All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mailing List Reader <mlreader@lucomp.net>
To: netfilter@lists.netfilter.org
Subject: broken SNAT with fixed external MTU
Date: Thu, 14 Oct 2004 18:15:22 +0200	[thread overview]
Message-ID: <416EA61A.9030600@lucomp.net> (raw)

Hello everybody,

My DSL router (very bad firmwares) wants me to force the MTU
(buggy MTU auto-setting). The firewall has a public IP and mtu 1500:

---snip
#route to the router net
ip route add 192.168.1.0/24 dev eth1 mtu 1440
# default to the router (mtu not needed here)
ip route add default via 192.168.1.1 mtu 1440
--snip

the firewall itself NATs one client back-to-back connected
(cable checked!):

---snip
#mss clamping 1)
iptables -A FORWARD -d $net1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS 
--set-mss 1440
iptables -A FORWARD -s $net1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS 
--set-mss 1440

#snat 2)
iptables -t nat -A POSTROUTING -j SNAT -o $out -s $net1 --to-source <other 
public IP>
---snip

Now:
1) mss clamping because tcpdumping I saw DF 1500 MTU packets
from the client being sent to the router. This would not work, the
(buggy) router has MTU 1500, the DSL line can't handle it (see above)
but of course no "fragmentation  needed" would come, so I thought forcing
the mss both ways would do. It seems to, no more "1500" packets.

2) pure SNAT one-to-one (to another unused IP)
The firewall only has few single lower ports being filtered (on the basis
of its IP, not the NATted clients one).


To come to the problem: everything is OK in these cases:
-firewall-external servers/internet
-firewall-same network servers
-firewall and same network servers - client

but in this case:
-client-internet (SNAT)
everything OK for 30 to 60 secs, then like a buffer getting filled
then stuck, everyting stops for about 30 seconds (streams get
lost, sockets go in timeout) <only> to internet.
I see nothing in tcpdump (but silence) no traffic whatsoever
nor coming nor going to the client (from/to the internet)


I've tried disabling all filtering, changing interfaces, (client)
operating systems, the cable, many iptables tests. Nothing yet.
I won't  force a lower MTU on the internal net.

I'm not sure about my mss solution, but this does not look like an
MTU issue: (it happens on any connection, any size of packets).
With a working DSL router with good MTU self-clamping everything
is just <fine>, though!

I'm lost. Any suggestion? Should I mangle the SNAted packets in some
way I don't get?


Cheers, any idea much appreciated,

Luigi Corsello






             reply	other threads:[~2004-10-14 16:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-14 16:15 Mailing List Reader [this message]
2004-10-14 18:17 ` broken SNAT with fixed external MTU Jason Opperisano
2004-10-14 19:52   ` Luigi Corsello

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=416EA61A.9030600@lucomp.net \
    --to=mlreader@lucomp.net \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.