[Swan] vti01 MTU not honored

[Xinwei Hong]

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 <paul at nohats.ca> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180228/b763efe5/attachment.html>