How does MTU actually function GUI->real???
-
The comment underneath the interface MTU setting is a bit confusing: "If a value is entered in this field, then MSS clamping for TCP connections to the value entered above minus 40 for IPv4 (TCP/IPv4 header size) and minus 60 for IPv6 (TCP/IPv6 header size) will be in effect."
I need to use MSS and MTU because we're on a PPPoE link.
So I have MSS of 1492.
My actual MTU (ipv4) is thus 1452.Normally I would enter 1452 for MTU.
If the description is correct, I should enter 1492 and pfSense will autoconfigure the actual MTU for ipv4 vs ipv6?
If so, why not make this a checkbox? No value need be entered??
-
I wouldn't expect you to need to set anything. I use PPPoE and the interface is already MTU 1492 by default. I don't set an MSS value specifically.
Steve
-
@stephenw10 So if I DO need to set MTU and MSS... sounds like you don't know how this works?
-
You can see how it works by looking at the interface and filtering. So for example if you enter:
Resulting in a config of:
<lan> <enable></enable> <if>vtnet1</if> <descr><![CDATA[LAN]]></descr> <ipaddr>192.168.20.1</ipaddr> <subnet>24</subnet> <ipaddrv6>track6</ipaddrv6> <track6-interface>wan</track6-interface> <track6-prefix-id>0</track6-prefix-id> <spoofmac></spoofmac> <mtu>1492</mtu> <mss>1300</mss> </lan>
You get an MTU set on the interface:
vtnet1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1492 description: LAN options=800b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE> ether 96:8f:b7:21:75:aa inet6 fe80::948f:b7ff:fe21:75aa%vtnet1 prefixlen 64 scopeid 0x2 inet6 fe80::1:1%vtnet1 prefixlen 64 scopeid 0x2 inet 192.168.20.1 netmask 0xffffff00 broadcast 192.168.20.255 media: Ethernet 10Gbase-T <full-duplex> status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
And pf rules:
scrub on $LAN inet all max-mss 1260 fragment reassemble scrub on $LAN inet6 all max-mss 1240 fragment reassemble
Steve
-
@stephenw10 Very cool. I am learning even from your example :)
And, your example confirms my surmise: since MSS should be 40/60 bytes smaller than MTU (for ipv4/ipv6)...
- One would set the two fields to be the same value if MSS is needed
- And there's no need for anything but an MSS checkbox.
If there are exceptions to this, I'd suggest modifying the documentation/comment to say it clearly:
"If MSS clamping is needed, normally enter the same value as MTU. MSS clamping for TCP connections is set to the value entered above minus 40 for IPv4 (TCP/IPv4 header size) and minus 60 for IPv6 (TCP/IPv6 header size.)" -
Yeah, you are not the first to question the logic there!
But it's been like that forever and changing it now would be a POLA violation.
You set the mss value to limit the packet size and pfSense sets max-mss appropriately.Bare in mind MSS only acts on TCP so if you really need to set a limit below 1492 you should set MTU so that pmtud will see it and restrict other protocols.
Steve
-
johnpoz LAYER 8 Global Moderatorlast edited by johnpoz Mar 29, 2022, 11:16 PM Mar 29, 2022, 11:11 PM
@stephenw10 said in How does MTU actually function GUI->real???:
POLA violation.
Dude ;) You dating yourself with pulling out that term.. heheheh Or maybe dating myself knowing what that means - hehehe
To be honest MSS clamping is antiquated from the days of frame relay and dial up, when the internet was just starting out, etc. You shouldn't really have to ever mess with that these days..
I can say with all honesty in 30 some years in the biz, have never had to mess with setting that to get shit to work.. Maybe back when on dial up with trumpet or something ;) in the early days of tcp..
-
stephenw10 Netgate Administratorlast edited by stephenw10 Mar 29, 2022, 11:50 PM Mar 29, 2022, 11:50 PM
Mmm, I mostly see it used/required where there is some tunneling involved, usually ipsec.
And that weird VMWare thread...
-
@stephenw10 said in How does MTU actually function GUI->real???:
see it used/required where there is some tunneling involved
But then the mtu is changed, like with PPPoE - if you ask me if your having to lower it more than the mtu you set on the tunnel via mss - something is borked. Or trying to run a tunnel inside a tunnel sort of thing..
-
@johnpoz said in How does MTU actually function GUI->real???:
POLA violation.
Dude ;) You dating yourself with pulling out that term.. heheheh Or maybe dating myself knowing what that means - hehehe
Maybe dating a lot of us. It's fun using it and then explaining it to people that have never seen a 6502 cpu.
Now how about bikesheds?
-
-
@stephenw10 I knew I'd found friends here LOL
Y'all are youngsters though.
How many have loved JFFO?
(POLA is in the eyes of the beholder, BTW... at least we can document the "normal" use of the form field to make life easy.)
And yes, @johnpoz, this is all about tunnels... Not positive I need it yet, but I'm running HE tunnel over PPPoE...
-
stephenw10 Netgate Administratorlast edited by stephenw10 Mar 30, 2022, 2:41 PM Mar 30, 2022, 1:45 PM
Yeah you would need to set that lower, see:
https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunnel-broker.htmlIf the WAN used for terminating the GIF tunnel is PPPoE or another WAN type with a low MTU, move the slider down as needed. For example, a common MTU for PPPoE lines with a tunnel broker is 1452.
Steve
-
@mrpete said in How does MTU actually function GUI->real???:
Not positive I need it yet, but I'm running HE tunnel over PPPoE...
Yeah mss clamping is not your issue with that.. I saw your other HE thread..
-
@stephenw10 said in How does MTU actually function GUI->real???:
Yeah you would need to set that lower...
...a common MTU for PPPoE lines with a tunnel broker is 1452.
OK, this is quite wierd.... I'm testing to discover the actual limit. From inside pfSense...
ping6 -nms 1232 google.com PING6(1280=40+8+1232 bytes) 2001:470:39:3c7::2 --> 2607:f8b0:400f:803::200e 76 bytes from 2607:f8b0:400f:803::200e, icmp_seq=0 hlim=119 time=6.014 ms
Anything larger fails.
I can reach both ends of the HE tunnel with 1452.
UPDATE: looks like a pfSense bug. Why oh why would it set the gif interface MTU to 1280 as a default?!!!
-
@stephenw10
OK, and with my gif-based WANv6 interface manually set to MTU = 1492... I still have a minor question:- I can ping6 to either end of the HE tunnel with -nms 1452
- But to go beyond requires -nms 1444
Is there some kind of extra packet overhead involved?
I'd really rather not chalk it up to "ipv6 is just strange that way" ;)
-
Hmm, yet you can ping the remote side of it with 1452?
-
@mrpete said in How does MTU actually function GUI->real???:
Why oh why would it set the gif interface MTU to 1280 as a default?!!!
You can change it on the HE site..
1280 is a common MTU for IPv6, since it like a requirement that IPv6 support this min size.
And you can change it on your interface..
-
@johnpoz 'twas not an issue on the HE site. Just had to set 1492 there since I am using PPPoE.
and yes, I can and now have forced it on my end.
Just more than a little surprised to see a default of 1280?!!!
And YES @stephenw10 , I could ping the far end of the tunnel way beyond the MTU. Crazy.
And now, I can ping the far end of the tunnel with 8 bytes more than the outside world.
Here: Near, Far, GoogleBad, GoogleGood ;)
[2.6.0-RELEASE][root@jasmine.ds.org]/root: ping6 -nms 1452 2001:470:39:3c7::2 PING6(1500=40+8+1452 bytes) 2001:470:39:3c7::2 --> 2001:470:39:3c7::2 1460 bytes from 2001:470:39:3c7::2, icmp_seq=0 hlim=64 time=0.180 ms ^C --- 2001:470:39:3c7::2 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.148/0.163/0.180/0.013 ms [2.6.0-RELEASE][root@jasmine.ds.org]/root: ping6 -nms 1452 2001:470:39:3c7::1 PING6(1500=40+8+1452 bytes) 2001:470:39:3c7::2 --> 2001:470:39:3c7::1 1460 bytes from 2001:470:39:3c7::1, icmp_seq=0 hlim=64 time=5.750 ms ^C [2.6.0-RELEASE][root@jasmine.ds.org]/root: ping6 -nms 1452 google.com PING6(1500=40+8+1452 bytes) 2001:470:39:3c7::2 --> 2607:f8b0:400f:802::200e ^C --- google.com ping6 statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss [2.6.0-RELEASE][root@jasmine.ds.org]/root: ping6 -nms 1444 google.com PING6(1492=40+8+1444 bytes) 2001:470:39:3c7::2 --> 2607:f8b0:400f:802::200e 76 bytes from 2607:f8b0:400f:802::200e, icmp_seq=0 hlim=119 time=6.146 ms