On Thu, 8 May 2025 18:43:37 +0200, Jan Klemkow wrote: > On Thu, May 08, 2025 at 06:16:47PM +0200, Pascal Stumpf wrote: > > On Thu, 28 Nov 2024 10:15:58 +0100, Jan Klemkow wrote: > > > On Wed, Nov 27, 2024 at 06:32:23PM GMT, Pascal Stumpf wrote: > > > > Continuing from misc@: > > > > > > > > I have two different gateway machines, one with em(4), one with igc(4) > > > > that exhibit the problem. > > > > > > > > With an iked.conf policy like this: > > > > ikev2 "foo" esp \ > > > > from 192.168.5.0/24 to dynamic \ > > > > [...] \ > > > > peer any \ > > > > [...] > > > > > > > > where 192.168.5.1 is an address on the gateway itself and the default > > > > route is on pppoe0 upon vlan7 upon em0/igc0. TCP MSS is clamped in > > > > pf.conf for the IPSec tunnel: > > > > > > > > match on enc0 all scrub (max-mss 1228) > > > > > > > > This works as expected for any machine on the 192.168.5.0/24 network. > > > > However, TCP connections to 192.168.5.1 will receive huge return packets > > > > that get fragmented over pppoe0. > > > > > > > > Setting net.inet.tcp.tso=0 restores expected behaviour. So there is a > > > > bug somewhere when making the decision to rely on TSO for TCP > > > > segmentation. > > > > > > Interesting. I'll have a look at this next week. > > > > have you been able to find out anything? This bug is still present in > > -current, unfortunately. > > Sorry. I start reproduce you setup and stopped at PPPoE. > Do you have an idea how to do this? > > It this your communication path? > > IPSec -> pppoe0 -> vlan0 -> em0 ---- igc0 -> vlan0 -> pppoe0 -> IPSec
Yes, although I'm not sure if the PPPoE bit matters in this case; FWIW I can also reproduce this with: IPSec -> pppoe0 -> vlan7 -> em0 ---- re0 -> IPSec as well as IPSec -> iwx0 --- [router that does pppoe] --- re0 -> IPSec. and IPSec -> iwx0 --- [router that does pppoe] --- igc0 -> vlan7 -> pppoe0 -> IPSec.
