Date: Sat, 21 Dec 2019 08:33:50 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 242744] IPSec in transport mode between FreeBSD hosts blackholes TCP traffic Message-ID: <bug-242744-7501-3yHM4oTrCL@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-242744-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-242744-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242744 --- Comment #5 from Victor Sudakov <vas@sibptus.ru> --- (In reply to Eugene Grosbein from comment #4) > First, one can use IPSec transport mode combined with gif tunnel and mtu= =3D1500 for the gif.=20 The solution with gif or if_ipsec tunnels is not scalable if you want to cr= eate a mesh of hosts with protected traffic between them. If we are talking about not more than 2-3 hosts, then the if_ipsec solution is the most elegant.=20 > Second, one can try sysctl net.inet.ipsec.dfbit=3D0 that is documented in= =20 > ipsec(4) manual page for IPSec tunnel mode=20 > but maybe it works for transport mode, too I wrote in the initial problem description that this sysctl does not work f= or transport mode. You just did not pay attention. > Third, you can adjust TCP MSS by means of packet filters.=20 I don't think I can if the packet in question is not received or transmitted via any interface (like locally generated ssh-client traffic intercepted by IPSec policies). Or I'll try if you provide an example of matching such a packet. I also tried pf's "scrub out proto 50 no-df" but there was no match. In a FreeBSD - Windows 7 combination, this kind of transport mode works transparently out of the box. I think Windows knows to adjust MSS, or something. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-242744-7501-3yHM4oTrCL>