A lot of customers on Azure want to use the 3rd party firewalls that are available in the Azure Marketplace. But when it comes to Site2Site VPN connections, sometimes it doesn’t work as expected. Especially when using different vendors on-premises.. Why? let’s find out…

Azure itself does not support all protocols inside its network.. Broadcast, IP-in-IP and GRE packets are blocked (link)

Many vendors have their own proprietary VPN solution (like TINA in Barracuda) that will work as long as you have the same vendor on both sides (as they don’t use GRE). But when you configure a VPN between two different vendors, it will (likely) fallback to IPSec.. which does use GRE and that is not supported in Azure in some scenario’s..

Usually the problems occurs when configuring firewalls in High-Availability Mode.. this architecture in many cases uses an Azure Load Balancer (it doesn’t support a floating / shared IP addresses) to load balance the two FW instances (read VM’s) in Azure. The Azure load balancer does not load balance, nor NAT’s the GRE packets and this cannot be configured either (as per July 2016) and therefore IPSec VPN’s cannot be established through the load balancer.. the annoying thing is, that if you actually try to configure it, is that in some cases, the tunnel itself IS established, but no data packets are received on either site..

Does this mean you cannot use 3rd party firewalls in a mixed environment for Site-to-Site connections back to the on-premises network? No, you can still use it.. but you need to take into account some specifics..

The GRE protocol is blocked inside the Azure network, but it will be able to reach your outer (public) IP addresses assigned to VM’s. If you want to load balance your firewalls, make sure to set an IP address for each of the FW’s directly on the VM instead of the load balancer. So you end up with 3 IP addresses minimum (1 for the load balancer, 2 for the FW’s (one for each)). Only then will the VPN tunnel be able to be established … and you can create 2 obviously (one to each firewall).

As long as the VM (3rd party FW) has the external IP address directly on its Network Interface, it should all work..