On 10/04/2010 03:38 PM, Christoph Anton Mitterer wrote: > Hi again. > > (And sorry for bugging you over and over again ;) ) > yeah, if the doctor is in, it will cost 50 cents ;-)
> > First perhaps some conceptual questions (whether I've understood it > right): > > 1) The IPsec policies (the stuff one gets with "ip xfrm policy")... this > is basically what strongswan sets up, and the rules how the kernel IPsec > code has to apply IPsec (encapsulation or decapsulation) on packets, right? > yes > Given how this looks at my system: >> src 1.0.0.1/32 dst 2.0.0.2/32 >> dir fwd priority 1680 ptype main >> tmpl src 1.0.0.1 dst 2.0.0.2 >> proto esp reqid 1 mode tunnel > => Tells the kernel to do IPsec processing with any packet being > _forwarded_ from 1.0.0.1 to 2.0.0.2 (when they're used as gateway with the > left/rightsubnet options)... by using esp/tunnel mode? > a) Why's there no fwd rule in the other direction? Ask the Linux kernel developers! > b) Why is there this rule at all, as I didn't use left/rightsubnet and > just have a connection between host-host. > With type=tunnel we always insert a fwd policy since we don't check if left|rightsubnet equal left or right, respectively. The fwd policy does not do any harm. >> src 1.0.0.1/32 dst 2.0.0.2/32 >> dir in priority 1680 ptype main >> tmpl src 1.0.0.1 dst 2.0.0.2 > proto esp reqid 1 mode tunnel > => Tells the kernel to do IPsec processing with any packet incoming from > 1.0.0.1 to 2.0.0.2... by using esp/tunnel mode? > >> src 2.0.0.2/32 dst 1.0.0.1/32 >> dir out priority 1680 ptype main >> tmpl src 2.0.0.2 dst 1.0.0.1 >> proto esp reqid 1 mode tunnel > => Tells the kernel to do IPsec processing with any packet outgoing from > 2.0.0.2 to 1.0.0.1... by using esp/tunnel mode? > >> src ::/0 dst ::/0 >> dir 3 priority 0 ptype main >> src ::/0 dst ::/0 >> dir 4 priority 0 ptype main >> src ::/0 dst ::/0 >> dir 3 priority 0 ptype main >> src ::/0 dst ::/0 >> dir 4 priority 0 ptype main >> src ::/0 dst ::/0 >> dir 3 priority 0 ptype main >> src ::/0 dst ::/0 >> dir 4 priority 0 ptype main >> src 0.0.0.0/0 dst 0.0.0.0/0 >> dir 3 priority 0 ptype main >> src 0.0.0.0/0 dst 0.0.0.0/0 >> dir 4 priority 0 ptype main >> src 0.0.0.0/0 dst 0.0.0.0/0 >> dir 3 priority 0 ptype main >> src 0.0.0.0/0 dst 0.0.0.0/0 >> dir 4 priority 0 ptype main >> src 0.0.0.0/0 dst 0.0.0.0/0 >> dir 3 priority 0 ptype main >> src 0.0.0.0/0 dst 0.0.0.0/0 >> dir 4 priority 0 ptype main > => What are these (dir 3 and 4) and why does each rule appear twice? > These are policies that exempt the IKE protocol (ports 500 and 4500) from tunneling. > These policies are the ones matched with iptables' "policy" match?! > > > > 2) How does the packages flow through the stack/netfilter? > (I've used this > http://en.wikipedia.org/wiki/File:Netfilter-packet-flow.svg overview) > > a) The en/decapsulation does _not_ take place "in" the mangle stage (which > I've guess first) but this xfrm stage, right? > b) Some poor man's ping and -j LOG tests showed me about this: > Incoming: > - an ESP packet arrives, goes through all tables (at some point finally > filter/INPUT) > - it's decrypted/authenticated/decapsulated in th xfrm "layer" > - the resulting package (no longer ESP but e.g. ICMP) is newly injected > and goes ("again") through all tables (at some point finally filter/INPUT). > - it's delivered to the process. > that's more or less correct. Since there is no documentation please inspect the kernel code. > If decryption/authentication would fail, then simply no "2nd" package > would be injected? > > Outgoing: analogous? > > > Thanks in advance :) > > Chris. Regards Andreas ====================================================================== Andreas Steffen [email protected] strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
