Important for MikroTik users using PPPoE: you may experience erratic issues over IPv6 to certain servers if you do not configure TCP MSS clamping.
TCP MSS clamping is not done automatically for IPv6 when using PPPoE, it only automatically clamps IPv4 by default. MikroTik's documentation for PPP profiles states: "change-tcp-mss - Modifies connection MSS settings (applies only for IPv4)". You can fix this with a simple firewall mangle rule for IPv6, which does the same thing that the default PPP profile does "behind the scenes" for IPv4, but now for IPv6 as well.
Add these rules. They assume that your PPPoE interface is in the interface list "WAN". You could also use out-interface=pppoe-out1 (or whatever your interface name is) instead of out-interface-list=WAN:
You can omit the second IPv4 firewall rule if you are using a PPP profile for your PPPoE client that has change-tcp-mss=yes. But keeping the IPv4 rule as well won't hurt.
Side note: PPPoE Large MTU support (RFC 4638). Many providers support this, including my old provider (Vox on Vumatel). It allows for the PPPoE tunnel to use the full 1500 MTU for packets inside, reducing the need for fragmentation and TCP MSS clamping. You'd simply set your ethernet port MTU to 1508, and the PPPoE client max MTU and MRU to 1500, and it would let you send full-size packets through the PPPoE link as if it was a standard ethernet link. Afrihost on Openserve does not support this, so the MTU over PPPoE maxes out at 1492 bytes. Providers, including Afrihost should really do their best to support this RFC since it alleviates some pain around MTU, fragmentation, and MSS clamping with PPPoE connections.
I hope this helps MikroTik users out there. If you think your IPv6 connectivity is working fine over PPPoE - think again and consider adding this rule. This problem only manifested for me with a certain Microsoft Azure CDN edge server, but it turned out some other sites were silently broken and took longer to load too. I only found out that it was a MikroTik-specific quirk after trying OPNsense and having it work perfectly. Then I figured out this MikroTik TCP MSS clamping quirk that only automatically applies to IPv4. After adding this rule, things are slightly faster and no more stalled/broken IPv6 connections, especially to Microsoft services.
TCP MSS clamping is not done automatically for IPv6 when using PPPoE, it only automatically clamps IPv4 by default. MikroTik's documentation for PPP profiles states: "change-tcp-mss - Modifies connection MSS settings (applies only for IPv4)". You can fix this with a simple firewall mangle rule for IPv6, which does the same thing that the default PPP profile does "behind the scenes" for IPv4, but now for IPv6 as well.
Add these rules. They assume that your PPPoE interface is in the interface list "WAN". You could also use out-interface=pppoe-out1 (or whatever your interface name is) instead of out-interface-list=WAN:
Code:
/ipv6 firewall mangle add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface-list=WAN protocol=tcp tcp-flags=syn
/ip firewall mangle add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface-list=WAN protocol=tcp tcp-flags=synSide note: PPPoE Large MTU support (RFC 4638). Many providers support this, including my old provider (Vox on Vumatel). It allows for the PPPoE tunnel to use the full 1500 MTU for packets inside, reducing the need for fragmentation and TCP MSS clamping. You'd simply set your ethernet port MTU to 1508, and the PPPoE client max MTU and MRU to 1500, and it would let you send full-size packets through the PPPoE link as if it was a standard ethernet link. Afrihost on Openserve does not support this, so the MTU over PPPoE maxes out at 1492 bytes. Providers, including Afrihost should really do their best to support this RFC since it alleviates some pain around MTU, fragmentation, and MSS clamping with PPPoE connections.
I hope this helps MikroTik users out there. If you think your IPv6 connectivity is working fine over PPPoE - think again and consider adding this rule. This problem only manifested for me with a certain Microsoft Azure CDN edge server, but it turned out some other sites were silently broken and took longer to load too. I only found out that it was a MikroTik-specific quirk after trying OPNsense and having it work perfectly. Then I figured out this MikroTik TCP MSS clamping quirk that only automatically applies to IPv4. After adding this rule, things are slightly faster and no more stalled/broken IPv6 connections, especially to Microsoft services.
