VTI MTU Not Persistent
-
FYI to Netgate - VTI interfaces are not retaining their MTU passed a reboot.
When rebooted, the ipsec interface MTU drops to 1400 no matter what it was configured at previously.
-
What are you trying to set it to?
A better option is to use MSS clamping under the advanced IPsec options.
-
Was trying to set to 1472.
I've got my MSS clamping set to 1400 now and removed MSS / MTU from interface. However, I would love to have it set to 1472 as I know that MTU works.
But when my VPN comes up, my ER-Lite comes up with the correct MTU of 1472, the VTI on pfSense comes up 1400 and my OSPF adjacency gets stuck in Exchange (expected of course with MTU mismatch). If I manually set MTU on ipsec interface to 1400, Save, then set to 1472, Save, the ipsec6000 interface comes up with the correct MTU and everything works. When firewall reboots, it reverts to 1400.
-
Hmm, ok. I'm not sure that was intended to work. I don't recall doing anything specific to handle the MTU for the IPsec interfaces when they are configured. I can look into it, but it may not be something fixable for 2.4.4-p1. I opened https://redmine.pfsense.org/issues/9111 to track it for 2.4.5.
-
That's quite okay!
It's functioning fine on the 1400, just trying to sneak those few little extra bytes out of the connection, that's all. :)
-
In the "better late than never" category, just thought you'd want to know I pushed a commit that should fix this. I tested it here and on two boxes I was able to set an MTU of 1472, then reboot, and they both came back up with an MTU of 1472 and were still exchanging OSPF routes.
-
That's great to hear!
That will resolve a bug I posted FRR OSPF state stuck in Extart / Exchange because of MTU following pfSense restart
https://redmine.pfsense.org/issues/9528
-
I closed that out since it's essentially a duplicate of #9111
You can apply the commit ID on that issue on 2.4.4-p3 to pick up the fix there.
