[Swan] Routing between two different tunnels

[Paul Wouters]

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