VPN Topologies Guide
VPN topology overview
VPN has become a very important factor for businesses. Especially as a company grows, more remote sites are requiring remote connectivity as well as mobile connectivity for remote users.
So it is important to have a firewall or VPN device that can support such growth. The firewall must also be able to support flexible VPN topology deployments. We will talk about the three most common VPN topologies
Site to Site
At a minimum a firewall should be able to support site to site VPN. This is just two VPN sites connected directly to each other. So as for the VPN IPSec config it is just a matter of configuring the phase1, phase2 settings, creating firewall policies inbound and outbound, and ensuring the same is done at the other site.
Hub and Spoke
In this topology all remote sites connect to the head office site. Remote sites are like all the spokes on a bicycle wheel which connect to the hub of the wheel (head office). For a multi site VPN scenario a hub and spoke topology is the most common implementation. A central hub will enable not only connectivity from remote site to the hub and the hub to the remote sites, but acts as a gateway for remote sites to communicate with each other via the hub.
Going off the scope a little I'll give an example below how this would be configured on a Fortinet firewall.
On a Fortinet Fortigate firewall acting as the hub you would do this by creating a phase 1 IPSec policy with an accept any peer (remote sites), and a phase 2 IPSec policy associated with the phase 1. You will have then created an IPSec virtual interface. You can now create two firewall policies, one from the internal interface to the virtual IPSec interface and the other way around. You will also specify the addresses behind both the hub and spoke networks. The addresses behind the spoke networks can be grouped together using address groups, so you can use this one address group in both inbound and outbound firewall policies to specify all remote subnet address of you spokes (remote site).
The firewall policies will look like the below;
Firewall policy one
Source interface - Internal Hub interface
Source address - Internal hub subnet address ->
Destination interface - virtual IPSec interface
Destination address - remote address group (this will be subnet addresses for the internal networks behind the spokes)
Firewall policy two
Source interface - Remote address group (this will be subnet addresses for the internal networks behind the spokes)
Source address - Virtual IPSec interface ->
Destination interface - Internal hub subnet address
Destination address - Internal Hub interface
Now you have a spoke to hub and hub to spoke VPN configuration on the hub side. From the spoke end you just need to configure a VPN as you would configure a standard site to site config to the hub.
However more work needs to be done if you require all spokes to communicate with each other via the hub as well. For spoke to spoke communication, on the hub you would configure a zone with the virtual IPSec interface specified. Then you create a firewall policy and where you specify an interface, you would specify the zone just created for both source and destination. You can also apply any other services such as UTM in the firewall policy.
On the spoke side some further alteration is required as well. All As well as the Hub address all other spoke addresses have to be specified in both firewall policies, again you can group these together via an address group. You have now a VPN config where all remote sites can communicate via the hub.
Meshed VPN Topology
This topology requires the most work. However it also provides the most reliability. Here all sites are connected to each other. There is no hub. In the previous Hub and spoke topology, if the hub dies or there is a connection problem to the hub, all sites will have no connectivity. However in this case there is no hub, so if a site has a hardware failure, only that site will be down, all other sites can still communicate with each other.So here in each site’s VPN device you have to specify all other sites, and create the required phase 1 and phase 2 settings and firewall policies for the number of sites. Every site will be connected to every other site. However the more sites there are the more connections and this can multiply very quickly, making it unmanageable.
Wikipedia's guide to VPN