'Re: [Swan] IPSec Overlapping IP solutions'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libreswan
Subject:    Re: [Swan] IPSec Overlapping IP solutions
From:       John Weir <john.weir () pharos-ei ! com>
Date:       2017-01-13 23:06:54
Message-ID: 3AA03D8B-F832-45DE-89BB-826D14D7910E () pharos-ei ! com
[Download RAW message or body]

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@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@lists.libreswan.org
> > https://lists.libreswan.org/mailman/listinfo/swan
> > 

_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

[prev in list] [next in list] [prev in thread] [next in thread] 