My relearned lesson for the day: when Linux networking weirdness occurs in a NAT environment, remember to try MTU clamping.
Thanks to the comments by Justin and Sesse, I was fast-tracked to the core of the problems I have been experiencing since Thursday, MTU issues. What's worse (from my pov) is that I have encountered this issue before with the provider I had in Timișoara, but, since that ISP was using PPPoE and my current ISP in Bucharest doesn't, I never really made the connection. I even had a commented out iptables rule for MTU clamping in my firewall script.
The rule I am talking about looks like this:
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $EXT_IF -j TCPMSS --clamp-mss-to-pmtu
or like the one I have been using (seems more logical to me):
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Note that this is not a fix, but a workaround and the real problem is over-zealous admins or weird setups[1] which think that banning TCP fragmentation (or the entire ICMP traffic) is a way to secure networks.
Once again, thanks to everybody who read and/or commented about my issue.
[1] Sesse told me that in his case there was a transparent proxy involved when he exeprienced MTU weirdness.
1 comment:
Cool, this finally solved my problems with my provider, too. I always wondered why I got some packages through from various hosts, but not bigger replies (like getting the original SYN/ACK reply from a webserver but not the result of my request). In my case, this happens with Mnet and almost all servers of the post/dhl.de domains. And of course my router has no troubles connecting and getting traffic through, only the hosts that get routed.
Post a Comment