Azure VPN – ACL confusion clarified

Azure currently only supports VPN connections with static routing. For such a simple set up, there is a surprising amount of confusion in documentation, and with vendor support. Given the lack of clarification found on the internet, this may help a few others.

Similar to AWS, during Azure VPN deployment, a sample configuration template can be downloaded, which can be modified to use on your own devices. For the route-based VPN configuration, the downloaded template, as well as those shown in official documentation, like this sample Azure VPN template, includes the definition of an ACL like this:

As a network engineer will notice, the ACL is defined, but never used. When asking Azure team, the answer got back was “the template has worked for other customers”. What they said turned out to be true, here are explanations for those who care for how things really work.

First, there are two different types of VPN connections, the table below compare the two side by side (for technical details refer to excellent illustrations by packetlife.net). Here we use the Route-based VPN, which Azure refers to as “Dynamic routing”. This, by the way, is an incorrect term. Because only the establishment of VPN is dynamic, no dynamic routing like BGP is supported with Azure at the moment. More importantly, Route-based VPN does not require an ACL, while Policy-based VPN does.

VPN type	Policy-based	Route-based
Microsoft term	static routing	dynamic routing
Require ACL	yes	no
Detailed explanation and configuration	http://packetlife.net/blog/2011/aug/15/policy-based-vs-route-based-vpns-part-1/	http://packetlife.net/blog/2011/aug/17/policy-based-vs-route-based-vpns-part-2/

For the Route-based VPN (or Azure’s “dynamic routing”) option, Microsoft’s documentation and Azure generated configuration includes an ACL but not using it, was the source of confusion. This also explains why it still works for other customers, the ACL is simply not used. Therefore, it is recommended that the ACL be removed, to avoid further confusion to your support and operational teams.

It’s puzzling such a basic mistake remains uncorrected for so long, any network engineers at Microsoft?