[Swan] IPSec Overlapping IP solutions

[John Weir]

Before replying I’ve been waiting for a response to my pony request.  It turns out there is no timeout on pony requests, and apparently no pony.

In all sincerity thank you very much for the reply. Your explanation makes sense and I hope I can pull it off.

I have been waiting for the other side to update their configuration – and still waiting.  So I don’t know if I will be able to get this to work.

Peace and respect - John

> On Dec 29, 2016, at 5:15 PM, Paul Wouters <paul at nohats.ca> wrote:
> 
> On Thu, 29 Dec 2016, John Weir wrote:
> 
>> How does one go about handling an overlapping IP?
>> 
>> I understand this question is broader than LibreSwan, but perhaps there is a solution particular to LibreSwan or ipsec.  My own research has left me more confused than enlighten. I am very new to networking and a slow learner.
>> 
>> The situation is:
>> 
>> Left side is on network 10.0.0.0/16 hosted on AWS
>> Right side is 10.0.0.0/8 hosted by a third party
>> 
>> Both sides are run by different organizations and are not able to change their internal networks.
> 
> Both sides might as well have asked for a pony. They need to cooperate.
> 
> The first obvious answer is, both ends should have IPv6 so we can do
> this without RFC1918 conflicting address space. But that pony will
> probably be easier.
> 
> If neither end wants to narrow down or renumber the address spaces to
> attach, then your only possible solution is to add NAT to it. This
> requires that any communication can be hardcoded to an IP address
> that does not need DNS of any kind.
> 
>> The configuration is
>> 
>>       leftid=hidden     # conf for AWS
>>       left=10.0.127.5  # Elastic IP
>>       leftsubnet=10.0.128.0/24
>> 
>>       right=hidden
>>       rightsubnet=10.0.0.4/32
>> 
>> What perhaps makes this a simpler problem, is the connection is essentially client based: the left will be connecting to the right, but the right has no access to the left. And perhaps even simpler only a single IP on the right is required.
> 
> So first, left picks a different range to connect to right's 10.0.0.4.
> Anything that does not clash with anything that right uses will work.
> Either pick a real public IP under left's control, or pick something
> from the RFC1918 or CGN reserved space that right isnt't using. Let's
> call that IP a.b.c.d for now. But it could be 192.168.1.1 (RFC1918) or
> 100.64.1.1 (RFC6598) as well.
> 
> Next, if you do not use 10.0.0.4/32 on left, make sure it never gets
> used. If needed add host routes to make it go to the ipsec server. If
> left does use it, then things are more tricky and you need to add a
> second NAT rule on the ipsec server (see below)
> 
> 
> Build a tunnel using:
> 
>        left=10.0.127.5  # Elastic IP
>        leftsubnet=a.b.c.d/32
> 
>        right=hidden
>        rightsubnet=10.0.0.4/32
> 
> Configure a.b.c.d/32 on the ipsec server on left, on the loopback
> device. This is needed so you can build IP packets with source
> address a.b.c.d.
> 
> Now make sure on left that 10.0.0.4 routes to the ipsec server.
> Then SNAT (an if using a different IP, DNAT) the packet to the
> right addresses.
> 
> Now you can bring up the tunnel and there is no conflict. A packet
> from the AWS network for 10.0.0.4 is send to the ipsec gateway,
> SNAT'ed to a.b.c.d, and then goes into the tunnel to get encrypte
> to the other end. At the other end, all traffic seems to come from
> a single IP, a.b.c.d. right needs to ensure their routing so that
> replies to a.b.c.d go the the ipsec server.
> 
> Hope this helps,
> 
> Paul
> 
> 
> 
>> Any advice, or pointers to documentation will be very much appreciated.
>> 
>> Thank you very much - John
>> _______________________________________________
>> Swan mailing list
>> Swan at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan
>>