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 <[email protected]> Sent: Thursday, June 22, 2017 12:47:08 PM To: Roscio, Steve Cc: [email protected] 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
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
