Hi Jozsef,
On Mon, 12 Nov 2012, Jozsef Kadlecsik wrote:
But I'm sorry that you won't consider having a flag that changes
MASQUERADE's behaviour to automatically change the source address in
the conntrack entry.
I don't think changing the source address were a good solution: if
MASQUERADE could be changed to handle the cases then the wrong
conntrack entries should be deleted.
I'm not quite sure what you mean here. Are you saying that "invalid
conntrack entries should be detected and deleted" or "changing MASQUERADE
is pointless because if it would just delete conntrack entries that should
not be deleted"?
But what would trigger the action? (Routing changed? I do not see such
a kernel event but I might missed it.) And more importantly, what
would identify the affected entries?
[...]
An in-kernel "route changed" notification were great, because then we
could delete all MASQUERAD-ed entries where --update-source-address flag
is set.
If we could register to receive routing changed events for SNAT source
addresses, that would be great (more efficient) but if the mechanism does
not yet exist, it would be much more difficult to create.
I suppose that if we just deleted them all on any routing change, then
that would solve the immediate problem for us. It would be ideal if
incoming packets could still be directed to the correct internal source,
but dropping them is a smaller problem than continuing to send out invalid
packets and keeping a broken entry alive forever.
I propose that:
* when the packet matches an existing conntrack rule, and
* is sent out of an interface that does not list the packet's new (SNAT-to)
source address as one of its IP addresses (i.e. if this were a new
connection, MASQUERADE would not choose this source address), and
First, it'd mean a heavy checking for every matched packet.
Is it really so expensive to get the list of IP addresses for an interface
and check down the list for presence of a given address? If so, perhaps
that's a problem elsewhere in the kernel?
Second, there's no callback, whatsoever in the netfilter conntrack
framework which could execute this instruction set. And if such an
internal hook were added, that'd mean an unnecessary "check the hook and
call if exists" overhead for *every* other case.
Another option is to check, after routing, the source address that
MASQUERADE would have assigned to the packet. There must be a mechanism
for that, because we already do it for the first packet in the connection,
and it surely cannot be expensive. If it's different to the current
SNAT-to address in the conntrack, and the flag is set on the conntrack,
then update the conntrack.
* the --update-source-address flag is set on the MASQUERADE target
then update the source address on the conntrack rule to the new one.
Why do you insist on updating the source address?
In these cases, the original source address is no longer valid. If we
delete the conntrack, we will just end up creating a new one for the same
packet. That results in more overhead and higher churn in the conntrack
table, but admittedly since the source address has changed, we should
probably treat the conntrack as UNREPLIED anyway, i.e. more like a new
fresh conntrack.
Perhaps if we were to leave the old conntrack alone and just create a new
one, then packets arriving from the peer destined to the old source
address would still end up being forwarded to the local device, which
could help to keep any existing connections kind-of alive (that might be
seen as a bad thing as well).
Should the --update-source-address be limited to UDP only?
I think the problem applies even more to portless protocols such as GRE.
Devices have no choice to "change the source port" when making a new
connection. Any packets that they send, will definitely keep a stale entry
alive.
Thank you for considering and engaging with this proposal :)
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
