Problem accessing https://my.procurve.com/profile/index.aspx (ACK is over the upper bound)

[Krzysztof Oledzki]

On Sun, 1 Jul 2007, Krzysztof Oledzki wrote:

>
>
> On Sun, 1 Jul 2007, Krzysztof Oledzki wrote:
>
>> Hello,
>> 
>> My colleague have just reported that he is unable to access "REGISTER HERE" 
>> page from the https://my.procurve.com/profile/index.aspx. Short debuging 
>> shows that his connection was dropped by the netfilter code running on 
>> fw/nat host:
> <CUT>
>> AFAIK netfilter is supposed to drop such packet (without sending a RST), 
>> isn't it? So why the RST packet was sent?
>
> OK, this was easy. The RST was sent simply because the packed was not dropped 
> but instead delivered to the local IP - there was no valid tuple to change 
> (unnat) the packed destination. Setting:
>
> iptables -I PREROUTING -m conntrack --ctstate INVALID -j DROP
>
> make no more RSTs, only retransmisions from the 216.34.143.7. And yes, I have 
> a patched kernel so I'm able to filter packets in a PREROUTING chain.
>
> The rest of the question remains:
>
>> Setting net.ipv4.netfilter.ip_conntrack_tcp_be_liberal solves the problem, 
>> but this is not a right fix and now the main question is: was this ACK 
>> really over the upper bound since when 
>> net.ipv4.netfilter.ip_conntrack_tcp_be_liberal is enabled it is possible to 
>> access this page (of course with many netfilter warnings that "ACK is over 
>> the upper bound").

Found this:

http://groups.google.pl/group/fa.openbsd.tech/browse_frm/thread/e27c7363b2c636b5/01ba6e0fa873cf42

Sounds familiar - it seems that there may be a crappy OpenBSD firewall 
lurking somewhere along the path. :(

What we can do with such packets? Maybe, when a ack is valid but a sack is 
not (as it is in this situation) we are able to remove such insane sack 
option(s) with a hope that this ACK itself may acknowledge something?

This is how this connection looks like when 
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal is enabled:

04:34:42.276125 IP (tos 0x0, ttl 127, id 10660, offset 0, flags [DF], proto: TCP (6), length: 48) 195.177.210.11.6747 > 216.34.143.7.443: S, cksum 0x4b25 (correct), 1809363748:1809363748(0) win 65535 <mss 1460,nop,nop,sackOK>
04:34:42.459601 IP (tos 0x0, ttl 241, id 65082, offset 0, flags [DF], proto: TCP (6), length: 48) 216.34.143.7.443 > 195.177.210.11.6747: S, cksum 0xa5a8 (correct), 3724064662:3724064662(0) ack 1809363749 win 4140 <mss 1380,nop,nop,sackOK>
04:34:42.459764 IP (tos 0x0, ttl 127, id 10665, offset 0, flags [DF], proto: TCP (6), length: 40) 195.177.210.11.6747 > 216.34.143.7.443: ., cksum 0xe248 (correct), ack 3724064663 win 65535
04:34:42.460215 IP (tos 0x0, ttl 127, id 10666, offset 0, flags [DF], proto: TCP (6), length: 142) 195.177.210.11.6747 > 216.34.143.7.443: P 1809363749:1809363851(102) ack 3724064663 win 65535
04:34:42.644004 IP (tos 0x0, ttl 241, id 65111, offset 0, flags [DF], proto: TCP (6), length: 162) 216.34.143.7.443 > 195.177.210.11.6747: P 3724064663:3724064785(122) ack 1809363851 win 4242
04:34:42.644766 IP (tos 0x0, ttl 127, id 10672, offset 0, flags [DF], proto: TCP (6), length: 83) 195.177.210.11.6747 > 216.34.143.7.443: P 1809363851:1809363894(43) ack 3724064785 win 65413
04:34:42.647212 IP (tos 0x0, ttl 127, id 10674, offset 0, flags [DF], proto: TCP (6), length: 1216) 195.177.210.11.6747 > 216.34.143.7.443: P 1809363894:1809365070(1176) ack 3724064785 win 65413
04:34:42.647362 IP (tos 0x0, ttl 127, id 10675, offset 0, flags [DF], proto: TCP (6), length: 1420) 195.177.210.11.6747 > 216.34.143.7.443: . 1809365070:1809366450(1380) ack 3724064785 win 65413
04:34:42.647381 IP (tos 0x0, ttl 127, id 10676, offset 0, flags [DF], proto: TCP (6), length: 689) 195.177.210.11.6747 > 216.34.143.7.443: P 1809366450:1809367099(649) ack 3724064785 win 65413
04:34:42.831152 IP (tos 0x0, ttl 241, id 65117, offset 0, flags [DF], proto: TCP (6), length: 40) 216.34.143.7.443 > 195.177.210.11.6747: ., cksum 0xc750 (correct), ack 1809365070 win 5461
acked 1809365070, 1380 + 649 octets unacked yet (1809367099)

04:34:42.831173 IP (tos 0x0, ttl 241, id 65119, offset 0, flags [DF], proto: TCP (6), length: 52) 216.34.143.7.443 > 195.177.210.11.6747: ., cksum 0x7ee4 (correct), ack 1809365070 win 5461 <nop,nop,sack 1 {2713871907:2713872556}>
sacked last 649 octets

04:34:42.835709 IP (tos 0x0, ttl 241, id 65123, offset 0, flags [DF], proto: TCP (6), length: 52) 216.34.143.7.443 > 195.177.210.11.6747: ., cksum 0x746e (correct), ack 1809367099 win 7490 <nop,nop,sack 1 {2713870527:2713872556}>
sacked full 2029 octets + acked everyting to 1809367099

04:34:42.841979 IP (tos 0x0, ttl 241, id 65127, offset 0, flags [DF], proto: TCP (6), length: 565) 216.34.143.7.443 > 195.177.210.11.6747: P 3724064785:3724065298(513) ack 1809367099 win 7490 <nop,nop,sack 1 {2713870527:2713872556}>
(redundant) sacked full 2029 octets + acked everyting to 1809367099 + sending some data + PUSH

04:34:42.853077 IP (tos 0x0, ttl 127, id 10684, offset 0, flags [DF], proto: TCP (6), length: 1150) 195.177.210.11.6747 > 216.34.143.7.443: P 1809367099:1809368209(1110) ack 3724065298 win 64900

Bingo... :)

04:34:43.136310 IP (tos 0x0, ttl 241, id 65148, offset 0, flags [DF], proto: TCP (6), length: 40) 216.34.143.7.443 > 195.177.210.11.6747: ., cksum 0xacc9 (correct), ack 1809368209 win 8600
04:34:43.383861 IP (tos 0x0, ttl 241, id 65264, offset 0, flags [DF], proto: TCP (6), length: 1420) 216.34.143.7.443 > 195.177.210.11.6747: . 3724065298:3724066678(1380) ack 1809368209 win 8600
04:34:43.386285 IP (tos 0x0, ttl 241, id 65265, offset 0, flags [DF], proto: TCP (6), length: 120) 216.34.143.7.443 > 195.177.210.11.6747: P 3724066678:3724066758(80) ack 1809368209 win 8600
04:34:43.390499 IP (tos 0x0, ttl 241, id 65267, offset 0, flags [DF], proto: TCP (6), length: 1420) 216.34.143.7.443 > 195.177.210.11.6747: . 3724066758:3724068138(1380) ack 1809368209 win 8600
04:34:43.394683 IP (tos 0x0, ttl 241, id 65270, offset 0, flags [DF], proto: TCP (6), length: 1420) 216.34.143.7.443 > 195.177.210.11.6747: . 3724068138:3724069518(1380) ack 1809368209 win 8600
04:34:43.403021 IP (tos 0x0, ttl 127, id 10695, offset 0, flags [DF], proto: TCP (6), length: 40) 195.177.210.11.6747 > 216.34.143.7.443: ., cksum 0xc8ad (correct), ack 3724066758 win 65535
(...)

There is a Windows XP host behind this NAT and is seems it is quite happy 
ignoring this sack crap as the ack itself finnaly acknowledged everyting. 
The transmition continues.


Additionally, creating TCPOPTSSTRIP target to allow striping specific tcp 
option(s) (for example Sack-Permitted from a SYN packet) may also be 
usable if it is possible to include this extension in a base kernel. This 
may also help with a similar window scaling problem as current solution 
requires to add a route on _all_ hosts inside a network. Working around it 
on a firewall may be much faster.


Best regards,

 				Krzysztof Olędzki

PS: I love to talk with myself. ;)