TLS problems with inbound routing via GRE

Hi everyone,



I’m running a multi-homed provider and recently subscribed an anti-ddos solution which allows me to announce my /24 prefixes through their network via GRE tunnel so they can scrub the traffic.

Basically, the traffic enters my network through the GRE tunnel and exits through my fiber provider’s gateways.

Everything seems to work fine until today a customer complaints he can’t clone a bitbucket repo via HTTPS. I investigated, and as soon as I announce their /24 back through my usual fiber providers everything works.

During the issue All I see is “connection reset by peer” but running

curl -I https://raw.githubusercontent.com

fails as well until I announce the route back with the fiber provider.

I came to the conclusion that bitbucket (along with other services I guess) doesn’t allow asymmetric routing because it looks like a spoofed connection to them. Either that, or a MTU issue with the GRE tunnel. I tried to set

new-mss=clamp-to-pmtu

through some mangle rules, but didn’t work.

What do you think?

I would first force the MSS to some insanely low manually set value (like 1000) and check that the traffic did match the rule. Only if it matches and the https connection nevertheless fails, I’d follow the non-symmetric routing investigation path.

clamp-to-pmtu does not cover all the possible MTU-related issues.

I’m 100% sure the problem is the GRE.
I just made a simple test by forcing a prefix to enter via a fiber provider and exit via another, reproducing thus the asymmetric routing: the problem doesn’t happen.

Hi,

I solved with the following mangle rule:

/ip firewall mangle
add action=change-mss chain=forward log-prefix="" new-mss=1436 passthrough=yes protocol=tcp src-address=xxx.yyy.www.zzz/24 tcp-flags=syn tcp-mss=1437-65535

where xxx.yyy.www.zzz is one of my own prefixes