Fortinet black logo

Handbook

IPsec Auto-Discovery VPN (ADVPN)

6.0.0
Copy Link
Copy Doc ID 4afb0436-a998-11e9-81a4-00505692583a:348822
Download PDF

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.

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.