The content of this topic has been archived on 5 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
I own a OpenWRT router with a rather complex configuration (VLANs, IPv6 tunnels, VPNs, ...). Everything works perfectly most of the time, but I am experiencing intermittent problems, that I suspect are related to wrong MTUs on some interfaces. I know about the "MMS Clamping" / "mtu_fix" options, but I have not found clear information on how and when to use them, or how to debug issues related to MTUs.
Does anybody have a link on information about this subject, please?
Many thanks!
I found this video really helpful in explaining why wan firewall zones use MSS Clamping by default in OpenWrt. In short, it prevents round-trips to a remote server when possible by marking TCP packets with the MTU size of the local client when they go out of the router. This allows a remote server to send traffic back at the correct MTU size without a "MTU Discovery" round-trip.
I own a OpenWRT router with a rather complex configuration (VLANs, IPv6 tunnels, VPNs, ...). Everything works perfectly most of the time, but I am experiencing intermittent problems, that I suspect are related to wrong MTUs on some interfaces. I know about the "MMS Clamping" / "mtu_fix" options, but I have not found clear information on how and when to use them, or how to debug issues related to MTUs.
Does anybody have a link on information about this subject, please?
Many thanks!
I'm sure I won't be of much help, but what are the intermittent problems you're experiencing?
Disclaimer: I'm interested because I'm in the process of setting up a dedicated VPN VLAN and although I'm using MSS Clamping / MTU Fix on my wan zone, I was unclear if I also need to apply it to my VPN tun0 zone. It makes sense why it should be used on wan from the video, but I'm questioning whether it also needs to be applied on a VPN client interface as well and why. Not trying to hijack this thread. Just suggesting that while I understand the concept, it's not clear where it needs to be applied besides WAN.
(Last edited by fecaleagle on 26 Jul 2015, 01:08)
I found this video really helpful in explaining why wan firewall zones use MSS Clamping by default in OpenWrt. In short, it prevents round-trips to a remote server when possible by marking TCP packets with the MTU size of the local client when they go out of the router. This allows a remote server to send traffic back at the correct MTU size without a "MTU Discovery" round-trip.
Very informative, many thanks. Right now I have this parameter active on all "external" zones, and inactive on the "internal" zones. So far, everything seems to be working properly.
eduperez wrote:I own a OpenWRT router with a rather complex configuration (VLANs, IPv6 tunnels, VPNs, ...). Everything works perfectly most of the time, but I am experiencing intermittent problems, that I suspect are related to wrong MTUs on some interfaces. I know about the "MMS Clamping" / "mtu_fix" options, but I have not found clear information on how and when to use them, or how to debug issues related to MTUs.
Does anybody have a link on information about this subject, please?
Many thanks!I'm sure I won't be of much help, but what are the intermittent problems you're experiencing?
Disclaimer: I'm interested because I'm in the process of setting up a dedicated VPN VLAN and although I'm using MSS Clamping / MTU Fix on my wan zone, I was unclear if I also need to apply it to my VPN tun0 zone. It makes sense why it should be used on wan from the video, but I'm questioning whether it also needs to be applied on a VPN client interface as well and why. Not trying to hijack this thread. Just suggesting that while I understand the concept, it's not clear where it needs to be applied besides WAN.
In my case, some websites loaded properly, while others left the browser waiting forever; other protocols besides HTTP worked properly. I also have a VPN server on the OpenWRT router, so your question is also relevant to my interests.
The discussion might have continued from here.