[strongSwan] Partially redundant connection

[Richard Andrews]

I'm pretty sure the two tunnels will clobber each others SPD entries.

In my experience this would normally be done with GRE inside IPsec as
GRE supports that kind of routing decision and load balancing. In this
case two tunnels would be configured to carry different traffic (GRE
src/dst) and GRE encapsulates the network-to-network traffic.

You will want to detect a failed path; so that means you need some
dynamic routing protocol also running across each path between the
networks.


On Thu, 2012-08-16 at 06:51 -0700, Shaun McCullagh wrote:
> Hi,
> 
> I'm running  Strongswan U4.4.1/K2.6.32-5-xen-amd64 on a Debian Squeeze system
> 
> I would like to setup a connection with redundancy at one end so there are two paths
> available for connectivity between networks 10.71.90.0/24 and 10.1.4.0/24
> 
> The Strongswan connections are defined below
> 
> 
> conn r1
>       authby=psk
>       left=%defaultroute
>       leftsubnet=10.71.90.0/24
>       leftauth=psk
>       right=185.61.202.4
>       rightsubnet=10.1.4.0/24
>       pfs=yes
>       ike=aes256-sha1-modp2048
>       auto=route
> 
> 
> conn r2
>       authby=psk
>       left=%defaultroute
>       leftsubnet=10.71.90.0/24
>       leftauth=psk
>       right=185.61.202.36
>       rightsubnet=10.1.4.0/24
>       pfs=yes
>       ike=aes256-sha1-modp2048
>       auto=route
> 
> 185.61.202.4 is assigned to an H3C in Birmingham and 185.61.202.36 is assigned to another H3C located in West Bromwich
> both H3Cs can reach network 10.1.4.0/24. Both H3C's are active.
> 
> 
> Will this work?
> 
> Or will I end with faulty routing with some packets egressing from 185.61.202.4 but replies being sent to 185.61.202.36?
> 
> If this design is wrong, what is the right way?
> 
> TIA
> 
> And thank you for putting StrongSwan on the public domain....
> 
> Shaun
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users