What is ADVPN?

So, I was working with a client to deploy ADVPN on their Juniper SRX Firewalls and came across an interesting problem setting up the Certificates. I didn’t find anything useful online to troubleshoot this issue, so I thought I would write it up as a blog.

But first, I wanted to give those who have not come across ADVPN before a bit of background.

Auto Discovery Virtual Private Networks are a type of IPSEC VPN using extensions set out in RFC7018 “Auto-Discovery VPN Problem Statement and Requirements” by engineers from Juniper and HP.

ADVPN is implemented by Juniper, Fortinet, HP and a few other vendors - though as the RFCs are not full IETF standards, interoperability is a maybe rather than a definitely (I intend to do some interop testing for this in my lab when time allows - so will post another blog then).

It is similar to, but not compatible with, Cisco’s Dynamic Multipoint VPN (DMVPN) and aims to solve the same basic problem.

Hubs and Spokes

That problem is the Spoke to Spoke traffic problem which afflicts traditional Hub and Spoke VPN architectures as shown below:

Traditional Hub and Spoke VPN with Spoke to Spoke Traffic

We have a normal Hub and Spoke VPN setup, with three Branch Offices (Spokes) each connecting to the HQ / Data Centre (Hub).

This works great for North/South connectivity from a PC in a Branch Office to a Server in the DC (green line), but it not ideal for Branch to Branch communication (red line), where traffic has to go via the Hub.

This is particularly troublesome where, as in the case for this client, Branch B and C are both in the USA, while the HQ is in London, UK.

The Branch to Branch communication is not only wasting capacity at the Hub, but adding significant and unacceptable latency for the users.

Full Mesh?

You could set up a Full Mesh VPN architecture, where you build tunnels between each of the Branches, but this quickly becomes troublesome for a different reason.

A Full Mesh requires n-1 additional tunnels to be setup and maintained on each branch (where n is the number of branches). So for just 10 sites, each Firewall needs 9 tunnels - we would need 90 VPNs to be configured (one to each of the other Branches + one to the Hub).

This is wasteful of processing resources on the Branch Firewalls, as well as complex and time consuming to manage. But it does allow traffic to take the most direct route between any two hosts.

ADVPN

ADVPN gives you the best of both worlds.

You configure just a single connection from each Spoke (now called a Partner) to the Hub (now called a Suggester), much like a normal Hub and Spoke VPN (except now you do not need to change anything on the Hub to add an additional Branch once it is setup, it is done automatically).

ADVPN, with a Shortcut VPN established from Branch B to Branch C

When Branch B tries to send traffic direct to Branch C, the initial traffic will follow the path through the Hub as before - but now the Hub earns its new name, suggesting that the two Branch FWs dynamically establish a Shortcut VPN so that the traffic can travel directly between them by the most efficient route, just like if we had a Full Mesh.

How does it work?

Well, partly using some extensions outlined in the RFC to add the messages necessary for the Suggestions to be made and be understood. But beyond that ADVPN adds a couple of requirements:

Must use IKEv2 (the extensions are to the newer IKE standard)
Must be a Route Based VPN, with Point to Multipoint St0.x interfaces
Must use OSPF or iBGP to allow shortcut routes to be dynamically updated
Must use X.509 PKI Certificates for IKE Authentication

The X.509 Certificates are essential - each device in the ADVPN is issued a Certificate from a Certificate Authority which all of them trust (this is often setup using an Internal CA to save money).

Now when the Suggestor (the Hub) tells a Partner (a Branch/Spoke) to initiate a shortcut VPN to another Partner they have a way to confirm whether they should trust one another without us having had to pre-configure any other information.

With a way to dynamically establish our shortcut tunnel sorted, we can just bind each of the VPN tunnels to the same Secure Tunnel interface (in Point to Multipoint mode) so that OSPF/iBGP Adjacency can form and we can dynamically update our Routing table.

Voila all the good bits of Full Mesh but with the ease of a Hub and Spoke - even easier, as you do not have to change the Hub to add a new Spoke (well, apart from the need to run a CA or setup certs… that that is easier than you’d think).

Coming Up…

I will add another post soon with all the details of how to configure ADVPN on Juniper SRX and then we will look at that PKI troubleshooting…