5.027 Kernel Upgrade...!

I have updated three ASL v5.026 boxes to v5.027, which each use very different hardware, and so far encountered no problems.

Actually, I just discovered now that CPU load dropped by 40..60% depending on the hardware, e.g. on a P-II/350 MHz CPU load dropped from nearly 60% to 30%, and on a Xeon 2.7 GHz from nearly 15% to 6% or so.

Quite a pleasant surprise!

Rolf

Hi,

after upgrading to the latest kernel we are no longer able to use FTP using the built in W2K ftp tool. The following error is generated:

150 Opening BINARY mode data connection for > Netout :Connection reset by peer
Connection closed by remote host.
ftp> close
Not connected.
ftp> bye

When using a general FTP program it works fine. Transfer fails when using the windows FTP tool.

Franc.

This is adversely affecting me. Is there a way to rollback to 5.026 (without having to re-install)?

Thanks,
Barry

[ QUOTE ]
This is adversely affecting me. Is there a way to rollback to 5.026 (without having to re-install)?

Thanks,
Barry 

[/ QUOTE ]
Hi Barry,
do you have a web-page that you can post here where the problem occurs?
(I do not have an idea to switch back to 5.026 without doing a reinstall)

cu SveN

Can you check whether you have enabled one of the following options in "Packet Filter->Advanced":
- "Strict TCP Session Handling"
- "Validate Packet-Length"

Regards,
Stephan

Hi Stephan, 

both Options were OFF (I turned them on for a test, but that didn't help). 
SYN Rate Limiter was ON (I turned this one OFF, this didn't help also).

I kernel.log still the same: 
 2004:11:18-14:45:52 (none) kernel: ip_conntrack_tcp: INVALID: invalid state SRC= DST= LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=47890 DF PROTO=TCP SPT=443 DPT=2676 SEQ=2878483313 ACK=1416483982 WINDOW=65535 RES=0x00 ACK URGP=0

I had the Strict TCP option enabled, wasn't aware it was. Disabled it now, will see how things are now.

Still having invalid state, and invalid syn showing up.

Here are the ones I am seeing, sanitized:

2004:11:18-08:51:54 (none) kernel: ip_conntrack_tcp: INVALID: invalid state SRC=192.168.X.X DST=X.X.X.X LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=36805 DF PROTO=TCP SPT=2180 DPT=4806 SEQ=512916997 ACK=3438793701 WINDOW=64512 RES=0x00 ACK URGP=0 

2004:11:18-08:52:41 (none) kernel: ip_conntrack_tcp: INVALID: invalid SYN (ignored) SRC=X.X.X.X DST=X.X.X.X LEN=48 TOS=0x00 PREC=0x00 TTL=43 ID=38242 DF PROTO=TCP SPT=4616 DPT=2180 SEQ=1266878367 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405AC01010402) 

2004:11:18-08:52:41 (none) kernel: ip_conntrack_tcp: INVALID: invalid state SRC=192.168.X.X DST=X.X.X.X LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=38045 DF PROTO=TCP SPT=2180 DPT=4616 SEQ=525803101 ACK=1266878368 WINDOW=64512 RES=0x00 ACK URGP=0

And now, after looking through my logs, I am seeing this one as well:

2004:11:18-08:27:23 (none) kernel: ip_conntrack_tcp: IGNORED: Out of window data; SEQ is over the upper bound (over the window of the receiver)

AND, also a LOT more of the bad tcp checksum errors with none of the advanced PF options enabled.

Interesting..i am not having this issue..but i will definitly keep a lookout for others that maybe..

Last night, I was unable to access https://wwws.ameritrade.com/apps/LogIn/
from one PC while another PC was running P2P (eMule) at 100kbits/sec. (my outgoing bw is 256kbits (measured))

browser reported connection resets and other errors.

normal HTTP was working fine.

further throttling the P2P reduced the errors.

BTW, I'm not using ASL's proxy, but am using another Squid proxy in the DMZ.

This did not occur prior to 5.027.
Also, I believe general connectivity has gone downhill in 5.027.
Even with QOS set up properly, surfing is unbearably slow while P2P is running, even at only 50kbits/sec.

Barry

Last night, I was unable to access https://wwws.ameritrade.com/apps/LogIn/
from one PC while another PC was running P2P (eMule) at 100kbits/sec. (my outgoing bw is 256kbits (measured))

browser reported connection resets and other errors.

normal HTTP was working fine.

further throttling the P2P reduced the errors.

BTW, I'm not using ASL's proxy, but am using another Squid proxy in the DMZ.

This did not occur prior to 5.027.
Also, I believe general connectivity has gone downhill in 5.027.
Even with QOS set up properly, surfing is unbearably slow while P2P is running, even at only 50kbits/sec.

Barry

Hi there all, 

in 5.027 the new kernel introduced a new security functionality called "TCP-Window Tracking", 
which can not be configured and is always activated.
This improvement monitors the SYN and ACK sequence number of every connection established through the firewall, in order to discard packages that do not match the actual allowed TCP windows.
Every Linux 2.4 kernel has this limitation, which recently (2-3 months ago) created some press about DoS using RST packets in conjunction with tcp window scaling.

This new functionality is needed to detect and prevent such kind of attacks, but also can introduce problems with TCP stacks from other machinces on the internet that do not correclty handle the TCP window.

This new functionality has also a very verbose logging, to make sure that attacks on that level can be detected and analyzed afterwords.
Even as the logfiles are filled with many messages, those are mostly informational messages/

Nevertheless we have you and one other customer who experiance difficulties to reach certain servers on the internet, 
therefore we are currently investigation this issue and will update you as soon as we have additional information.

Best Regards
Gert Hansen

Thanks Gert.

Any way to disable this feature on the console, or rollback to 5.026 w/o having to re-install?

Here's some log output in case you need it:

Code:

---

2004:11:17-21:14:10 (none) kernel: ip_conntrack_tcp: INVALID: invalid SYN (ignored) SRC=199.200.9.1 DST=69.166.x.x LEN=44 TOS=0x00 PREC=0x00 TTL=231 ID=35603 PROTO=TCP SPT=80 DPT=42134 SEQ=1847748428 ACK=2691260888 WINDOW=8190 RES=0x00 ACK SYN URGP=0 OPT (020405B4)

2004:11:17-21:14:51 (none) kernel: ip_conntrack_tcp: INVALID: invalid SYN (ignored) SRC=199.200.9.1 DST=69.166.x.x LEN=44 TOS=0x00 PREC=0x00 TTL=231 ID=47747 PROTO=TCP SPT=80 DPT=42138 SEQ=2975213062 ACK=2734272676 WINDOW=8190 RES=0x00 ACK SYN URGP=0 OPT (020405B4)

2004:11:17-21:16:51 (none) kernel: ip_conntrack_tcp: INVALID: invalid SYN (ignored) SRC=199.200.9.1 DST=69.166.x.x LEN=44 TOS=0x00 PREC=0x00 TTL=231 ID=52771 PROTO=TCP SPT=80 DPT=42163 SEQ=1449251316 ACK=2852810003 WINDOW=8190 RES=0x00 ACK SYN URGP=0 OPT (020405B4)

---

 

Thanks,
Barry 

Hi Gert,

does the problem I have with resetting FTP connections also have to do with this issue ?

Regards,
Franc.

[ QUOTE ]
Hi Gert,

does the problem I have with resetting FTP connections also have to do with this issue ?

Regards,
Franc. 

[/ QUOTE ]
Have you tried using PASV?

cu SveN

In my experience, PASV ftp usually makes things worse, especially if doing MASQ/NAT, etc.

Dunno if it'd help in this case though.

Barry

Hi,

no I'm not using PASV. Things broke after installing 5.027. Before that the FTP script worked perfectly fine. Chaning to PASV didn't solve the problem. FTP is aborted during transfer at random positions.

Franc.

Followimg my upgrade to 5.027 I'm having problems browsing some SSL and non-SSL sites too.  Any news of a fix ?

I have investigated these issues and found that Symantec firewalls may cause problems. They may reply to a SYN packet with an ACK packet (instead of SYN-ACK) and expect an RST packet back. If they receive the RST packet, then incoming connections are handled correctly afterwards (by issuing SYN-ACK). This mechanism is an unusual behaviour which may or may not work in reality.

Could you please provide we with URLs and sites that cause problems? Either post it to the UBB or e-mail me directly.

Regards,
Stephan

Some sites are:-

www.maporama.com
www.jnwine.com
https://www.halifax-online.co.uk/_mem_bin/FormsLogin.asp?source=halifaxcouk


 Interestingly the problem only seems to happen when using an ADSL internet connection. If I use my leased line internet connection the problem does not occur - perhaps it is an MTU issue with the ADSL connection ?

This is interesting, I ihave the content filter turned on with a/v under transparent mode with strict tcp/ip on and all of those sites came up fine.  I am on a verizon DSL connection.  This is one i am watching closely.