SNAT and connection tracker: should established connections be dropped when a rule is removed from nat table?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I need am advice on SNAT.

There is SNAT setup where my clients connected through ipsec. Whenever
new connection appears, SNAT rule for respective IP is created.
Whenever client disconnects, corresponding SNAT rule is dropped.

In general it works, but this schema leads to the packets leakage through NIC:

1) IPSEC client disconnects
2) Rule for this client is deleted from the nat table
3) But incoming messages (from remote servers) for already established
connections are continuing to come! They are "de-NATed" regardless of
the fact the rule does not exist anymore.
4) They come to xfrm subsystem which does not take them (as no SA
associated with this IP exists)
5) As a result these packets (addressed to the private addresses) are
appearing on the eth0 interface

As of now my solution is to drop these packets using ebtables. But I
am still not sure it's an optimal one.

So, my questions:

- Do I understand it right that when SNAT rule is deleted from the nat
table, it does not mean that already established connections are
stopped from being tracked? And the they are continuing to flow using
the rule which was assigned to them at the moment when corresponding
connection was created?  Can this behavior be changed?
- Any idea how can current schema be improved?   The first option I
see is to be able to stop SNATting of the connections for which the
rule was deleted. In theory I can do it even from userland. The second
option is to ask xfrm to drop all the packets from specific network if
there no SA for dest IP address of the packet (sounds weird).

Thanks in advance!

-- 
WBR & WBW, Vitaly
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux