[Swan] Duplicate RightSubnets by Varying LeftSubnets?

[Roscio, Steve]

Thanx Paul for the quick answer!  VTI devices and marking looks like the right way to go; I really like how each connection can have its own interface.  Sadly, tho, our central servers are stuck on RHEL6 with a 2.6-32 kernel due to the massive bureaucracy of our IT department :-(


Thus I'll dig into the NAT idea (any references for it are welcome), and your container idea has me thinking of trying network namespaces ... if that works I'll post a writeup to this list.


Thanx again,

- Steve

________________________________
From: Paul Wouters <paul at nohats.ca>
Sent: Thursday, June 22, 2017 12:47:08 PM
To: Roscio, Steve
Cc: swan at lists.libreswan.org
Subject: Re: [Swan] Duplicate RightSubnets by Varying LeftSubnets?

On Thu, 22 Jun 2017, Roscio, Steve wrote:

> Currently we require that the subnet exposed by each customer be unique. But this is met with
> resistance, understandably, since many customers use the same internal RFC-1918 private address spaces
> (10.0.0.0/8, 172.[16-31].0.0/16, 192.168.0.0/16).
>
> Is there a way to create host-to-subnet or subnet-to-subnet IPsec connections where the rightsubnets
> (customer-side) are the same or overlap?

Yes, when you use MARKing. You can also combine MARK with VTI
interfaces. See:

https://libreswan.org/wiki/Route-based_VPN_using_VTI

While this will resolve your issue of where to send replies to,
it still requires flows originating from your end to be told
for which target 192.168.1.1 these are meant. You can do that
by MARKing the packets (via iptables, custom kernel module, etc)

Some people build a NAT'ed IP range for their customers, so to
them all their customers appear as unique IPs, then de-NAT these
into the customers real IP's before it hits the IPsec tunnel.

A completely different solution is to use a container/cloud
instance which only contains one customer per instance, so it
will never conflict.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20170622/92b40db3/attachment-0001.html>