I recently had some issues with MTU with one of my customers using Microtik Firewall/Router that we built.

We provide them with ADSL and put the ADSL Modem/Router into bridge mode, and used the PPPoE client on the MT box to connect up to us.
Using the Change TCP MSS NEVER worked correctly for us.. and the ONLY way I ever got it to work was to put a Single Static mangle rule in the firewall setting MSS to 1452. I've looked at the stuff that change TCP MSS does in the PPPoE client, it makes 2 dynamic rules, 1 on incoming on the pppoe interface and 1 on the outgoing.. The MTU for one of them never would go below 1460 or looked to be locked into 1460, the other would take the MTU specified in the PPPoE client minues a value of 40. The manuall rule I did wasn't bound to any specific interface, and that was the only way I could get it to work..

Now, next part. Customer tried to goto a bank site with SSL and used some sort of RSA security, it would make it through both passwords check and hang.. we only got it to work by converting the ADSL modem back to a PPPoE client/router and route a subnet to the MT box, thus indicating to me, that it's something to do with MTU or the PPPoE.. and I think it's MTU..

So, Why does the Change TCP MSS work correctly, and what would have caused the issue with the bank site.. I think the MTU for the ADSL is 1492 before PPPoE.

Thanks, Billy

Connor9220,

Try the following rules...

/ ip firewall mangle
add chain=forward tcp-flags=syn action=jump jump-target=mss comment="\[tcp\], mss" disabled=no
add chain=mss protocol=tcp tcp-flags=syn tcp-mss=!536-1460 action=change-mss new-mss=1440 comment="\[tcp\], mss fixation" disabled=no
add chain=mss protocol=tcp tcp-flags=syn tcp-mss=1453-65535 action=change-mss new-mss=1440 comment="\[tcp\], mss 1440 for mtu 1492" disabled=no
add chain=mss protocol=tcp tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu comment="\[tcp\], mss clamp-to-pmtu" disabled=no
add chain=prerouting action=change-ttl new-ttl=set:65 comment="\[tcp\], mss ttl fix" disabled=no

Matt

This is crazy, why do we need to do all that?? There is a option under the PPP Profile section that says Change TCP MSS, but it doesn't work correctly. It makes 2 mangle rules 1 in each direction bound to the PPPoE interface, but they're different, and apparently binding them to the PPPoE interface doesn't work correctly. Further more, from my research, they're setting MSS on every packet instead of packets that are greater than the mtu requested. What's the point of having this option if it doesn't work? Why do we have to jump through hoops to get PPPoE to work correctly?

Connor9220,

From my understanding the problem isn't the pppoe server, it's the client end router that causes the issue when they don't have their MTU set to a setting that isn't set to < 1480. Most routers today assume that all servers allow for a MTU packet size of 1500 which isn't true. What i've ended up having to do is put these rules in all my pppoe server's then the client routers that we setup, change their MTU settings in their routers to 1476.

I know completely where you are coming from. This MTU problem though is known to all router manufactures. What really needs to happen is manufactures all need to get their crap together and use a standard MTU size of 1480 or less. This would make everyones life's easier.

Matt

At this point. my MT IS acting as the PPPoE client, not the server, and my normal ADSL routers have no issues working.. They just do. In fact, to get around this issue, I turned my router from a bridge back into a PPPoE client and used it as a normal router and burned a extra /29 CIDR on the customer. Something with how MT handles MTU isn't correct either.

Dear Connor9220,

ADSL Routers are made for plug n play, so that normal users dont have to do much tweaks to get started..MT is for enterprise environment so you have to do all this to get full control on your Router. got my point??

regards,
Asad

where do i put the 4 mss rules after of my mangle (mark routing) rules for msn and http....??????? and another Question in the profile what do i have to put change tcp mss to yes or no if i want to put these rules ??

where do i put the 4 mss rules after of my mangle (mark routing) rules for msn and http....??????? and another Question in the profile what do i have to put change tcp mss to yes or no if i want to put these rules ??

Proggams2,

I put the rules at the very top before all the over rules, that way it modified the packet before mangling it for HTTP and so on. In profile set change tcp mss to "no".

Matt

Using the Change TCP MSS NEVER worked correctly for us.. and the ONLY way I ever got it to work was to put a Single Static mangle rule in the firewall setting MSS to 1452. I've looked at the stuff that change TCP MSS does in the PPPoE client, it makes 2 dynamic rules, 1 on incoming on the pppoe interface and 1 on the outgoing.

Have been saying it for a while. That feature is broken and wont permit pathmtu's lower than, in your case, 1492.

Now, next part. Customer tried to goto a bank site with SSL and used some sort of RSA security, it would make it through both passwords check and hang.. we only got it to work by converting the ADSL modem back to a PPPoE client/router and route a subnet to the MT box, thus indicating to me, that it's something to do with MTU or the PPPoE.. and I think it's MTU..

If path-mtu is lower than, in your case, 1492 then this will happen as your connection will more than likely break further up the path network.

So, Why does the Change TCP MSS work correctly, and what would have caused the issue with the bank site.. I think the MTU for the ADSL is 1492 before PPPoE.

ADSL? ATM has a packet MTU which is much much smaller than Ethernet. But your IP MTU can be much much larger than Ethernet. ADSL runs PPPoA which is not limited to 1492.

thank you so much and another question if anyone knows . why when i give a 256k connection to someone the transfer rate on the computer is slow u dont feel its fast in downloading , its not a problem with my computer im sure . is it a problem with mtu or something ? plz im w8ing fou u guys

that can be a million things.

no im sure that everything is ok. i have the internet coming to my MT is PPPOE and i give the clients pppoe and the pppoe client has (1480/1480) and the pppoe server give my clients (1480/1488). do i have to change something with the mangle rules above ?

anyone ???

no im sure that everything is ok. i have the internet coming to my MT is PPPOE and i give the clients pppoe and the pppoe client has (1480/1480) and the pppoe server give my clients (1480/1488). do i have to change something with the mangle rules above ?

Proggams2,

You should be ok without changing and mangle rules.

Matt

Connor9220,

Try the following rules...

/ ip firewall mangle
add chain=forward tcp-flags=syn action=jump jump-target=mss comment="\[tcp\], mss" disabled=no
add chain=mss protocol=tcp tcp-flags=syn tcp-mss=!536-1460 action=change-mss new-mss=1440 comment="\[tcp\], mss fixation" disabled=no
add chain=mss protocol=tcp tcp-flags=syn tcp-mss=1453-65535 action=change-mss new-mss=1440 comment="\[tcp\], mss 1440 for mtu 1492" disabled=no
add chain=mss protocol=tcp tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu comment="\[tcp\], mss clamp-to-pmtu" disabled=no
add chain=prerouting action=change-ttl new-ttl=set:65 comment="\[tcp\], mss ttl fix" disabled=no

Matt

Is just wonderfull !!!! I solve my problem of random page load !!! many thanks to you guy !!!!!!!!!!!!!!!!!!!

PLEASE READ THIS: If you think have an DNS issue, error 404, pages don`t load and you know they are online, please try this mangle rules.

those mss rules are my rules! from an earlier post!

except for the ttl rule, i think the ttl one might too easily lead to ttl loops.

what ttl rule you suggest??? it works fine for me, thanks.

well, none. a route loop mistake involving that router and you'll have a packet storm that wont subside until the router reboots from the stress.
i'm not as worried about the detrimental effects of traceroute as much as i'm worried about what would happen if the wrong interface (local interface) no longer was in running state. what would happen then is packets from the internet, destined to your network, would bounce between your router and the upstream router (following default gateway) until something broke down.
but you know your network best, of course.

Connor9220,

Try the following rules...

/ ip firewall mangle
add chain=forward tcp-flags=syn action=jump jump-target=mss comment="\[tcp\], mss" disabled=no
add chain=mss protocol=tcp tcp-flags=syn tcp-mss=!536-1460 action=change-mss new-mss=1440 comment="\[tcp\], mss fixation" disabled=no
add chain=mss protocol=tcp tcp-flags=syn tcp-mss=1453-65535 action=change-mss new-mss=1440 comment="\[tcp\], mss 1440 for mtu 1492" disabled=no
add chain=mss protocol=tcp tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu comment="\[tcp\], mss clamp-to-pmtu" disabled=no
add chain=prerouting action=change-ttl new-ttl=set:65 comment="\[tcp\], mss ttl fix" disabled=no

Matt

So... its working for me for a time, but then i stops all them an add the only rule:
add chain=forward protocol=tcp out-interface=cityconnect tcp-flags=syn action=change-mss new-mss=1300

and it work just fine.

Connor9220,

Try the following rules...

/ ip firewall mangle
add chain=forward tcp-flags=syn action=jump jump-target=mss comment="\[tcp\], mss" disabled=no
add chain=mss protocol=tcp tcp-flags=syn tcp-mss=!536-1460 action=change-mss new-mss=1440 comment="\[tcp\], mss fixation" disabled=no
add chain=mss protocol=tcp tcp-flags=syn tcp-mss=1453-65535 action=change-mss new-mss=1440 comment="\[tcp\], mss 1440 for mtu 1492" disabled=no
add chain=mss protocol=tcp tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu comment="\[tcp\], mss clamp-to-pmtu" disabled=no
add chain=prerouting action=change-ttl new-ttl=set:65 comment="\[tcp\], mss ttl fix" disabled=no

Matt

So... its working for me for a time, but then i stops all them an add the only rule:
add chain=forward protocol=tcp out-interface=cityconnect tcp-flags=syn action=change-mss new-mss=1300

and it work just fine.

Why would you fragment your packets that small?

Matt