Project

General

Profile

Connecting Subnets Behind More Than Two Gateways » History » Version 1

Version 1/2 - Next » - Current version
Tobias Brunner, 15.07.2016 18:46


Connecting Subnets Behind More Than Two Gateways

Connecting subnets behind two gateways is pretty straight forward. You just setup a connection between the two and define the subnets as local and remote traffic selectors (local|remote_ts in swanctl.conf, left|rightsubnet in ipsec.conf).

But let's say you have three gateways A, B and C, each connected to a local subnet (10.1.0.0/16, 10.2.0.0/16 and 10.3.0.0/16, respectively) and want to connect the three subnets with each other.

There are basically two ways to do this:

  • Hub and spoke: Connect two (or more) gateways to the third central one. This requires one connection between each spoke and the the central hub (n - 1 connections for n gateways). So assuming A acts as hub that'd be connections A <-> B and A <-> C with extra subnets in the traffic selectors (or additional IPsec SAs if IKEv1 is used) for the subnets behind the spokes. For instance, for the connection between A and B you'd include the subnet behind C, that is, on A you have local_ts=10.1.0.0/16,10.3.0.0/16 and remote_ts=10.2.0.0/16, and on B local_ts=10.2.0.0/16 and remote_ts=10.1.0.0/16,10.3.0.0/16 (analogous for the connection between A and C).
             +---+
      +------+ A +------+
      |      +-+-+      |
      |        |        |
    +-+-+    +-+-+    +-+-+
    | B |    | C |    | D |
    +---+    +---+    +---+
    

    This hub-and-spoke setup may also be used to connect subnets behind just two gateways via a third gateway, as is demonstrated by the swanctl/net2net-gw scenario.

  • Full mesh: This requires establishing connections between all of the three (or more) gateways (for n gateways that's n * (n - 1)/2 connections). So in the example above this requires three connections (A <-> B, A <-> C, B <-> C) and each connection exactly has one subnet in the local and remote traffic selector. For instance, for the connection between A and B you'd just configure remote_ts=10.1.0.0/16 on B because traffic to 10.3.0.0/16 is handled by the separate connection between B and C.
             +---+
      +------+ A +------+
      |      +-+-+      |
    +-+-+      |      +-+-+
    | B +------|------+ D |
    +-+-+      |      +-+-+
      |      +-+-+      |
      +------+ C +------+
             +---+