Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    VTI MTU Not Persistent

    Scheduled Pinned Locked Moved IPsec
    8 Posts 3 Posters 1.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Y
      YoungPeach
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        What are you trying to set it to?

        A better option is to use MSS clamping under the advanced IPsec options.

        Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • Y
          YoungPeach
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            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.

            Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • Y
              YoungPeach
              last edited by

              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. :)

              1 Reply Last reply Reply Quote 0
              • jimpJ
                jimp Rebel Alliance Developer Netgate
                last edited by

                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.

                Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 0
                • nzkiwi68N
                  nzkiwi68
                  last edited by

                  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

                  1 Reply Last reply Reply Quote 0
                  • jimpJ
                    jimp Rebel Alliance Developer Netgate
                    last edited by

                    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.

                    Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

                    Need help fast? Netgate Global Support!

                    Do not Chat/PM for help!

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.