[Swan] IPSec Overlapping IP solutions
paul at nohats.ca
Fri Dec 30 01:15:16 UTC 2016
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
> 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
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
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
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,
> Any advice, or pointers to documentation will be very much appreciated.
> Thank you very much - John
> Swan mailing list
> Swan at lists.libreswan.org
More information about the Swan