Messages

Update: I changed the NIC from a AOC-STGN-i2S 10 GBe with a Intel 82599 chip and 2x RJ45 SFPs to a Intel i350-T4. Long story short: my MSS clamping issue is gone. I don't need any manual mss entry in the wan interface. Automatic mode works for me with this nic. So I guess it is maybe a driver/kernel issue with some nics? 

@meyergru: your suggestion or how-to is mainly about maximizing the MTU size to avoid fragmentation, which makes sense. But @Deltorek112 and I are dealing with a more basic issue around MSS clamping.

Up until now, neither of us had ever set any MTU or MSS values manually and everything just worked. That's no longer the case, and now we need to adjust things by hand to get stable connections.

As I mentioned in post #20, there's a small difference — exactly 8 bytes — with MSS clamping before and after setting MTU and MSS manually. I think it might be related to the 8-byte overhead from the PPPoE interface. For some reason, the automatic MSS clamping doesn't seem to work properly anymore.

Just guessing here, but: there was an MTU-related change issued here. Could that be connected to the problems we're seeing now?

I've now compared two Wireshark tcpdumps. One was captured while I was still experiencing connection issues. The destination in both cases is a FritzBox connected via IPsec. I believe the behavior is similar with other destinations as well (for testing, I accessed the German adac.de website).

In the problematic dump, the connection starts with an MSS of 1460, which is then reduced to 1374. However, with this MSS, no data is transmitted.

In comparison, the tcpdump I captured today also starts with an MSS of 1460 but gets reduced to 1366. In this case, the connection works correctly, and the website loads as expected.

It seems that something is off with automatic MSS clamping. When neither MTU nor MSS is explicitly set, the connection fails. However, once I manually configure MTU 1500 and MSS 1452 on the WAN interface (not the pppoe interface in advanced), the connection works reliably.

Yes, vlan for pppoe.

Standard vlan device linked with the point-to-point device. Selected PPPoE in WAN / IPv4 Configuration Type, nothing special. I have dual stack on my wan interface, with IPv6 no issues occoured so far as I know, only with IPv4 server.

Set MTU 1500, MSS 1452 in Interfaces / WAN

Here is my ifconfig with wan interface and pppoe:

Code Select Expand

ix1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=4803828<VLAN_MTU,JUMBO_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,HWSTATS,MEXTPG>
        ether XX:XX:XX:XX:XX:XX
        media: Ethernet autoselect (1000baseT <full-duplex,rxpause,txpause>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
        description: WAN (wan)
        options=0
        inet XX.XX.XX.XX --> XX.XX.XX.XX netmask 0xffffffff
        inet6 XXXXXXXXXXXXX%pppoe0 prefixlen 64 scopeid 0x1a
        inet6 XXXXXXXXXXXXXXXXXXXXX prefixlen 64 autoconf pltime 1800 vltime 14400
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>


I encountered similar issues with HTTPS timeouts on some websites. Wireshark indicated a successful TLS handshake, but no application data was transmitted afterward. This led me to suspect an MTU/MSS mismatch.

After some research, I found several posts on forums and Reddit mentioning MTU/MSS-related problems with PPPoE connections. I'm not entirely sure whether the issue already existed in 25.1 and I simply didn't notice it, or if it first appeared for me with 25.7.

As a temporary workaround, I manually set the MSS on the LAN interface to a lower value (e.g., 1200), which resolved the issue partially. However, setting the MSS via the "Firewall: Settings: Normalization" feature had no noticeable effect.

On the WAN interface, MTU and MSS were initially unset. Running ifconfig showed a default MTU of 1500 on the physical interface, and 1492 on the PPPoE interface, which is expected. Once I explicitly set the WAN interface MTU to 1492 and MSS to 1452, all connections, including those over VPN tunnels, began working properly again.

When MTU is set to 1492, the PPPoE MTU is automatically reduced to 1484. I ended up setting the WAN MTU back to 1500 and manually defining the MSS as 1452. With this configuration, all services are currently functioning as expected. ifconfig still reports 1500 on the WAN and 1492 on the PPPoE interface, as before.

For context: prior to this, I never explicitly configured MTU or MSS settings, and everything worked out of the box.