Date: Tue, 09 Nov 2004 12:04:50 +0100 From: Angelo Turetta <aturetta@commit.it> To: "Matthew T. Lager" <freebsd@trinetworks.com> Cc: freebsd-net@freebsd.org Subject: Re: 5.3-RELEASE w/ IPSEC & RACOON Message-ID: <4190A452.1060303@commit.it> In-Reply-To: <1903.24.25.209.32.1099792495.squirrel@24.25.209.32> References: <1903.24.25.209.32.1099792495.squirrel@24.25.209.32>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew T. Lager wrote: > Using the same configuration in 5.3-*, the tunnel is still established and > simple traffic can be sent across the tunnel. When a sudden burst of > packets is sent through the tunnel, that particular connection completly > and permanantly freezes. An example of this is a simple SSH session to > another FreeBSD machine where a dmesg is issued. About 5 lines into the > dmesg, the connection freezes up. > > Does anyone have any ideas or information? Thanks in advance! > > Matt Lager I once have seen a similar problem, and after a lot of tcpdump I found something I don't know all the exact details about, but I'll try to explain in non-technical language :-(. Apparently, sometimes a TCP packet is so full that after adding the ESP headers it's length exceeds the MTU. The IPSEC layer should fragment it transparently, while the receiving side reassemble the pieces and normally nobody notices. In my case, the remote side was a commercial firewall which actually blocked the fragments, hanging the TCP connection. To solve the problem I had to MSS-CLAMP all the TCP trafic between the two subnets. I don't know what filters you may have between your two bridge-head servers, but I advice you to tcpdump on the external interfaces of both sides, looking for strange packets. Hope this helps, Angelo Turetta
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4190A452.1060303>