Hi Andreas Schuldei, Andreas Schuldei wrote: > On Sat, Dec 26, 2009 at 5:11 PM, Daniel Mentz > <[email protected]> wrote: >> Hi Andreas Schuldei, >> >> I guess that IKE traffic on port 500 is never protected by ESP because it >> has its own protection which is the IKE SA. So don't worry about IKE >> traffic. > > i didnt talk about protection but rather distortion that you get when > the ipsec connection is somehow confused and traffic cant pass through > it properly. is the port 500 exempted from going through the ipsec > connection? then i am happy and wont worry about traffic interruptions > that become longer then necessary. it would certainly make sense to > special-case port 500.
IKE traffic which runs on port 500 and 4500 is excluded from IPsec processing. Therefore, this kind of traffic will not be wrapped inside ESP packets. I do not know how this works, though. Either the kernel is clever enough to exclude it or strongSwan uses some special socket. > >> Regarding ssh I do understand the problem. What you might want to try out is >> a passthrough setup like the one described on >> >> http://www.strongswan.org/uml/testresults43/ikev1/passthrough/ >> >> Try setting up a passthrough connection with a proto/port specification. >> Maybe the kernel selects the most specific policy for ssh traffic which is >> the passthrough policy. > > then i would need one additional connection definition for each > host-host pair? that would double the size of my configuration files > from very large to very very large (in case of my full mash of hosts). > cant that be done more elegantly? Very interesting topic. A spent a few hours doing research on that. I kind of solved your problem by using the following commands to add entries to the Security Policy Database (SPD): ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp sport 22 dir in priority 100 ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp sport 22 dir fwd priority 100 ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp dport 22 dir out priority 100 ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp dport 22 dir in priority 100 ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp dport 22 dir fwd priority 100 ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 proto tcp sport 22 dir out priority 100 Please note, that the priority value is actually a bit confusing. Policies with lower priority values have higher priority. So "priority 100" wins over "priority 200". I also tried to use strongSwan's passthrough policy but this did not work out because strongswan assigned the corresponding policies a higher priority value which in effect means that they have lower priority. @strongSwan team: How can I control the priority values of the policies? If you run the commands above, all SSH traffic should be excluded from IPsec processing as long as there are no other policies with lower priority values. -Daniel > >> Personally, I usually depend on a third host that I can use for >> troubleshooting. If the IPsec connection between A and B fails, then I can >> ssh to C and from there login into B. > > i have third hosts, too. > >> Does that help? >> >> -Daniel >> >> Andreas Schuldei wrote: >>> hi Andreas! >>> >>> (thanks to this thread i just discovered traffic selectors, reading >>> this mailing list DOES help! :-) >>> >>> what i would like to do is to NOT send ssh (port 22) and ike2 traffic >>> (port 500) via ipsec. that is because back in 2000 when i worked with >>> ipsec i discovered that if the encrypted connection hang for some >>> reason i would be unable to reach the other side via ssh (and fix the >>> remote problem) and the connection could not be renegotiated quickly >>> becaus even the key exchange could not be done because the connection >>> which was responsible for renegotiation was unavailable. >>> >>> for that reason i would like to exclude those two ports from >>> ipsec-transportation. but the syntax for transport selectors does not >>> provide for a "dont add THIS port to ipsec", does it? >>> >>> apart from this: do you people observe the described failiour modes in >>> real life? perhaps these issues went away in the mean time. >>> >>> /andreas >>> >>> >>> On Sat, Dec 26, 2009 at 2:48 PM, Andreas Steffen >>> <[email protected]> wrote: >>>> Hello Mugur, >>>> >>>> it does not matter if you define each tunnel between two >>>> peers independently or if you use conn %default or an also= >>>> construct to save typing work. All tunnels, i.e. a definition >>>> of traffic selectors are grouped under the same IKE_SA >>>> which is going to be established between the two peers. >>>> >>>> The IKEv2 charon daemon allows the enumeration of several >>>> traffic selectors for the same CHILD_SA using left|rightsubnet: >>>> >>>> leftsubnet=10.1.0.0/16,10.3.0.0/16 >>>> rightsubnet=10.2.0.0/16,10.4.0.0/16 >>>> >>>> will establish the following four IPsec SAs with a single CHILD_SA: >>>> >>>> 10.1.0.0/16 - 10.2.0.0/16 >>>> 10.1.0.0/16 - 10.4.0.0/16 >>>> 10.3.0.0/16 - 10.2.0.0/16 >>>> 10.3.0.0/16 - 10.4.0.0/16 >>>> >>>> Currently traffic selectors with protocol/port restrictions >>>> using the left|rightprotoport parameters cannot be >>>> grouped together in a single CHILD_SA. You will have to define >>>> a separate conn description for each protocol/port combination >>>> resulting in a separate CHILD_SA exchange. Thus the example >>>> >>>> conn net-net >>>> also=host-host >>>> leftsubnet=10.1.0.0/16,10.3.0.0/16 >>>> rightsubnet=10.2.0.0/16,10.4.0.0/16 >>>> auto=start >>>> >>>> conn proto1 >>>> also=host-host >>>> leftsubnet=10.5.0.0/16 >>>> rightsubnet=10.5.0.0/16 >>>> leftprotoport=tcp >>>> rightprotoport=tcp/http >>>> auto=start >>>> >>>> conn proto2 >>>> also=host-host >>>> leftsubnet=10.5.0.0/16 >>>> rightsubnet=10.5.0.0/16 >>>> leftprotoport=tcp >>>> rightprotoport=tcp/smtp >>>> auto=start >>>> >>>> conn host-host >>>> left=<IP address of left> >>>> right=<IP address of right> >>>> >>>> would create six IPsec SAs between left and right, using a primary >>>> IKE_AUTH and two additional CHILD_SA exchanges. >>>> >>>> Best regards >>>> >>>> Andreas >>>> >>>> ABULIUS, MUGUR (MUGUR) wrote: >>>>> Hello, >>>>> >>>>> I looked to strongSwan connection parameters >>>>> (http://wiki.strongswan.org/wiki/1/ConnSection) and I am not sure how >>>>> to define several tunnels between the same endpoints, each tunnel >>>>> with several traffic selectors. >>>>> >>>>> In my understanding an independent tunnel is defined by a "conn >>>>> <name>" directive with the condition that its body does not contain >>>>> an "also = <section name>" directive. >>>>> >>>>> Now, I want, for each tunnel to include several traffic selectors; >>>>> i.e. several "left|rightprotoport = <protocol>/<port>" and several >>>>> "left|rightsubnet = <ip subnet>". >>>>> >>>>> Moreover I want to combine traffic selectors in a specific way for a >>>>> same connection. For example to specify somehow >>>>> >>>>> leftprotoport=icmp ONLY for leftsubnet= 192.168.10.0/24 and >>>>> leftprotoport=UDP ONLY for leftsubnet= 172.16.10.0/24 >>>>> >>>>> Can you please specify which are all possibilities of using the IKEv2 >>>>> extended traffic selector concept with strongSwan. >>>>> >>>>> Thank you Mugur _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
