

Not sure what your setup is trying to do, but I run a double tunnel, and it is not usable without clamping the mss! Even when I set the correct link mtu, I still see in wireshark that the envelope IP packets get fragmented. The packets still get delivered, which is good in a way since it lets many internet services work albeit at half the speed, EXCEPT that most (but not all) TLS connections fail to progress past the handshake. It is as if TLS is trying to squeeze an entire certificate into a single packet and refuses to work if that packet gets fragmented, even if all the fragments arrive intact. This fails silently, with the browser window just spinning forever for example.
However if I set mtu AND clamp mss like this:
ip link set tun1 mtu 1420
ip link set tun2 mtu 1340
iptables -t mangle -A FORWARD -o tun2 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t mangle -A FORWARD -i tun2 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Then the packets do not get fragmented, every service including TLS works perfectly, and I get 90% of full tunnel-less bandwidth. I use wireguard, not OpenVPN, and testing with wireshark shows that a single wireguard wrapper is about 80 bytes. The iptables --clamp-mss-to-pmtu option is equivalent to OpenVPN’s mssfix option if I recall.
Yep, that’s how the calculation goes! You only need mssfix on the innermost tunnel, and the outer tunnel will stay under the limit naturally. Mssfix only works on TCP, so it wouldn’t work on the VPN packets themselves anyway, inside the outer tunnel. OpenVPN/wireguard use UDP. By the way, does Discord use UDP at all? I don’t know what’s the proper way to limit the size of UDP packets in a situation where pathway mtu discovery is the problem/issue. I only know the trick with TCP and clamp-mss. Is there a way to tell discord to force use TCP only? Also, can you be sure that Discord service itself doesn’t block your commercial VPN?