On Thu, 15 Nov 2018, Matt Hilt wrote:
I'm trying to setup a (temporary) over-the-internet database replication
process. I am using libreswan in
two distinct ways:
"Mesh": The first method uses opportunistic IPSec to create a mesh of
tunnels between hosts within an AWS
VPC. I have this working well and each host can talk to each over over tunnels
currently.
Great :)
"S2S": The second method uses a subnet-to-subnet tunnel to connect a host in
a data center to a host in
the AWS VPC. The data center host is on a private subnet and talks through a
firewall out to the internet.
The AWS host has two interfaces, one public and one private. The private NIC
is connected to the mesh
network. The tunnel comes up and I can route traffic via my "VPN" gateways
from other hosts in the subnets.
Great too :)
Problem: The issue I have is that I want the traffic coming out of the S2S
tunnel to be forward through the
mesh tunnel(s) to the remote endpoint(s); likewise I want traffic coming from
members in the mesh subnet to
use the mesh tunnels when trying to connect hosts on the other side of the S2S
tunnel. This does not seem to
happen either automatically or via best feeble attempts at forcing it via
routing rules.
So this is a little tricker. You can have two meshes that are
independent, both of which contain a gateway to the other mesh's
gateway, using a subnet-to-subnet tunnel. In that case, the mesh
nodes need to send traffic to their gateway but as I think you found
out, because the destination IP is not that gateway/mesh, it is not
getting encrypted.
You can also add both private IP ranges to both meshes. And ensure
proper routing via the two gateways. Then you should be able to
initiate from a node in one mesh to a node in the other mesh. The
only additional tunnel is then one on two gateways covering
leftsubnet=mesh1/mask and rightsubnet=mesh2/mask. This would lead
to double encryption on the packets between the two gateways.
Questions:
* Is this actually a feasible/reasonable solution?
I think so, although the older 1990's version of Opportunistic
Encryption could not deal with this scenario. I cannot think of
why this should currently not be possible though. But I have not
tried it myself either.
* Am I missing something critical in my configurations to make this happen?
I don't know :)
* Any hints on magic routing settings or some term I can google for?
Hope the above helped?
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
