On Sat, Dec 26, 2009 at 5:11 PM, Daniel Mentz <danielml+mailinglists.strongs...@sent.com> 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. > 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? > 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 >> <andreas.stef...@strongswan.org> 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 >>> >>> ====================================================================== >>> Andreas Steffen andreas.stef...@strongswan.org >>> 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 >>> Users@lists.strongswan.org >>> https://lists.strongswan.org/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> Users@lists.strongswan.org >> https://lists.strongswan.org/mailman/listinfo/users > > _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
