Azure Gateway VPN & Custom Routing via Third-Party Firewall Appliance

Within your Azure Virtual Network (vNET) you may require connectivity from an additional source, options available include:-

• vNET Peer
• VPN Gateway
• ExpressRoute Gateway

vNET Peer

Common connection method for theoretically peering onto another Azure vNET, routing is done via the the Microsoft backbone and to the end user it will look like an extension of their current vNET at the private IP addressing level. There are two types of peering availabe:-

• vNet Peering - Connectivity to vNETs within the same Azure region
• Global vNET Peering - A more recent advancement, allows the ability to connect vNets across Azure Regions

Gateways (VPN & ExpressRoute)

VPN Gateway is a virtual network gateway that creates a private connection between your on-premise site to vNET within Azure; alternatively vNET to vNET VPN Gateway's can be configured as well - to allow the ability of sending encrypted data between Azure and additional location. A note to add:- only one VPN Gateway can be deployed per vNET; additional VPN connections can be created to the same VPN Gateway.

Azure Routing

Whenever you create a vNET with multiple subnets; each subnet will automatically be assigned default system routes. Additional system routes cannot be added nor current ones edited but with the creation of a User Defined Routetable (UDR) - will override any default system route with your created UDR.

The default system routes:-

Next hop...

The next hop represents how Azure routes specific traffic to the destination address, hops above explained:-

• Virtual Network: Traffic destined to an address range within the vNET will be routed within the virtual network.
• Internet: When destination traffic is Internet-bound, the traffic flow will use the default route of 0.0.0.0/0 providing no User Defined Routes are in place or this will be overwritten if a UDR matches.
• None: Traffic being routed to none, Azure will drop the traffic. As shown above, Azure creates these routes for private IP addresses found in RFC 1918 & RFC 6598

Additional reading

How Azure Selects A Route

Azure Custom Routes

Azure Optional Default Routes

Gateways with User Defined Routes (UDR's)

The scenario

An environment is going to route traffic to a firewall appliance on a virtual machine before traffic coming inbound or outbound access the environment, traffic in question will be:-

• Internet traffic
• Traffic incoming from another vNET using VPN Gateway

Environment Overview

• vNET1 will be the "Production" vNET will an IP range of 10.0.0.0/24
• vNET1 will contain 3 subnets:- gatewaySubnet, firewallSubnet & webSubnet
• vNET1 will have a third-party firewall appliance in place
• vNET1 will contain a Web Server (WFE) & it will require access to the internet
• vNET2 will be the additional vNET configured using VPN Gateway with range of 10.1.0.0/24
• vNET2 will contain 2 subnets:- gatewaySubnet, userSubnet
• vNET will have the userAccess VM

Implementation

userAccess VM will want to access WFE VM & as mentioned within the scenario all incoming and outgoing internet traffic from vNET1 will have to be routed via the firewall appliance. For this to be implemented, User Defined RouteTables will be required to be added; if not, the default system routes will apply.

RouteTables are applied at the subnet level, the following would be applied to vNET1:-

webSubnet

gatewaySubnet

No RouteTable required on firewallSubnet as the default system routes will be suffice.

Note:- Within webSubnet route table, I added the route "to-vNET2"; indeed this is needed even though there is no requirement for WFE to access userAccess VM, but once the actual incoming traffic hits WFE the return packet will need to follow the same route. If the route is not returned the same way when a firewall appliance is in place, it cause cause a "Routing Triangle"

This message indicates that a TCP SYN followed by a TCP ACK has been detected, without the firewall having seen the TCP SYN-ACK from the destination host. This implies that a routing triangle exists in the logical network topology that causes the firewall to only see one side of a conversation. When this routing misconfiguration exists, it will cause connections between the affected networks to either not work, or to only work in one direction. Typically, this problem occurs when the firewall is defined as the default gateway IP address for systems on the LAN, and there exists a separate routing device connected to the same LAN that has connections to other networks. Often this is seen on networks with a private MPLS router for WAN sites. Please refer to the diagram below for an example of one such design that creates a triangular routing problem: Reference: Barracuda - https://bit.ly/2P8dCHJ

With the Route Tables in place; the end scenario will look like this: