IPsec Auto-Discovery VPN (ADVPN)
Consider a company that wants to provide direct secure (IPsec) connections between all of its offices in New York, Chicago, Greenwich, London, Paris, Frankfurt, Tokyo, Shanghai, and Hong Kong.
A straightforward solution is to create a full mesh of connections such that every site has eight IPsec configurations, one for each of the other sites. If there were ninety sites, that could still be done but now the configuration is becoming tedious, since every time a new site is added, N-1 other sites have to have their configuration updated.
An efficient and secure alternative is IPsec Auto-Discovery VPN (ADVPN), which allows a minimum amount of configuration per site but still allows direct IPsec connections to be made between every site. RFC 7018 essentially describes this problem, along with some requirements for candidate solutions.
The ADVPN solution involves partitioning the sites into spokes and hubs such that a spoke has to have enough IPsec configuration to enable it to connect to at least one hub. A hub does not have specific configuration for each spoke, so the amount of configuration does not grow with the number of spokes that are connected to that hub. A hub to hub connection would typically involve both hubs having configuration for each other.
So, one possible partition for the original nine sites would be that Chicago and Greenwich would be spokes for the New York hub, Paris and Frankfurt would be spokes for the London hub, and Tokyo and Hong Kong would be spokes for the Shanghai hub:
Once a spoke has established a connection to its hub then initially IPsec traffic to another site transits via one or more hubs. For example, traffic from Chicago to Hong Kong would transit via the New York and Shanghai hubs. This transit traffic then triggers an attempt to create a more direct connection.
In FortiOS:
- Direct connections are only created between the two endpoints that want to exchange traffic (e.g. Chicago and Hong Kong); we do not create intermediate connections say Chicago to Shanghai, or New York to Hong Kong) as a side-effect.
- Learning the peer subnets is done via a dynamic routing protocol running over the IPsec connections.
- Negotiation of the direct connections is done via IKE.
- Both PSK and certificate authentication is supported.
Example ADVPN configuration
Since dynamic routing with IPsec under FortiOS requires that an interface have an IP address, then for every site a unique IP address from some unused range is allocated. For example we’ll assume that 10.100.0.0/16 is unused and so assign the IP addresses:
- Chicago 10.100.0.4
- Greenwich 10.100.0.5
- New York 10.100.0.1
- London 10.100.0.2
- Shanghai 10.100.0.3
- Paris 10.100.0.6
- Frankfurt 10.100.0.7
- Hong Kong 10.100.0.8
- Tokyo 10.100.0.9
We’ll assume that each site has one or more subnets that it protects that it wants to make available to the peers. For the purposes of exposition we’ll assume there is only one subnet per site and they are allocated as:
- Chicago 10.0.4.0/16
- Greenwich 10.0.5.0/24
- New York 10.0.1.0/24
- London 10.0.2.0/24
- Shanghai 10.0.3.0/24
- Paris 10.0.6.0/24
- Frankfurt 10.0.7.0/24
- Hong Kong 10.0.8.0/24
- Tokyo 10.0.9.0/24
Our example network topology now looks like this:
The configuraton in Chicago would be as follows:
config vpn ipsec phase1-interface edit “New York”
set type static
set interface wan1
set remote-gw <New-York-IP-address>
set psk <New-York-PSK>
set auto-discovery-receiver enable next
end
The attribute auto-discovery-receiver indicates that this IPsec tunnel wishes to participate in an auto- discovery VPN. The IPsec interface would then have its IP assigned according to the Chicago address:
config system interface edit “New York”
set ip 10.100.0.4/32
set remote-ip 10.100.0.1 next
end
RIP (for simplicity, you could use OSPF or BGP) is then configured to run on the IPsec interface and on the Chicago subnet (you could use redistribute connected, but we’ll allow for the fact that there may be other subnets learned from another router on the 10.0.4.0/24 subnet):
config router rip
edit 1
set prefix 10.100.0.0/16 next
edit 2
set prefix 10.0.4.0/24 next
end
Other than the firewall policy and a minimal phase 2 configuration, this concludes the configuration for Chicago.
Each spoke would have a similar configuration.
The New York hub would have a dynamic phase 1 for its spoke connections, and two static phase 1s for its connections to the other hubs:
config vpn ipsec phase1-interface edit “Spokes”
set type dynamic set interface wan1
set psk <New-York-PSK>
set auto-discovery-sender enable set auto-discovery-psk enable
set add-route disable next
edit “London”
set type static
set interface wan1
set psk <New-York-London-PSK>
set auto-discovery-forwarder enable next
edit “Shanghai”
set type static
set interface wan1
set psk <New-York-Shanghai-PSK>
set auto-discovery-forwarder enable next
end
The ‘Spokes’ connection has set auto-discovery-sender enable to indicate that when IPsec traffic transits the hub it should optionally generate a message to the initiator of the traffic to indicate that it could perhaps establish a more direct connection. The set add-route disable ensures that IKE does not automatically add a route back over the spoke and instead leaves routing to a separately configured routing protocol.
The two inter-hub connections have set auto-discovery-forwarder enable to indicate that these connections can participate in the auto-discovery process. The interface IP addresses are assigned:
config system interface edit “Spokes”
set ip 10.100.0.1/32
set remote-ip 10.100.0.254 next
edit “London”
set ip 10.100.0.1/32
set remote-ip 10.100.0.2 next
edit “London”
set ip 10.100.0.1/32
set remote-ip 10.100.0.3 next
end
Following this, RIP is enabled on the relevant interfaces:
config router rip edit 1
set prefix 10.100.0.0/16 next
edit 2
set prefix 10.0.1.0/24 next
end
A similar configuration would be used on the other two hubs.
Traffic flow and tunnel connection
With the configuration in place at all spokes and hubs, assuming all the spokes are connected to a hub, then Chicago would learn (via RIP) that the route to the Hong Kong subnet 10.0.8.0/24 is via its “New York” interface. If a device on the Chicago protected subnet (say 10.0.4.45) attempted to send traffic to the Hong Kong proected subnet (say 10.0.8.13) then it should flow over the New York interface to New York, which should then transmit it over the Shanghai tunnel to Shanghai, which should then send it over the dynamically negotiated Hong Kong tunnel to Hong Kong.
At the point when the traffic transits New York it should notice that the Chicago Spoke tunnel and the Shanghai tunnel have auto-discovery enabled, causing the New York hub to send a message via IKE to Chicago informing it that it may want to try and negotiate a direct connection for traffic from 10.0.4.45 to 10.0.8.13.
On receipt of this message, IKE on Chicago creates the (FortiOS-specific) IKE INFORMATIONAL SHORTCUT- QUERY message which contains the Chicago public IP address, the source IP of the traffic (10.0.4.45), the desired destination IP (10.0.8.13), and the PSK that should be used to secure any direct tunnel (if certificates are confgured, it is assumed that they all share the same CA and so no additional authentication information is required). This message is sent via IKE to New York since routing indicates that New York is the best route to 10.0.8.13.
On receipt of the IKE INFORMATIONAL query, New York checks its routing table to see who owns 10.0.8.13. It finds that 10.0.8.13 should be routed via Shanghai, and since Shanghai is marked as an auto-discovery-forwarder then the query is forwarded.
Shanghai repeats the process, finds that 10.0.8.13 should be routed via its Hong Kong Spoke and so sends it to Hong Kong. Hong Kong checks 10.0.8.13, finds that it owns the subnet, so it remembers the Chicago public IP address (and PSK) and creates an IKE INFORMATIONAL reply message containing its external IP address. To work out where to send the IKE message, the FortiGate does a routing lookup for the original source IP (10.0.4.45), determines that the message should be routed via its Shanghai tunnel and so sends the reply back to Shanghai. The reply then makes its way back to Chicago following the reverse of the path that it used to arrive at Hong Kong.
When the reply makes it back to the Chicago initator then it now knows the IP address of the Hong Kong device. Chicago now creates a new dynamic tunnel with the remote gateway as the Hong Kong public IP address and initiates an IKE negotiation (the dynamic tunnel nameis auto-generated from the tunnel over which it performed the query; in this case it would be called ‘New York_0’).
This negotiation should succeed since Hong Kong is set up to expect an attempted negotiation from the Chicago public IP address. Once the negotiation succeeds, RIP will start to run on the newly created tunnels at Chicago and Hong Kong. This will update the routing on Chicago (and Hong Kong) so that the prefered route to 10.0.8.0 (10.0.4.0) is via the newly created tunnel rather than via the connection to New York (Shanghai).
Notes about ADVPN in FortiOS
- Auto-discovery is only supported by IKEv1.
- All Spokes must have an IP address that is routable from any other spoke; devices behind NAT are not currently supported.
- The feature requires the use of a dynamic routing protocol. There is no support for IKE handling routing.
- RIP is not a very scalable routing protocol. When there are more than a few spokes it would be advisable to use route summarization to avoid huge RIP updates. Better yet, use BGP instead of RIP.
- It is assumed that spokes will not be used to transit other spoke traffic, for example: traffic from Chicago to Tokyo would not transit an existing Chicago to Hong Kong tunnel even though that has a shorter hop count than a route via New York and Shanghai.
- There is no facility to allow you to filter which traffic that transits the hub should trigger the message sent to the initiator suggesting it create a direct connection. Currently any and all traffic will trigger it.