why not use 'conntrack -D' command to delete conntrack entries from connection tracking itself ? On Fri, Jul 31, 2015 at 4:01 PM, Vitaly Repin <vitaly_repin@xxxxxxxx> wrote: > Hello, > > I've described complete solution implemented: > http://vrepin.org/vr/IPsec-PacketLeakage/ > > Hopefully, it can be useful for others facing similar problems. > > 2015-07-10 19:29 GMT+03:00 Noel Kuntze <noel@xxxxxxxxxxxxxxxxx>: >> Hello Vitaly, >> >> Create a drop rule in *filter FORWARD, that drops incoming >> packets for SNATed IPs without a matching policy >> >> - -A FORWARD -m ipset --set snatedIPs dst -m policy --pol none --dir out -j DROP >> >> Mit freundlichen Grüßen/Kind Regards, >> Noel Kuntze >> >> Am 10.07.2015 um 18:26 schrieb Vitaly Repin: >> > 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 -- 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
