I have a client who is connecting via PPPoE through our Mikrotik PPPoE Server. He has a problem accessing one secure citrix site... Now before you all jump to tell me "well change the MTU or MSS size silly" please read on.

When attempting to connect to the server in question, we'll call it ra.fubar.com, the connection times out repeatedly. No response when trying to access via a web browser, or telneting to ra.fubar.com on port 443. Just times out.

When hooking a packet sniffer up to the client while trying to connect to the server, it's as the error message says... I see the SYN packet sent to the server, but no SYN ACK back, nothing back to be exact.

Change TCP MSS is enabled on the MT PPPoE Server, and running ROS 2.9.42. I've had the client change the MTU to various sizes (starting at 1400 and going down from there) to no avail. I know due to certain Network Admins who like to block all ICMP traffic, can will cause problems with PMTU-D so this is why I tried lowering the MTU. Still nothing no response.

Here's the kicker, I can access https://ra.fubar.com from a server that is connected to the same switch as my PPPoE concentrator. The server is not connecting via PPPoE, and is using a standard MTU size of 1500.. Default MTU size on my PPPoE Server is 1480 (again I've already tried various MTU sizes on the client router).

So the problem has to be either with the PPPoE server. Or somehow the packets are getting dropped by the remote connection. Which I know not to be the case at least from an IP address standpoint (ie: they're not filtering my subnets)..

Now the packets could get getting dropped due to fragmentation, or some other filter but im just not sure... If anyone has any ideas on what may be going on here, I'd greatly appreciate it. I feel I've exhausted option thus far...

thanks.

also, I've tried clearing all my firewall filter rules on the PPPoE server to rule out any possibility of a mistake in one of the rules, but I'm not blocking SSL. Even with all the rules disabled this still did not work.

DNS resolves to the correct IP address, and I can trace route to the secure server, well, just before it because the server does not respond to ICMP. I can not ping the server, because of the ICMP filter they have in place.

Again I can access this site from virtually any other connection than those that are connected through my PPPoE concentrator. This is the first time I've run into this type of problem that wasn't fixed by simply lowering the MTU size.

if you use the ppp profile feature to adjust the mss, you need to know that it is broken. Next, Cisco PIX firewalls running one of the later versions of software will drop packets with tcp mss unconditionally adjusted.

cisco sux !

if you use the ppp profile feature to adjust the mss, you need to know that it is broken. Next, Cisco PIX firewalls running one of the later versions of software will drop packets with tcp mss unconditionally adjusted.

Where is the best place in the MT to adjust mss then?

Is something like this good (adapted from another post)
I also disabled change-tcp-mss in the /ppp profile. (If I left that enabled, it would further decrease the mss.) With either change-tcp-mss setting, certain sites would still not work.

http://svartifoss2.fcc.gov/cgi-bin/ws.e ... bsmenu.hts

is one of the sites that works problematically when over pppoe. Does this mean svartifoss2.fcc.gov has broken mtu path discovery? I thought the change mss mangle was supposed to fix that. The main problem was when you tried to apply certain changes using a web form.

Each hop on my network from the customer is a real IP and is pingable - we don't block any icmp, so I doubt the problem is at my end.

To get the customer working, we put them on a non-pppoe IP address and I also had to disable the mangle rule posted above for things to work. Any suggestions.

change-tcp-mss unconditionally alters mss. let me give you a short example.

USER--(1480)--NAS--(1500)--{inet}--(1500)--FW--(1400)--WWW


USER sends TCP syn with mss of 1460
NAS sets mss to 1440
FW adjusts mss to 1360
WWW replies with TCP syn+ack with mss of 1360
NAS set mss unconditionally to 1440
USER now thinks remote mss is 1440 and not 1360
[ conversations stalls sometime after this ]

Thus broken.

TCP mss should only be adjusted to a lower value and never increased.
TCP mss must never be unconditionally set.

so..

/ppp profile set 0 change-tcp-mss=yes

needs to be changed to

/ppp profile set 0 change-tcp-mss=no


?

I ended up rebuilding my routing tables on all of my routers because there was some questionable routes to support some segments of the network that hadn't been switched to PPPoE that I assumed was causing the problem.. It fixed it for the the connections going through one of my routers i was able to access the website in question... Now I just need to check with the customer and verify it's fixed on his end as well.. He's going through a different PPPoE concentrator/router than my office connection.

I have the change-tcp-mss setting set to yes on the router my office is connecting through.. so from what I understand from your post I should disable this and not adjust the MSS at all?

I may try this if he's still experiencing the problem on his end...

not entirely correct

you really should adjust mss but you can't use the change-tcp-mss= feature. you are then left with the option of doing it manually.
adding a clamp-to-pmtu rule in forward mangle rule will only adjust mss one way. for it to work you need to use it on both ends of the pppoe session, which is not always feasible.
or, you could adjust mss manually according to the lowest of your link mtus.

Example of how the dynamic change-tcp-mss rules *should* have been.