<div dir="ltr">Hi Martin,<div><br></div><div style>I wasn't aware of this thread and asked a similar question in a different one.</div><div style><br></div><div style><span style="font-family:arial,sans-serif;font-size:13px">> If you need two identical tunnels with a failover mechanism, you'll have</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> to assign Netfilter marks to the connections. This allows strongSwan to</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> install identical policies (with different marks) in the kernel. Your</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> packets then have to be tagged with the correct mark before they hit</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> IPsec policy lookup. strongSwan currently does not provide such a</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> mechanism, so you'll have to create and update these rules yourselves.</span><br></div><div style><br></div><div style>I have a similar requirement and was digging up all the Strongswan use cases. Was wondering if this would help. <a href="http://www.strongswan.org/uml/testresults/ikev2/nat-rw-mark/index.html">http://www.strongswan.org/uml/testresults/ikev2/nat-rw-mark/index.html</a></div>
<div style><br></div><div style>In this context, can you please help me understand your comments. You said that Strongswan currently does not provide the "tagging with firewall marks" mechanism but the example seems to show that such a thing is possible?</div>
<div style><br></div><div style>Bharath Kumar</div><div style><br></div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 6:21 AM, Patrick Hemmer <span dir="ltr"><<a href="mailto:strongswan@stormcloud9.net" target="_blank">strongswan@stormcloud9.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The reauth=no seems to have solved the issue. I thought I had tried<br>
this, but thinking back on it, I think I screwed up the test.<br>
<br>
However listing all the subnets in a single CHILD_SA did not create a<br>
mesh network between the 2 gateways. I'm assuming it would work fine if<br>
none of the subnets overlap, but since mine are overlapping it seems to<br>
just choose the subnet with the largest mask.<br>
<br>
Thanks :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
-Patrick<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 2013/03/04 05:09, Martin Willi wrote:<br>
> Hi Patrick,<br>
><br>
>> So I want to have each box provide it's own subnet, and then a larger<br>
>> subnet which encompasses the other IPsec gateway. This way traffic<br>
>> will take the shortest route to each remote subnet, but if an IPsec<br>
>> gateway goes down, the traffic will route through the remaining<br>
>> gateway.<br>
> So this means that on a box you have two tunnels with an identical IPsec<br>
> policy? If yes: Please be aware that the Linux kernel can't handle<br>
> identical policies (how should it pick the correct one?). Therefore<br>
> strongSwan uses some refcounting logic to install only one of them, but<br>
> this means that only one of the tunnels can be used actively.<br>
><br>
> If you need two identical tunnels with a failover mechanism, you'll have<br>
> to assign Netfilter marks to the connections. This allows strongSwan to<br>
> install identical policies (with different marks) in the kernel. Your<br>
> packets then have to be tagged with the correct mark before they hit<br>
> IPsec policy lookup. strongSwan currently does not provide such a<br>
> mechanism, so you'll have to create and update these rules yourselves.<br>
><br>
>> However I am occasionally experiencing issues where when the main IKE SA<br>
>> reauthenticates, the tunnel sometimes goes dead until the child SA<br>
>> reauthenticates.<br>
> The reauthentication behavior of strongSwan shows interruptions of<br>
> traffic flow, and there is not much you can do about it. Do you really<br>
> have a need for reauthentication from a security perspective? Probably<br>
> not if you have the preshared key in ipsec.secrets. I'd try to switch to<br>
> IKE_SA rekeying by using reauth=no, which can solve a lot of problems.<br>
><br>
>> I've played with a ton of different ways of configuring this, but a<br>
>> separate "conn" section for each tunnel seems to be the only way which<br>
>> it works. Trying things like putting all the subnets in a single "conn"<br>
>> using a comma-delimited "left/rightsubnet" ends up creating a single<br>
>> tunnel to the /16 subnet.<br>
> Having all subnets in a single CHILD_SA creates a full mesh between all<br>
> sunbets in leftsubnet and rightsubnet. If you have separate conn<br>
> sections, you'll get different CHILD_SAs, and of course no full mesh<br>
> between them.<br>
><br>
>> I've also tried setting 'reuse_ikesa = no', which results in the same<br>
>> behavior.<br>
> This just means that each CHILD_SA initiated to a peer will use its own<br>
> IKE_SA.<br>
><br>
> Regards<br>
> Martin<br>
><br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a><br>
<a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div>