MTU on GIF interface
-
@jknott
... just found a bug report in FreeBSD that seems to explain the issue:https://man.freebsd.org/cgi/man.cgi?gif(4)
According to this page the MTU should be set to 1240 . Is there a way to do it manually and not over the web interface ?
-
https://man.freebsd.org/cgi/man.cgi?ifconfig(8)
-
@nogbadthebad
I found the xml file that configures the interfaces. Gonna try i tomorrow. Thx ifconfig works too oc. -
@andi1075 said in MTU on GIF interface:
According to this page the MTU should be set to 1240 . Is there a way to do it manually and not over the web interface ?
As I said, 1280 is the minimum. You can't have less than that for IPv6.
-
But that would be for IPv6 inside the tunnel no?
For IPv4 carried over IPv6 it should be OK. Which is what I understand DS-Lite to be.
-
I put the fritzbox back on and made a :
ping -c 1 -s $((1500-28)) -M do whatever.weresult was:
From 192.0.0.2 (192.0.0.2) icmp_seq=1 Frag needed and DF set (mtu = 1452)and yes, its ipv4 inside a ipv6.
I am confused. If I set the size to 1280 (with pfsense) I can't reach some side or the internet is really slow. Set the 1240 manually and I check it out tomorrow.@JKnott
yes u are right, MTUs smaller than 1280 aren't supported by IPv6 ... let me check the results tomrrow. -
Which MTU are you talking about? The interface? Or the tunnel? Yes, the tunnel could be less than 1280, as low as 576, if it carries only IPv4. However, my understanding was he was referring to the WAN interface, not a tunnel. If so, it would have to be at least 1280. Or is the tunnel for IPv6? I doubt it with dual stack lite.
Here's what Wikipedia says about DS Lite:
Dual-Stack Lite technology does not involve allocating an IPv4 address to customer-premises equipment (CPE) for providing Internet access.[22] The CPE distributes private IPv4 addresses for the LAN clients, according to the networking requirement in the local area network. The CPE encapsulates IPv4 packets within IPv6 packets. The CPE uses its global IPv6 connection to deliver the packet to the ISP's carrier-grade NAT (CGN), which has a global IPv4 address. The original IPv4 packet is recovered and NAT is performed upon the IPv4 packet and is routed to the public IPv4 Internet. The CGN uniquely identifies traffic flows by recording the CPE public IPv6 address, the private IPv4 address, and TCP or UDP port number as a session.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
@andi1075 said in MTU on GIF interface:
I am confused. If I set the size to 1280 (with pfsense)
Any interface that supports IPv6 cannot have a MTU less that 1280. The tunnel MTU can be no more than the IPv6 MTU less the tunnel overhead.
I used to use a tunnel to get IPv6. On that, the tunnel MTU was 1280 and my LAN & WAN MTUs were 1500.
-
Good morning,
I gave up (frustrated) ... after reinstalled pfsense I wasn't able to get any ipv6 though any more.
It seem like ppp works fine and after that - nothing. pfsense says interface went down since it wan't reachable (100% loss). Packet capturing just stays empty ..... no packets on WAN.Maybe its the media converter that went bad. No idea. Thx anyways and : very nice explanation about ds-lite ! I appreciate the time and effort u guys put into helping me.
Status: up
PPPoE up Uptime: -
IPv6 Link Local
fe80::ec73:14ff:fe15:1d4a%vtnet1
Gateway IPv6
fe80::fe33:42ff:fe21:7aca
MTU
1440
In/out packets
0/8 (0 B/840 B)
In/out packets (pass)
0/8 (0 B/840 B)
In/out packets (block)
0/0 (0 B/0 B)
In/out errors
0/0
Collisions
0... this one was with MTU set to 1440 ... same result with any regular 1492.
-
@andi1075 said in MTU on GIF interface:
... this one was with MTU set to 1440 ... same result with any regular 1492.
It doesn't hurt to set the MTU low for testing and then put it up to what it should be for the connection, when everything is working.
-
@jknott said in MTU on GIF interface:
Which MTU are you talking about? The interface? Or the tunnel? Yes, the tunnel could be less than 1280, as low as 576, if it carries only IPv4. However, my understanding was he was referring to the WAN interface, not a tunnel. If so, it would have to be at least 1280. Or is the tunnel for IPv6? I doubt it with dual stack lite.
The tunnel interface, gif0. That is what determines the MTU for traffic through it. And for DS-Lite that is IPv4 traffic. The tunnel itself is carried over IPv6. Thus it should be possible to set it to less that 1280 as long as the gif interface does not have an IPv6 address. Unless I'm missing something, which is always possible!
But anyway looks like it's solved.
-
Hello again,
I was able to figure out what my issue with the ipv6 was. So that's solved. I still have no clue about the OPT1 (GIF) Interface. I lowered the MTU to 1280 and got corrupted packages. So I raised it 1452 and I was able to send packages but still had the isse that my apple products cant receive some https sides (no not related to dhcp, pinging it works fine).
ping -M do -s 1432 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1432(1460) bytes of data.
ping: local error: message too long, mtu=1452-> This looks ok for me since I set the tunnel to 1452.
-> My provider gives me 1492 on my pppoe interface- Am I mistaken if I assume that my max tunnel size would be 1472 ( since I have to substract the ipv4 header from the max tunnel size) ?
- If so can I somehow mangel packets or shouldnt that be done automatically be the fw ?
Thx in adavance.
A
-
I GOT IT !
enabled MSS clamping to 1440.
So settings for Wemag, if anyone is reading this post :
WAN:
-> DHCPv6
-> MTU 1492
-> prefix /64LAN:
leave untouched (...well, apart from the ipv6 setting - tracking WAN and so on- )GIF:
MTU 1472
MSS clamping: 1440now everything seems to work as it should. tbc.
Thank u @JKnott and @stephenw10
