This is probably an old issue, as we were many versions behind in our network.

I have recently updated a few MT routers to 40.1. In the process of updating them my PPPoE clients stopped working properly. Some websites would load while others would not etc.. Upon investigation, the rule that originally was a dynamic MSS rule was gone. Ok, that's fine. (i see it's not needed now as of ver 39) But why would an upgrade (break) pppoe? I understand that mss is somehow internal to pppoe now. But what would need to be changed, or better yet, why didn't MT have some kind of rule in place to upgrade the router settings to not break pppoe upon an upgrade?

Once I put my mss rules back in to my routers, all was well again.

What do we need to do to take advantage of the internal change that removes the dynamic mss rule? And will this be fixed in future firmware so that we don't have to manually adjust things to keep our network running after an upgrade.

Did you find a solution?

Check the changelogs. I suspect you'll need to contact MT about this.

I recall some version change where dynamic MSS rules was removed, and it is now apparently handled internally inside PPP itself.

What is the MTU/MRU/MRRU configuration on router? What exact rules did you add to make it work again?

Have you tried to sniff packets on another device behind this router to see MSS when Mangle rules are not there and when they are? Are you sure that change-tcp-mss is enabled on PPP Profile used for connection?

So. If you build a PPPoE concentrator in a lower version, we used all of the defaults from that. So change mss is set to "default", and not explicitly set to "yes".

I added these to get my PPPoE customer to work properly again.
/ip firewall mangle> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=forward action=change-mss new-mss=1440 passthrough=yes tcp-flags=syn
protocol=tcp out-interface=all-ppp tcp-mss=1441-65535 log=no
log-prefix=""

1 chain=forward action=change-mss new-mss=1440 passthrough=yes tcp-flags=syn
protocol=tcp in-interface=all-ppp tcp-mss=1441-65535 log=no log-prefix=""

These above, are the same firewall rules that were dynamically added to previous versions of MT. I just manually entered them back in to the router after an upgrade where these rules were removed.
We had customers who couldn't load certain web sites. Other would work fine. It was an apparent MTU rule, as soon as I entered these back in, the customer he access again. We were updating from versions well before .39 (which is where I think MSS was changed in MT to not need mangle) And maybe it doesn't. "IF" you build your PPPoE concentrator after that. These of course were built prior to this change in MT, and I think it doesn't work correctly after an upgrade. Or at least apparently is does not work properly.

Are you running 6.40.x version? If you enable change-tcp-mss on PPP/Profile and get rid of these Mangle rules does it work properly?
Starting from 6.39 we have this:
!) ppp - implemented internal algorithm for "change-mss", no mangle rules necessary;
Later versions had more improvements and now starting from 6.39.2 change-mss should work without any problems. If you have later RotuerOS version, change-mss is enabled and you can sniff packets and see that MSS is higher than tunnel MTU/MRU-40bytes, then please write to support@mikrotik.com

Yes we are on 6.40.

The problem is when I updated a handful of routers, my customers stopped working. MT should have "change mss" to "ON" by default in later versions so that this doesn't happen to people upon an update. Manual intervention after an update to fix a problem i didn't have before is troublesome to say the least.

That's the entire point to my post.

Are you running 6.40.x version? If you enable change-tcp-mss on PPP/Profile and get rid of these Mangle rules does it work properly?
Starting from 6.39 we have this:
!) ppp - implemented internal algorithm for "change-mss", no mangle rules necessary;
Later versions had more improvements and now starting from 6.39.2 change-mss should work without any problems. If you have later RotuerOS version, change-mss is enabled and you can sniff packets and see that MSS is higher than tunnel MTU/MRU-40bytes, then please write to support@mikrotik.com

Our original defaul configurations by MT, when adding a new PPPoE server are 1480 mtu and mru.

I updated a couple more routers two night ago, and selected "change mss" to on on the profiles. Customers still didn't have any service.
It wasn't until I added the previously mentioned mangle rules that it started to work.
Can you tell me why that is?

strods,please explain how to calculate MSS for PPPOE (chap). MSS = MTU-40 or MSS = MTU - 44 ? The information found on the Internet varies in the amount of 40 or 44. Thanks.

What is the MTU/MRU/MRRU configuration on router? What exact rules did you add to make it work again?

What should be on client side and ppooe_servers? 1480/1480/1600 are these correct ?

Have you tried to sniff packets on another device behind this router to see MSS when Mangle rules are not there and when they are? Are you sure that change-tcp-mss is enabled on PPP Profile used for connection?

i have also no any mangle rule on firewall and change-tcp-mss is enabled on PPP Profile on the ppooe_servers.
how can i understand if it is work correctly ?

What is the MTU/MRU/MRRU configuration on router? What exact rules did you add to make it work again?

What should be on client side and ppooe_servers? 1480/1480/1600 are these correct ?

Have you tried to sniff packets on another device behind this router to see MSS when Mangle rules are not there and when they are? Are you sure that change-tcp-mss is enabled on PPP Profile used for connection?

i have also no any mangle rule on firewall and change-tcp-mss is enabled on PPP Profile on the ppooe_servers.
how can i understand if it is work correctly ?

You will know because some web sites will load, and others won't. The behavior of your customer connections will be strange and unpredictable. Like most MTU issues when they occur.

My problem stems from already having made PPPoE servers, (with default MT settings for mtu and mss clamping). Then when I upgraded, my PPPoE customers don't work any more. So going from defaults, to defaults, something has broken in the code from MT's side of things. Although, they apparently don't think so, and I'm supposed to figure it out for them I guess.

My customers were magically fixed when I added the mangle rules back in that the newer version strips out. As those rules previously were dynamically added by MT. New versions exclude them it seems..

Have same problem with about 1K users
updated our 4 concentrators this night and now we have massive problems with https sites and MTU discovery has some problems on some client router types
Last version we where running 6.37.5 worked fine but had some other problems

We did an upgrade to the actual bug fix only 6.38.7 on our PPPOE Server and run into problems. Customers get bad/flake/no connections. They are pingable but I guess some MTU related stuff kills them. We cant realy find the problem as the CPEs have another problem with fragmentation.

Downgrade to 6.37.5 solved the problem.

Dont like bugfix only versions to introduce problems .

After yesterday's "URGENT security advisory" from Mikrotik I upgraded my PPPoE Servers to 6.40.6 and now same thing: MSS mangle rules gone and service broken!

Please help!

After yesterday's "URGENT security advisory" from Mikrotik I upgraded my PPPoE Servers to 6.40.6 and now same thing: MSS mangle rules gone and service broken!

Please help!

write it manual may help you;
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn

So was anything ever resolved or figured out on this ? We had an x86 v6.32 ROS PPPoE (MSS Clamping default on server so no mangle/firewall rules at all and disabled on client edge devices) that ran amazing until the server suddenly died. Replaced it with a CCR v6.42.2 and clients with edge device set to disabled MSS Clamping could not go to "any websites at all" nothing worked. Turned on MSS Clamping on the client devices and they could go everywhere but sporadically they will suddenly not be able to go to many sites (Netflix , Yahoo Mail , many others) while being able to go others just fine. Anything that forces their device to make a new PPPoE connection fixes the problem, until it happens again.

V6.32 MTU 1492 / MRU default / MSS Clamping Default (Disabled on client devices) Ran amazing for almost 10 years

V6.42.2 Forced to change to MTU 1480 / MRU 1480 (can not leave on default or PPPoE auth problems) / MSS Clamping On or Default makes no difference that we can tell. Also forced to enable MSS Clamping on devices that have the option (or they can not go anywhere at all, no websites work). Clients on these devices still randomly lose ability to go to many websites (always the same ones Netflix, Yahoo Mail, etc...) until PPPoE connection is dropped / reconnected.

Note that clients on our FTTH (connecting to a different PPPoE server in the same router) that use Netgear/Belkin/Windows etc... PPPoE client works fine on the old MTU 1492 / MSS Clamping Default settings and they continue to work fine other than we had to set MRU to 1492 instead of leaving it at default. In fact if we change these clients to 1480/1480 they start randomly having the "can't go to many websites" problem.

The MSS Clamping Default / On seems to do nothing.

So I guess the reason I'm here is I have been unable to resolve the problem where a client suddenly can't go to many websites until their PPPoE connection is reset (I'm also curious why I had to change MTU/MRU to 1480 after running 1492 for many years). Did MT ever confirm they broke something or do I need to just either downgrade back to 6.32 or try some of the mangle firewall rules I see here ?

No answer to this. Are the additional clamping rules still needed?

I think I've also seen this issue on 6.40.8 and 6.42.9

Is there a workaround other than re-inserting the mangle rules manually, or running on an MTU of 1500 for pppoe (which also worked as a fix)