Azure Virtual Network: What is the difference between Policy-based and Route-based VPN?

You want to configure a Site-to-Site (S2S) VPN tunnel from an on-premises hardware VPN device, such as your firewall, and an Azure Virtual Network. For this, you require several objects in Azure. One of those is a “virtual network gateway”–which is basically just a software VPN appliance with a public IP that you will connect to.

This software VPN is really just a Windows RRAS server in the background, and it is capable of making various types of VPN connections, to accommodate different vendors and requirements.

One of the first questions you are presented with is VPN type: “Route-based” or “Policy-based.” In my experience, most Windows system admins aren’t as network savvy, and have no idea how to answer this question. So let me help you out, if that happens to be you.

Route-based vs. Policy-based

In my setup, I always use WatchGuard firewalls at my perimeter, and as long as I’m running an up-to-date firmware on that device, I have both options available to me. Both Policy-based and Route-based are legit choices.

With your own device, you can check out this page from Microsoft Azure docs, to see which type your device supports.  So technically either might work for you just fine, so long as you pick an option that is supported by your hardware vendor. That is key point numero uno.

However, when I have the option between both (like I do with my WatchGuards), I am going to choose Route-based.  The short version is, it unlocks the option for dynamic routing, and is technically more efficient, especially in larger environments. In a nutshell: it gives you more scalability, as well as more flexibility and options for enabling complex designs.

The long version of why I prefer route-based

When I choose a Route-based connection, I get to use what WatchGuard terms “BOVPN virtual interfaces” (as opposed to the legacy BOVPN / Policy-based VPN).

The newer virtual interfaces give me more flexibility in my designs, and wider options down the road. For example, I can configure more complex routing scenarios, like dynamic routing, adding new sites or subnets, failover/weighted routes with priority, and so on. Plus, the tunnels come up faster in my testing than they do using the policy-based / traditional BOVPN on the same appliance.

This is because the virtual interface for the VPN is added into the routing table on the firewall, and it knows what networks are route-able through it. So updating the virtual interface will update the routing table instantly. Or you can move things around in your routing table also, and routing will be updated accordingly on the fly.

With the old style BOVPN, you did not have a routing table like that, instead you had policies that were created when you built the VPN,  and that means any traffic was routed based on the policy list in the firewall, which also controlled the traffic to and from the remote network. These are a bit clunkier and require more processing/overhead on the firewall, plus it requires you to update those policies whenever things change. Last, the policy order was of utmost importance, because in some circumstances, you might be inadvertently blocking site-to-site traffic that you did not mean to, if your ordering was incorrect.

Down the wrong rabbit hole… 

Here is where we enter the Matrix and it gets more confusing: a Route-based VPN can also be configured for “static routing” or “dynamic routing.” I know, clear as mud, right?

True dynamic routing is preferred in complex environments where multiple admins might be adding networks or changing routes on a more frequent basis. In this scenario, dynamic & route-based VPN configuration would be best, to make these updates more or less “automatic” on either side of the connection.

But route-based VPN can also be configured for static routing, and this is sometimes preferred in simpler environments that tend not to change, and are mostly static, as the name suggests (which again is most small businesses).

• Here is WatchGuard’s kb on configuring Route-based (but static) VPN
• Here is their article on configuring Route-based (dynamic) VPN

The main difference is these is that the virtual interface needs to have an IP address associated with it in the dynamic method. The benefit of doing Route-based and static over the Policy-based static method is that (in my opinion on the WatchGuard anyway), the setup & maintenance is a bit easier, and it will still use the newer virtual interface and routing table, rather than the legacy policies.  So there is still some more flexibility there, and I’m not locked into a purely static, policy-based option.

Just note that you won’t have “automatic” updating if networks are added/changed on either side of the connection, when you go with static configuration. In my experience, I have not yet run into a scenario where true dynamic routing would be required in the small business space (10-75 users), or even larger mid-sized enterprises (say 75-150+ users). But it is good to know that WatchGuard does indeed support both options.

To recap

All of that to say, most SMB environments will never really need to use the benefits of a “dynamic” routing environment, because they tend to be more static in nature, and Policy-based VPN is perfectly fine for that. So if it is your only option, don’t feel bad.

I personally like to be on the newer / less restrictive technology whenever possible, in case I need to leverage additional capabilities down the road, or expand my solutions/offerings to clients without creating more snowflakes & variations. And like I said, I think that the BOVPN virtual interfaces are a bit more intuitive, and easier to setup than traditional BOVPN anyway, and faster–though I’m not sure if the same holds true for every hardware vendor–I just have this experience with my WatchGuards.

Last point: you just need to follow your vendor’s documentation, pick a supported option to set everything up correctly.