[strongSwan] overlapping redundant subnets

[Bharath Kumar]

Hi Martin,

I wasn't aware of this thread and asked a similar question in a different
one.

> If you need two identical tunnels with a failover mechanism, you'll have
> to assign Netfilter marks to the connections. This allows strongSwan to
> install identical policies (with different marks) in the kernel. Your
> packets then have to be tagged with the correct mark before they hit
> IPsec policy lookup. strongSwan currently does not provide such a
> mechanism, so you'll have to create and update these rules yourselves.

I have a similar requirement and was digging up all the Strongswan use
cases. Was wondering if this would help.
http://www.strongswan.org/uml/testresults/ikev2/nat-rw-mark/index.html

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?

Bharath Kumar





On Mon, Apr 8, 2013 at 6:21 AM, Patrick Hemmer
<strongswan at stormcloud9.net>wrote:

> The reauth=no seems to have solved the issue. I thought I had tried
> this, but thinking back on it, I think I screwed up the test.
>
> However listing all the subnets in a single CHILD_SA did not create a
> mesh network between the 2 gateways. I'm assuming it would work fine if
> none of the subnets overlap, but since mine are overlapping it seems to
> just choose the subnet with the largest mask.
>
> Thanks :-)
>
>
> -Patrick
>
>
> On 2013/03/04 05:09, Martin Willi wrote:
> > Hi Patrick,
> >
> >> So I want to have each box provide it's own subnet, and then a larger
> >> subnet which encompasses the other IPsec gateway. This way traffic
> >> will take the shortest route to each remote subnet, but if an IPsec
> >> gateway goes down, the traffic will route through the remaining
> >> gateway.
> > So this means that on a box you have two tunnels with an identical IPsec
> > policy? If yes: Please be aware that the Linux kernel can't handle
> > identical policies (how should it pick the correct one?). Therefore
> > strongSwan uses some refcounting logic to install only one of them, but
> > this means that only one of the tunnels can be used actively.
> >
> > If you need two identical tunnels with a failover mechanism, you'll have
> > to assign Netfilter marks to the connections. This allows strongSwan to
> > install identical policies (with different marks) in the kernel. Your
> > packets then have to be tagged with the correct mark before they hit
> > IPsec policy lookup. strongSwan currently does not provide such a
> > mechanism, so you'll have to create and update these rules yourselves.
> >
> >> However I am occasionally experiencing issues where when the main IKE SA
> >> reauthenticates, the tunnel sometimes goes dead until the child SA
> >> reauthenticates.
> > The reauthentication behavior of strongSwan shows interruptions of
> > traffic flow, and there is not much you can do about it. Do you really
> > have a need for reauthentication from a security perspective? Probably
> > not if you have the preshared key in ipsec.secrets. I'd try to switch to
> > IKE_SA rekeying by using reauth=no, which can solve a lot of problems.
> >
> >> I've played with a ton of different ways of configuring this, but a
> >> separate "conn" section for each tunnel seems to be the only way which
> >> it works. Trying things like putting all the subnets in a single "conn"
> >> using a comma-delimited "left/rightsubnet" ends up creating a single
> >> tunnel to the /16 subnet.
> > Having all subnets in a single CHILD_SA creates a full mesh between all
> > sunbets in leftsubnet and rightsubnet. If you have separate conn
> > sections, you'll get different CHILD_SAs, and of course no full mesh
> > between them.
> >
> >> I've also tried setting 'reuse_ikesa = no', which results in the same
> >> behavior.
> > This just means that each CHILD_SA initiated to a peer will use its own
> > IKE_SA.
> >
> > Regards
> > Martin
> >
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130408/2a89719e/attachment.html>