The following diagram represents the tunnel between two Neutron routers that are constructed from the IPSec site connections created in the previous section:
Figure 12.15
Neutron automatically generates an ipsec.conf VPN configuration file according to the settings defined by the user. The configuration files can be found on the network node in the /var/lib/neutron/ipsec/<router_id>/etc/ directory that corresponds to the individual Neutron router. In this demonstration, the controller node is also the network node.
The following configuration files correspond to the EAST and WEST routers, respectively:
# Configuration for EastRouterVPNService
config setup
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
authby=psk
mobike=no
conn ada99bbe-4e96-4252-8d12-f9c981980942
keyexchange=ikev1
left=10.50.0.112
leftsubnet=172.25.30.0/24
leftid=10.50.0.112
leftfirewall=yes
right=10.50.0.113
rightsubnet=192.168.49.0/24
rightid=10.50.0.113
auto=route# Configuration for WestRouterVPNService
config setup
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
authby=psk
mobike=no
conn f3d96653-6bef-4f60-95c3-6d1c51853ee9
keyexchange=ikev1
left=10.50.0.113
leftsubnet=192.168.49.0/24
leftid=10.50.0.113
leftfirewall=yes
right=10.50.0.112
rightsubnet=172.25.30.0/24
rightid=10.50.0.112
auto=routeWhen traffic routed through a Neutron router matches a route and transform policy, the creation of a site-to-site VPN tunnel is initiated using the defined parameters. In this example, when traffic from a virtual machine behind the EAST router in the 172.25.30.0/24 subnet instance hits the gateway, a route lookup is performed within the router namespace. The following screenshot shows the routing table within the namespace:
Figure 12.16
Table 220 is created by Neutron and contains the route to the remote subnet 192.168.49.0/24 defined in the IPSec site connection, East-to-West:
Figure 12.17
Note how the next hop address is 10.50.0.113, which is the IP address of the WEST router. Once a route is determined, an XFRM lookup is performed. XFRM is a framework to transform packets, which includes encrypting their payloads and is used to implement the IPSec protocol suite in Linux. XFRM implements two important concepts in IPSec: security policies and security associations.
If you recall, the security association, or SA, contains the security parameters and keys that are used between peers. An SA is unidirectional, meaning that there should always be two—one for each direction or traffic. The ip xfrm state command can be used to determine the security associations in place. The security policy, or SP, defines the traffic to which a security association is applied, resulting in its encryption or any other action an SA may prescribe. The ip xfrm policy command can be used to determine the security policies in place.
In this example, the XFRM policy table contains three policies that match the traffic:
Figure 12.18
The first policy listed is known as a forwarding policy, and it matches traffic to and from virtual machine instances behind the VPN gateway. In this case, the VPN gateway is the Neutron router. It is a bidirectional policy where source and destination addresses work in both directions. The second and third policies are matched if the destination or source address, respectively, is assigned to one of the local interfaces of the Neutron router.
When a policy is matched, the source and destination addresses are matched against a single security association. Looking at the XFRM state table, we can see that no SA exists by default:
Figure 12.19
As traffic is generated, the kernel builds the appropriate security associations that match this tunnel and forward the traffic to the remote peer through the secure tunnel.
In the following example, the tunnel is in a DOWN state and will be initiated by a ping from the EAST instance to the WEST instance:
Figure 12.20
A single packet is lost as the creation of the tunnel is initiated and completed. Using the ip xfrm state command, we can see that the security associations are now established:
Figure 12.21
A quick look at the IPSec site connection list shows that both connections are ACTIVE:
Figure 12.22
Traffic is encrypted according to the parameters of the SA and routed to the remote peer, 10.50.0.113. The remote peer will have a similar configuration that allows for the decryption and forwarding of the packet to the host in the 192.168.49.0/24 network.
Once the tunnel is established, the instances will be able to communicate with one another via their fixed addresses provided the proper security group rules that allow communication between them are in place. The process of establishing the tunnel can take upwards of 5-10 seconds, though this time may vary between environments. Using SSH, we can confirm that access to the fixed IP of the WEST instance from the EAST instance is now possible over the VPN:
Figure 12.23