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 > [email protected] > https://lists.strongswan.org/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
