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 configuration 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 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 "Shanghai"

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 protected 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 configured, 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 initiator 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 name is 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 preferred 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.

• For classic Spoke to Hub VPN tunnels, Spokes can be located behind a NAT device as long as all required ports for an IPSEC tunnel establishment are open (usually UDP ports 500 and 4500).

• 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.