By Default, in PPPoE profile, we leave this option turned on always:
Scenario:

Internet-------Etherreal.Sniffer------MT.PPPoE.Server(change-tcp-mss=yes)----DLINK(NAT)----MT.PPTP.Server--------MT.PPTP.Client------WindowsClient

ALL MT Versions 2.9.27

1) Windows Client cannot surf many websites (eg http://www.stuff.co.nz and http://www.xtra.co.nz)
2) Etherreal sniffer shows TCP Syn packets with MSS=1452 due to the above MSS rule at the PPPoE Server.
(NOTE: MSS MUST be 1400 or below to function properly due to the PPTP link in the 'loop')
3) Delete the dynamic MSS rule in the PPPoE Server and the Windows client can happily surf ALL websites (Etherreal now shows MSS as 1400 as it should, as the PPTP link is re-writing the MSS to 1400 as it should)
4) Delete the dynamic rule and manually add a MSS rule for the client of 1400 and the windows client can still surf all websites properly. (again, Etherreal shows MSS as 1400 as it should)

Verdict:
change-tcp-mss=yes re-writes the MSS value of ALL TCP SYN packets to the new value. I think this is bad. It this a feature or a fault ?

Shouldnt this rule only re-write the MSS value of TCP Syn Packets that are larger than whatever the rule is set to ?

How can we make a rule to rewrite the MSS only if the existing MSS is bigger? There are no FW matchers for existing MSS value.

Feature, you may check for 'ip firewall mangle print dynamic' to check that dynamic rules (it changes tcp-mss for certain out/in interfaces).
You are able to specify to PPPoE/PPTP server, which profile to use with change-tcp-mss=yes or no.

Yes, I understand that. I will try to explain again:

What we dont understand is why the MSS rule re-writes every packet to the new MSS. It should only re-write the MSS if the original MSS is greater than the MSS that the rule specifies

READ: a TCP SYN MSS rule should only ever re-write the MSS to a LOWER value, never a HIGHER value as it sometimes does now.

EG number 2: I have a dynamic 'change mss' rule for a PPPoE client (added automatically because the default pppoe profile has 'change TCP MSS' ticked. This rule is 40 below the operating MTU and is automatically set to 1452. OK thats fine PROVIDED that the maximum MSS for the entire end to end connection is 1452 or lower. In many cases this doesnt work because the client might be behind a different PPTP connection that requires an MSS of 1400 or below.

So what happens is, the client way down the chain who needs an MSS of 1400 is getting his MSS re-written by our PPPoE server to a larger value of 1452 and therefore he cannot browse many websites.

Use different 'ppp profiles' for different services.

Are you absolutely sure it rewrites all tcp mss packets and that there is no issues with the order?

I noticed TCP MSS rewriting was broken in later v2.9.2x versions for my vpns but I chalked it up to programmers lack of network knowledge.

In all fairness, i can't expect programmers to understand network problems. Those are two different worlds.

It's a pitty too, because issues like these exclude routeros from being the linux gui of choice for some.

Absolutely, positively sure, well with version 2.9.27 at least.

With no mangle rules:

/ip firewall mangle print all shows NOTHING
Etherreal sniffing a client with MSS of 1400 = MSS of 1400
Client can surf happily


With the two default rules added by PPPoE profile for same client:

/ip firewall mangle print all
0 D chain=forward in-interface=<pppoe-xxx@xxxxx.xxx.xx> protocol=tcp tcp-flags=syn action=change-mss new-mss=1452
1 D chain=forward out-interface=<pppoe-xxx@xxxxx.xxx.xx> protocol=tcp tcp-flags=syn action=change-mss new-mss=1452
Etherreal sniffing a client with MSS of 1400 = new MSS of 1452
Client cannot surf many websites

The simple option, most people would think, is to simply switch off the MSS rule completely. Unfortunately this is NOT an option because many customers linksys routers require this rule to function properly.

1) First option,
'interface pppoe-server server> set 0 max-mtu=1440 max-mru=1440'
Dynamic rules created with 1400 TCP MSS.

2) Second option adding static mangle rule,
/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn action=change-mss new-mss=1400

I have considered this option, making every client on the network operate with an MSS of 1400.....

However, wouldn't this create a lot more overhead ?

Forcing all clients to one mtu+mru would permit you to optimize for that scenario. That would leave you with less overhead as long as they are all at one setting. HOWEVER, the MSS adjustment feature is still broken and it will create complications whenever someone tries to access your subscribers IP's from an external connection with smaller mtu, if you choose to use that (mis)feature.

In my (not so) humble opinion there should be no tolerance for broken behavior.

Im Blind. There is indeed a matcher for existing TCP MSS in 2.9.27 (probably earlier versions of 2.9 too)

Everything is now fixed at the PPPoE Server by doing two things:

1) 'Change TCP MSS' should equal 'No' in the PPPoE server profile
2) Add one rule to the firewall:
I suggest the MT people make the dynamic profile MSS mangle rule match and re-write the MSS only if the original MSS is bigger.

Well yes, but this wont work properly if someone logs in with an mtu that is < 1452. ( another half-way-there hint: new-mss=clamp-to-pmtu )

In this case we are lucky.... all our managed connections have an originating MSS of either 1400 or 1460 - nothing else.

So now, just the 1460's get their MSS changed down to 1452 and the 1400's remain unmodified.

Otherwise that's very true. The dynamic MSS rule really needs to have the matcher so the rule can only ever lower the MTU, not raise it.

EG the dynamic 'Change TCP MSS' rule should really do this: Instead of what is currently does: Bugfix for 2.9.28 Please MT programmers ?