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

    Ipv6 unusable due lack of love from FreeBSD (prev: Support baby jumbo frames)

    General pfSense Questions
    7
    50
    9.6k
    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.
    • D
      doktornotor Banned
      last edited by

      @M_Devil:

      Using native ipv6 over PPPoE.

      Well, that'd be pretty much the same, except that you could start with values 20 bytes higher – 1492/1472 (since you do not have the tunnel encapsulation overhead) and go lower only if that does not help.

      1 Reply Last reply Reply Quote 0
      • H
        hda
        last edited by

        @M_Devil:

        Using native ipv6 over PPPoE.

        Not only have PPPoE WAN on 1492, but LAN on 1492 too, for RA. Then MSS is 1432 for IPv6. Test with wireshark and see the MSS 1440 when you leave LAN MTU on 1500 (or blank ?).

        1 Reply Last reply Reply Quote 0
        • M
          M_Devil
          last edited by

          Need to put LAN on MTU=1492 because of RA? I use Jumbo frames (MTU=9000) on LAN side. No problems at all with ipv4. Not sure if I understand your suggested test, but I give it a try.

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned
            last edited by

            @hda: Not needed at all on any PPPoE box I tried.

            @M_Devil: With the jumbo nonsense, you're on a sure way to a giant kaboom, which has totally nothing to do with this topic.

            1 Reply Last reply Reply Quote 0
            • M
              M_Devil
              last edited by

              @doktornotor mtu change on LAN side was suggested by hda. Because I did not see the relevance for changing MTU on LAN side, I did mention my use of jumbo for LAN side (for inter vlan routing).

              1 Reply Last reply Reply Quote 0
              • H
                hda
                last edited by

                My native IPv6 connection isn't comfortable (ISP IPv6 lease renewal fails) with MTU=1492 & MSS=1472 only on WAN & all 'blank' on LAN's. I concluded the common denominator MTU=1492 for IPv6, as long as MTU negotiation (rfc4638) doesn't work everywhere or flawlessly. Found out MTU=1492 & 'blank' MSS for all interfaces with IPv6 works best or reliable.

                @M_Devil: RA advertizes the MTU=xxxx in its broadcast.

                1 Reply Last reply Reply Quote 0
                • M
                  M_Devil
                  last edited by

                  @hda thank you for the clarification.

                  Running MTU and MSS settings like you suggested and running fine. Can only hope pfSense/FreeBSD team can solve the root cause in a reasonable amount of time.

                  1 Reply Last reply Reply Quote 0
                  • H
                    Harvy66
                    last edited by

                    I may be missing something, but I found some reference on https://calomel.org/freebsd_network_tuning.html

                    With an interface MTU of 1500 bytes we suggest an
                    net.inet.tcp.mssdflt of 1460 bytes. 1500 MTU minus 20 byte IP header minus 20
                    byte TCP header is 1460. With net.inet.tcp.rfc1323 enabled, tcp timestamps
                    are added to the packets and the mss is automatically reduced from 1460 bytes
                    to 1448 bytes total payload. Note: if you are using PF with an outgoing scrub
                    rule then PF will re-package the data using an MTU of 1460 by default, thus
                    overriding this mssdflt setting

                    It sounds like PF scrub doesn't adjust for rfc1323, so you need to manually set your MSS to 1448?

                    1 Reply Last reply Reply Quote 0
                    • D
                      doktornotor Banned
                      last edited by

                      It suggests to set net.inet.tcp.mssdflt which is not what the MSS setting does in the GUI. Plus it tells you that it will  be ignored completely by scrub, so no idea really what's the point in messing with net.inet.tcp.mssdflt here.

                      1 Reply Last reply Reply Quote 0
                      • H
                        Harvy66
                        last edited by

                        I guess what I was getting at is it ignores the default setting. The term "default" implies the value can be changed. Instead of using the default values, why not manually set the values?

                        1 Reply Last reply Reply Quote 0
                        • D
                          doktornotor Banned
                          last edited by

                          Dunno, but "scrub rule then PF will re-package the data using an MTU of 1460 by default, thus overriding this mssdflt setting" would strongly suggest that messing with that sysctl is a total waste of time.

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