On Thursday 2012-11-08 17:35, Chris Wilson wrote:
>
> Summary: UDP devices (e.g. SIP phones) that don't change their source port,
> behind NAT, when routing to their destination changes, keep a conntrack entry
> valid which contains the old (wrong) SNAT-to address
Actually, not {changing the tuple and thus breaking at least
stream-type connections} could be considered a feature, for example
when you migrate off a certain address and onto a new one.
This(^) thought applies to both SNAT and DNAT scenarios. In fact,
IPv6 (non-NAT) temporary addresses follow the same principle — they
continue to be valid for a certain time even after their
preferred_lifetime has run out.
You can remove "old" NFCT entries by use of conntrack(8) if you
the time between preferred_lft and valid_lft running out is too
short.
> However I suspect this is not easily generalisable to other NAT types, and
> violates layering (the source address and port after SNAT may not be
> available at the time of the lookup) so I guess there may be a more
> acceptable solution.
>
> Another option which doesn't violate layering might be to update the NAT rule
> when the outgoing address is known (after routing),
That is what MASQUERADE is usually for.
> if it's different to the
> current outgoing address. This would break existing TCP connections if the
> routing changes, but in most cases the connection is already broken by the
> routing change, and what we're trying to fix is that future connection
> attempts, reusing the same conntrack, should not fail as well.
>
> Another option might be to remember the destination interface as part of
> the conntrack entry, and continue to send matching packets out of that
> interface even if the routing changes. [...]
Consider this 2×2 event matrix (giving 4 cases a packet can end up
in):
route out on {A, B} × use outgoing address {A, B}
It is certainly possible that a customer may be multi-linked (2 or
more ISPs), and each ISP accepting traffic from/to his multi-home (1
or more subnets), whilst he is doing round-robin loadbalancing.
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.
--
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
