sorry my bad. I got confused with my earlier configuration. Actually, both sides are libreswan, one side is vti, other side is ipsec0(pluto+klips). I was using ip link to set mtu to different size. Actually I just tried to set MTU on ipsec0 to a smaller value (less than 1332), and I see similar behavior from the other side. So, basically, MTU only affect sending size, receiving larger MTU is OK. I found this online. https://serverfault.com/questions/749110/why-can-i-receive-ethernet-frames-bigger-than-my-current-mtu-size
Looks like the behavior is expected. Thanks, Xinwei On Tue, Feb 27, 2018 at 7:03 PM, Paul Wouters <[email protected]> wrote: > On Tue, 27 Feb 2018, Xinwei Hong wrote: > > I have a route-based vpn setting between racoon and libreswan. The racoon >> side has MTU=1476, and libreswan has MTU=1332. When I ping >> with DF flag and pktsize larger than 1332 from libreswan side, pkt would >> be dropped as expected. However, from racoon side, ping with >> DF flag and pktsize=1400 could still reach host on libreswan side. Any >> idea why the vti01 does not drop the big pkt when DF is set? >> > > I'm not an expert on the kernel VTI implementation, other then knowing > it is being completely rewritten.... > > The VTI device MTU differs from kernel version to kernel version. I'm > not sure why. libreswan doesn't change the MTU. I assume raccoon does > not either? (Does it even support vti, or are you doing this manually?) > > In 3.23 we added support for nopmtudisc=yes|no (default no) which could > maybe be used to change some of this behaviour? > > Paul >
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
