Your second command does kot specify any output interface whereas the first command speciefies tun0. Especially on ESXi you see almost no difference compared ro a vietual Box.

I myself run 1.2.0 in both a Physical and ESXi instance on PPPoE and use the clamping commands successfully on both nodes

In T1245#32694, @c-po wrote:

Your second command does kot specify any output interface whereas the first command speciefies tun0. Especially on ESXi you see almost no difference compared ro a vietual Box.

I myself run 1.2.0 in both a Physical and ESXi instance on PPPoE and use the clamping commands successfully on both nodes

Yes, i purposely left out an output interface on the first command to apply to all interfaces. But also ran one specifying tun0 to make sure it wasn't required.

One thing i've noticed in testing today is that traffic sourced from the VyOS box itself is getting clamped.
But passthrough traffic is not.

My use case is a bit different than a PPPoE connection. I'm using a layer2 bridge that gets piped over a VPN.

My setup is this -

LAN SEGMENT > VyOS eth1 > Br0 > tun0 ---- gre-bridge ---- tun0 > Br0 with layer3 address.

Come to think of it, there isn't any routing involved. Which may be why iptables isn't clamping my MSS.
Thing is this for sure works on a UBNT EdgeRouter. They do the same thing to clamp MSS across the board.

@c-po thanks for mentioning the PPPoE connection, really got me thinking about the word POSTROUTING!
The solution is this -

As mentioned here on StackExchange,
https://unix.stackexchange.com/questions/410112/iptables-not-filtering-bridged-traffic

The problem is that br_netfilter is a separate module in 4.x kernels. UBNT Routers are still 3.x kernels which is why they worked.
I've added the following to /config/scripts/vyos-postconfig-bootup.script

modprobe br_netfilter
iptables -t mangle -I POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

This applies a system wide clamp on MSS, even if the traffic is passing over a bridge to a tun interface without a layer3 address being involved.
This has thus far fixed the problem i was seeing. Now my hit count is incrementing continually with the traffic, and TLS handshakes are no longer failing.

[425:25316] -A POSTROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

Would be nice if we merged this into VyOS, or a way in "set firewall" to turn it on.
Seems to be the only way to do a layer2 bridge over an MTU limited medium, such as an IPSec VPN.

Does anyone have any thoughts on this going forward?

This will be part of a bigger workpackage when the whole firewalling is rewritten. There is yet no ETA.

I also use the same workaround in /config/scripts/vyos-postconfig-bootup.script.

I do not see this as firewall configuration as EsgeOS does it. It should reside under policy routing or as a per interface command like ip mss-clamp in Cisco devices, as we already have interface ethernet mtu command

Sorry i'm not sure we're on the same page.

I'm good with the workaround in /config/scripts/vyos-postconfig-bootup.script.
Adding -
iptables -t mangle -I POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

And EdgeOS configures a line that looks very similar when you do -
set firewall options mss-clamp mss 1400

I see there's a greater conversation there and am fine with using the workaround.

The question i'm proposing now is should we turn on br_netfilter.
In the older kernels, br_netfilter wasn't a thing and iptables would affect transient traffic on bridge interfaces.
In newer 4.x kernels, br_netfilter was created and must be loaded to affect transient traffic.

The use case really being layer2 bridges where you wouldn't route any traffic, you're just bridging between two areas.

br_netfilter should already be compuled as a module. Can you sudo modprobe br_netfilter? To see if it fits your purpose? If so we can autoload it on system bootup

Yes! That's what i need.
In my script above i had to put modprobe br_netfilter so it loads on system boot.

modprobe br_netfilter
iptables -t mangle -I POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

If we could have br_netfilter loaded on boot in the image that would be great and would fix this problem.

Latest rolling should autoload the module

Thank you!
I'll test the next rolling asap and report back.

The last rolling worked great. Saw the module was loaded on boot and MSS was clamped correctly.
Thanks!

@c-po can you backport this to crux, please

Already in 1.2.1