[Openswan Users] assistance with atypical configuration

Erich Titl erich.titl at think.ch
Wed Nov 10 02:59:57 EST 2010


Hi

at 10.11.2010 08:13, Roel van Meer wrote:
> Neal Murphy writes:
> 
>> On Tuesday 09 November 2010 12:30:08 Frank Temple wrote:
>>> I am investigating how to configure the network detailed below. I am aware
>>> that some manual scripting may be required. All of the hosts are using
>>> openswan.
>>>
>>> A--------B-------D
>>> A--------C-------D
>>>
>>> There are four hosts. The tunnels are detailed with the lines above. The
>>> objective is to permit A to communicate with D through B or C. A needs to
>>> route to D in the morning via B and in the afternoon via C. This is the
>>> part where I assume some manual scripting may be required. I can do that
>>> part, I just need to learn what needs to be done. The private IP for D
>>> should be the same for A independent of the tunnel (B,C) selected.
>>
>> Every *routed* LAN must have a unique address.
>>
>> Using two routes equally involves 'policy routing'. Take a gander at 
>> lartc.org; in Linux at least, you can configure both A and D to balance the 
>> traffic between each other using both B and C.
>>
>> If you really have to have overlapping (or concurrent) subnets at A and D, you 
>> will have to find a way to bridge the two LANs across the IPSEC tunnels. My 
>> simple mind say, "Lift layer 2 into a point-to-point tunnel between A and D."
> 
> I agree. I also thought up a rather complex scenario involving lots of 
> NATting, but that wouldn't meet the requirement that a change of tunnels 
> would not cause any data loss.
> 

Have you considered to use gre tunnels and eql to bundle the connections
to the remote site, then use the eql interface for IPSEC. Then you could
just remove the respective gre tunnel and possibly activate the other to
take over. You need gre tunnels as the egl interface appears to not
allow to enslave real eth devices.

I have not testet this though.....

cheers

Erich

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3409 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.openswan.org/pipermail/users/attachments/20101110/883e0485/attachment.bin 


More information about the Users mailing list