Creating Your First Peering
A peering consists of a node and a peer virtual appliance. The difference between the two is that the subnets on the side of a node have access to subnets on the side of the peer, but not the other way around. If we continue with the example described in the previous section, the node can be thought of as the consultant's virtual appliance, whilst the peer is the client's virtual appliance. This is because the consultant wants to access the client's network, but does not want the client to have access to the consultant's network.
Peerings are created within Groups, which are used as a way to organise a group of peerings. In a consultant and client context, a Group could be used to organise all of the peerings for a particular client or engagement. Groups can be created in the Dashboard by navigating to "Groups" and selecting "New Group".
Once a Group has been created, peerings can be configured under that Group by navigating to "Peerings" and selecting "New Peering". This is also where the node and peer subnets are defined. Typically, a single node subnet will be advertised, and this will be the same subnet that the node virtual appliance is expected to be assigned an IP address on. As many peer subnets as necessary may be advertised.
Although multiple node subnets can be advertised, this would at present require a router to perform routing between the various node subnets, or may necessitate that static routes be configured on the hosts that need to be able to traverse the tunnel. This caveat does not apply to peer subnets, as all tunnel traffic is NATed to the peer virtual appliances IP address prior to being forwarded to any peer subnets.
If any of the subnets you are advertising overlap with a subnet the peer is also advertising, they will need to be translated. This is because subnets must be unique between node and peer networks, otherwise correct routing cannot take place. In such cases, you will be prompted to configure an appropriate subnet translation. The virtual appliances on both sides will take care of the actual translations for you, but you will need to ensure you use the translated addresses when communicating with the peer subnets.
Keys & Shared Secrets
Whenever a peering is created, a node and peer key in the format of
XXXX-XXXX-XXXX-XXXX is generated. You should share the peer key with the remote side, as they will need to input this key into their virtual appliance.
At this point you should also agree on an 8–16 character shared secret. Ideally, this secret should be shared via an alternate communications channel than the one used for the key. For instance, if the peer key was shared via email, then the secret could be shared via a text message.
Next, we will go through the setting up of the Autotunnel Virtual Appliance.