Daniel, thank you VERY much! when would be a good time to run those commands? are there hooks in strongswan to call a script containing those commands? or are there scripts on the system already where i can add these commands?
On Mon, Dec 28, 2009 at 3:05 PM, Daniel Mentz <danielml+mailinglists.strongs...@sent.com> wrote: > Hi Andreas Schuldei, > > Andreas Schuldei wrote: >> >> 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. > > 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 >>>> <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 > > _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
