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

    Changing AdvLinkMTU when using NPt

    Scheduled Pinned Locked Moved IPv6
    36 Posts 6 Posters 4.9k 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.
    • P
      paddy76
      last edited by

      For various reasons I've opted to use NPt between my LAN and WAN. Because of this the MTU set in radvd.conf is wrong as it seems to be following the LAN side MTU when not using interface tracking.
      This becomes an issue when using, for example, a GIF tunnel to HE as MTU has to be lowered to 1280.

      For now I've fixed it by changing the services.inc file so it always sets AdvLinkMTU to 1280 instead of interface MTU if interface tracking is not used.

      A more permanent solution would be if it were possible to manually set the MTU in the radvd gui configuration, follow option 26 from DHCPv6 or possibility to select interface that should be followed to get MTU for radvd.

      1 Reply Last reply Reply Quote 0
      • JKnottJ
        JKnott
        last edited by

        One thing that's mandatory with IPv6 is path MTU discovery.  That means that a too small MTU along the path is automagically discovered and adjusted for.  If that didn't work, you couldn't use paths where a link had a smaller MTU than your LAN.  Does the different MTU actually cause a problem?  Having a different MTU on LAN vs WAN has always been part of networking.  Years ago, 576 was a common MTU for dial up links, yet connected just fine with Ethernet & 1500 byte MTU or token ring with 4K byte MTU.  The main difference back then was fragmentation of too large packets.  With IPv6 and even IPv4 now. MTU discovery is used to prevent too large packets from being sent, so fragmentation is no longer needed.

        Also, for the first 6 years I had IPv6, I used a tunnel broker with 1280 MTU and never had a problem, even though my LAN was the usual 1500.

        PfSense running on Qotom mini PC
        i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
        UniFi AC-Lite access point

        I haven't lost my mind. It's around here...somewhere...

        1 Reply Last reply Reply Quote 0
        • demD
          dem
          last edited by

          I also modify services.inc to set the MTU to 1280. PMTU discovery is nice in theory but in practice too much traffic ends up going nowhere.

          1 Reply Last reply Reply Quote 0
          • JKnottJ
            JKnott
            last edited by

            @Dave:

            I also modify services.inc to set the MTU to 1280. PMTU discovery is nice in theory but in practice too much traffic ends up going nowhere.

            If it fails, it's because someone blocked ICMP somewhere.  IP has long been designed to work with smaller MTUs along the path and I've certainly not had a problem with MTU discovery.  For example, if someone has an ADSL connection, they'd normally have 1500 on the LAN, 1492 on the WAN and may hit 1280 somewhere, even without a tunnel.  IP has to deal with it and does.

            As I mentioned above, I used a tunnel for 6 years and never had an issue with MTU.

            PfSense running on Qotom mini PC
            i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
            UniFi AC-Lite access point

            I haven't lost my mind. It's around here...somewhere...

            1 Reply Last reply Reply Quote 0
            • N
              Napsterbater
              last edited by

              @paddy76:

              For various reasons I've opted to use NPt between my LAN and WAN. Because of this the MTU set in radvd.conf is wrong as it seems to be following the LAN side MTU when not using interface tracking.
              This becomes an issue when using, for example, a GIF tunnel to HE as MTU has to be lowered to 1280.

              Ummm NPt has nothing to do with MTU, it is not the reason the "MTU is wrong" (its not). An Ethernet LAN has a MTU of 1500, thus will be advertised as such. It is NOT suposed to advertise that WAN MTU to the LAN.

              Nothing is wrong with it advertising 1500 MTU, that is as designed/intended.

              1 Reply Last reply Reply Quote 0
              • JKnottJ
                JKnott
                last edited by

                An Ethernet LAN has a MTU of 1500, thus will be advertised as such.

                Actually, I was experimenting with 9K byte jumbo frames the other day.  Even had the pfSense DHCP server configured with option 26 to do that.  The only thing that has a limit of 1500 bytes is 802.3 Ethernet.  IP uses Ethernet II, which does not have a size limit, though older hardware might be limited to 1500.  Gigabit gear generally supports jumbo frames.

                PfSense running on Qotom mini PC
                i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                UniFi AC-Lite access point

                I haven't lost my mind. It's around here...somewhere...

                1 Reply Last reply Reply Quote 0
                • N
                  Napsterbater
                  last edited by

                  @JKnott:

                  An Ethernet LAN has a MTU of 1500, thus will be advertised as such.

                  Actually, I was experimenting with 9K byte jumbo frames the other day.  Even had the pfSense DHCP server configured with option 26 to do that.  The only thing that has a limit of 1500 bytes is 802.3 Ethernet.  IP uses Ethernet II, which does not have a size limit, though older hardware might be limited to 1500.  Gigabit gear generally supports jumbo frames.

                  godd point.. I should have mentioned that in general an MTU of 1500 is used/standard. But you are right, its not the max.

                  But my point of it not being related to NPt, no more having to be the same as or even related to the WAN MTU stands.

                  1 Reply Last reply Reply Quote 0
                  • F
                    FuN_KeY
                    last edited by

                    I am using 6RD for ipv6 tunneling, and I am also required to lower the AdvLinkMTU to 1280 in order to get ipv6 working.

                    I would also greatly benefit from a proper way to define this value (either in the webGUI or some config file). I do not see how auto MTU detection could be of any help in this scenario, my clients blindly follow what is advertised by radvd.

                    1 Reply Last reply Reply Quote 0
                    • N
                      Napsterbater
                      last edited by

                      @FuN_KeY:

                      I am using 6RD for ipv6 tunneling, and I am also required to lower the AdvLinkMTU to 1280 in order to get ipv6 working.

                      I would also greatly benefit from a proper way to define this value (either in the webGUI or some config file). I do not see how auto MTU detection could be of any help in this scenario, my clients blindly follow what is advertised by radvd.

                      There is no reason to set LAN MTU less then 1500, even if your WAN has a different/smaller MTU.

                      And everything I see says pfSense uses/forces 1280 MTU for 6rd WAN, which means when pfSense gets a 1500 packet, it will send a ICMPv6 Type 2 "Packet to Big" to the client, the client should then reduce its MTU for that connection to 1280 on its own, that is how IPv6 was designed to work and how it does work, until people start blocking ICMPv6 without knowing what they are doing.

                      Which means you are probably either breaking/blocking ICMPv6/PMTUD, or you have broken clients.

                      1 Reply Last reply Reply Quote 0
                      • JKnottJ
                        JKnott
                        last edited by

                        And everything I see says pfSense uses/forces 1280 MTU for 6rd WAN, which means when pfSense gets a 1500 packet, it will send a ICMPv6 Type 2 "Packet to Big" to the client, the client should then reduce its MTU for that connection to 1280 on its own, that is how IPv6 was designed to work and how it does work, until people start blocking ICMPv6 without knowing what they are doing.

                        Also, when the connection fails, even though the MTU was properly negotiated, then it's assumed someone is blocking ICMP and so TCP will adjust the size automagically, so that the connection will work.

                        PfSense running on Qotom mini PC
                        i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                        UniFi AC-Lite access point

                        I haven't lost my mind. It's around here...somewhere...

                        dragoangelD 1 Reply Last reply Reply Quote 0
                        • F
                          FuN_KeY
                          last edited by

                          First of all, I did not hardcode any MTU on any interface

                          I did some more investigation, and on the pfsense level, the MTU negotiation is fine:

                          wan_stf: flags=4041 <up,running,link2>metric 0 mtu 1280
                                  inet6 2a02:xxxx:xxx:xxx:: prefixlen 32
                                  nd6 options=1 <performnud>v4net xxx.x.xx.xx/32 -> tv4br xxx.xxx.xxx.xxx
                                  groups: stf

                          The problem is that radvd is either taking 1500 or the MTU of the LAN interface (which end up being 1500 in my case). I did some wireshark and saw no packet too bit.

                          How is it meant to be working? Should pfsense advertise the correct MTU? Should the client be able adjust on packet too big? Who would issue the packet too big (pfsense, 6RD GW, …) ?</performnud></up,running,link2>

                          1 Reply Last reply Reply Quote 0
                          • JKnottJ
                            JKnott
                            last edited by

                            PfSense should be advertising the MTU of the local link only, not any other interface.  So, even if your tunnel is only 1280, the local link is 1500.  IPv6 will then use Path MTU Discovery to set the MTU for any traffic passing through that tunnel.  So, if you look at packets going through the tunnel, you should see an MTU of 1280.  You can capture the packets with Packet Capture, but will have to export to Wireshark to see the MTU.  If you capture everything, you can see PMTUD in action.

                            PfSense running on Qotom mini PC
                            i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                            UniFi AC-Lite access point

                            I haven't lost my mind. It's around here...somewhere...

                            1 Reply Last reply Reply Quote 0
                            • N
                              Napsterbater
                              last edited by

                              @FuN_KeY:

                              First of all, I did not hardcode any MTU on any interface

                              I didnt say you did, I said pfSense does on 6RD interfaces.

                              @FuN_KeY:

                              The problem is that radvd is either taking 1500 or the MTU of the LAN interface (which end up being 1500 in my case). I did some wireshark and saw no packet too bit.

                              That is not a problem, that is exactly what it is supposed to do.

                              @FuN_KeY:

                              How is it meant to be working? Should pfsense advertise the correct MTU? Should the client be able adjust on packet too big? Who would issue the packet too big (pfsense, 6RD GW, …) ?

                              pfSense is advertising the correct MTU for the Ethernet LAN, 1500, again that is what it is supposed to do.

                              When pfSense receives a packet that need to be forwarded though the 6RD interface with an MTU of 1280 that is larger then that it will send a ICMNPv6 Type 2 (Packet to big) message with the MTU that should be used, the client will then resend its packets to that destination with the new MTU. If you block All ICMP or those messages the connection will fail if any packets are over the MTU of the link.

                              Also really 6rd does not have an automatic MTU of 1280, pfSense just sets it that way for some reason. 6rd MTU can be upto:
                              (Your WAN MTU) - 20 = (6RD MTU)

                              Also NPt has NOTHING to do with MTU at all.

                              1 Reply Last reply Reply Quote 0
                              • JKnottJ
                                JKnott
                                last edited by

                                ^^^^
                                Where's this 6rd coming from?  I thought the OP was talking about he.net, which uses 6in4 over a configured tunnel.  6rd is a method used by some ISPs to provide IPv6, using the ISPs IPv4 addresses.  While both methods use a tunnel for IPv6, the set up is quite different.

                                https://en.wikipedia.org/wiki/IPv6_rapid_deployment

                                PfSense running on Qotom mini PC
                                i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                                UniFi AC-Lite access point

                                I haven't lost my mind. It's around here...somewhere...

                                1 Reply Last reply Reply Quote 0
                                • N
                                  Napsterbater
                                  last edited by

                                  @JKnott:

                                  ^^^^
                                  Where's this 6rd coming from?  I thought the OP was talking about he.net, which uses 6in4 over a configured tunnel.  6rd is a method used by some ISPs to provide IPv6, using the ISPs IPv4 addresses.  While both methods use a tunnel for IPv6, the set up is quite different.

                                  https://en.wikipedia.org/wiki/IPv6_rapid_deployment

                                  Op was using a GIF INterface and I assume he.net tunnel.

                                  FuN_KeY is using 6rd.

                                  1 Reply Last reply Reply Quote 0
                                  • JKnottJ
                                    JKnott
                                    last edited by

                                    AC3200 is acting as my main gateway, and I want to use it as DHCP server for local and VPN clients.

                                    If they were using 6rd, there'd be no need for he.net.  Either method creates an IPv6 tunnel, but you wouldn't use both.  So, it's either 6rd or he.net.  Take your pick.

                                    PfSense running on Qotom mini PC
                                    i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                                    UniFi AC-Lite access point

                                    I haven't lost my mind. It's around here...somewhere...

                                    1 Reply Last reply Reply Quote 0
                                    • F
                                      FuN_KeY
                                      last edited by

                                      I was able to capture the packet too big on wireshark. Everything looks good, except for my Windows 10 client that appear to ignore this value.

                                      1 Reply Last reply Reply Quote 0
                                      • JKnottJ
                                        JKnott
                                        last edited by

                                        @FuN_KeY:

                                        I was able to capture the packet too big on wireshark. Everything looks good, except for my Windows 10 client that appear to ignore this value.

                                        So, it continues to send 1500 byte packets, despite the too big message?  I certainly never had a problem running Windows on IPv6, back when I used a tunnel.

                                        PfSense running on Qotom mini PC
                                        i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                                        UniFi AC-Lite access point

                                        I haven't lost my mind. It's around here...somewhere...

                                        1 Reply Last reply Reply Quote 0
                                        • N
                                          Napsterbater
                                          last edited by

                                          @JKnott:

                                          @FuN_KeY:

                                          I was able to capture the packet too big on wireshark. Everything looks good, except for my Windows 10 client that appear to ignore this value.

                                          So, it continues to send 1500 byte packets, despite the too big message?  I certainly never had a problem running Windows on IPv6, back when I used a tunnel.

                                          Agreed,, I have never had an issues with PMTUD on Winows since XP..

                                          1 Reply Last reply Reply Quote 0
                                          • N
                                            Napsterbater
                                            last edited by

                                            @FuN_KeY:

                                            I was able to capture the packet too big on wireshark. Everything looks good, except for my Windows 10 client that appear to ignore this value.

                                            Any 3rd party firewall?/security software? Have you made any canges to the windows firewall.

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