A simple matter of…

No, I’m still employed

Had an interesting one at work today, ssh over vpn to a box worked fine, but when I tried to scp a large file up, the connection hung. A bit of Wiresharking later and I have my answer – the Cisco ASA firewall is mangling the sequence numbers of packets coming out from the server back to my laptop (but not those from my laptop to the server). This is pretty silly in this environment since Linux has a much better track record than Cisco does at using random sequence numbers and the extra hassle of debugging such a connection definitely means it should be off.

Lastly it needs to be off since the ASA doesn’t mangle the “SACK” options to match – so when the server sends packet with SACK options set back to my laptop, oddly enough my laptop bins the packet since the SACK bits make no sense.

I can hardly see a reference to this at all on the web, so hopefully this one will help
Cisco hide most of their documentation (evil) the only reference I can see in their documentation seems to refer to clearing the SACK options rather than dropping packets with them set (neither of which seems to be what’s happening in what I saw).

“echo 0 >/proc/sys/net/ipv4/tcp_sack” on the Linux box sending the SACKs works around the problem – we now just lose all the benefit of SACK (which is that when a packet it dropped, we have to retransmit _all_ the subsequent packets, rather than just the missing ones).