Hi all,
On Thu, 8 Nov 2012, Jan Engelhardt wrote:
An operating system can therefore never automatically know whether it
is ok to continue using certain tuples over a link or not, unless the
user intervenes in some way.
...
Even a default-off MASQUERADE flag that says "--update-source-address" would
give us the option to have this fixed automatically, provided that people know
about the flag and use it.
I'll leave this to the nf_nat maintainer(s) and what direction it
should go.
While thinking about this last night, I realised that if this is actually
a bug or limitation in MASQUERADE, then anyone using a Linux router on
dynamic IP (frequently changing) with one of these UDP devices behind it
is almost certainly experiencing the same problem:
After the public IP changes (which might be every 8-24 hours in some
cases), outbound packets from the device keep the old conntrack entry
alive forever, with the wrong public IP address, and no replies will ever
be received to those packets. Surely this is a more common scenario than a
Linux box managing multihoming or failover connections.
I hope that either we will make the MASQUERADE target update the source
(SNAT) address address automatically by default, or that all cheap router
vendors will add rules like this:
iptables -t nat -A POSTROUTING -p udp -j MASQUERADE --update-source-address
iptables -t nat -A POSTROUTING -j MASQUERADE
Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
