Azure Site To Site VPN Through Private IP With Azure Firewall

In this pattern, we leverage the Azure Virtual Network Gateway’s private IP address as the Ikev2 tunnel termination endpoint to for a VPN tunnel through Azure firewall’s public IP addess.

Architecture

Azure VPN Gateway Configuration

Firewall DNAT and Network Rules

User Defined Routes

Considerations

Conclusion

Architecture

VPN Gateway Configuration

• Deploy a route-based VPN gateway

• Make sure to choose a Zone-Redundant SKU (like VpnGw1AZ, VpnGw2AZ, etc) because they’re the only ones that support VPN over private IP (Azure Docs)

• Create your local gateway (what’s a local network gateway? Here’s the Azure docs link). In my case, below is my local gateway configuraiton:

  IP Add: 52.252.99.40
  ASN: 65515
  BGP Peer IP: 192.168.200.4
  
  

• Create a new connection on your vgw:

  • Toggle “Use Azure Private IP Address”.

  

With the above settings, you can now use the private VNET gateway IP address to terminate the VPN tunnel (check the IP address used in your gatewaySubnet, that’s the one).

Firewall Rules

• Destination NAT Rules: These allow traffic originating from the outside VPN endpoint to be translated to the private gateway IP address.

  DNATRuleCollection: 
  src: 52.242.99.40/32, dst: 52.10.3.5 <--fw public IP
  ports: udp 500, 4500 (<-- this is for NAT-Traversal)
      NAT: 10.0.1.10 (VGW)
  
  

• Network rules: After DNAT is performed, firewall logic will check network rules to ensure that this traffic is allowed through. So we’ll need the rule below:

  NetworkRuleCollection: 
  src: 52.242.99.40/32, dst: 10.0.1.10
  ports: udp 500, 4500
      Action: allow
  
  

With this, traffic from the outside VPN endpoint reached the gateway with its public IP address.

User Defined Routes

The next thing we need is to force tunnel all traffic from the GatewaySubnet destined to the outside VPN enpoint’s public IP to Azure Firewall. Below is the UDR we need to attach to that subnet:

prefix: 52.242.99.40/32
	next-hop (virtual appliance): 10.0.2.10 (AZFW private IP)

Considerations

Please consult with a Microsoft Solution Architect of Network global Black Belt to understand what the implications of this architecture are. I’d also recommend to question the driver behind your requirements for doing this over private IP address. They may be valid, but adding a Firewall is an additional layer that adds relative complexity

Conclusion

After you configure the outside endpoint, the tunnels should come up and, if you chose to use BGP, the peer status will come up.

View your BGP Peer status

az cli command: az network vnet-gateway list-bgp-peer-status --ids /subscriptions/{sub-id}/resourceGroups/{resource-group}/providers/Microsoft.Network/virtualNetworkGateways/{gateway-name}

{
  "value": [
    {
      "asn": 65515,
      "connectedDuration": "00:00:02.3805462",
      "localAddress": "10.0.1.10",
      "messagesReceived": 1632,
      "messagesSent": 20963,
      "neighbor": "192.168.200.14", //<-- overlay vpn peer
      "routesReceived": 10,
      "state": "Connected"
    }
  ]
}

View your BGP Learned Routes

az cli command: az network vnet-gateway list-learned-routes --ids /subscriptions/{sub-id}/resourceGroups/{resource-group}/providers/Microsoft.Network/virtualNetworkGateways/{gateway-name}
{
  "value": [
    {
      "asPath": "65515",
      "localAddress": "10.0.1.10",
      "network": "192.168.200.0/24",
      "nextHop": "192.168.200.14",
      "origin": "EBgp",
      "sourcePeer": "192.168.200.14",
      "weight": 32768
    },
    {
      "asPath": "65515",
      "localAddress": "10.0.1.10",
      "network": "10.0.2.0/24",
      "nextHop": "192.168.200.14",
      "origin": "EBgp",
      "sourcePeer": "192.168.200.14",
      "weight": 32768
    }
  ]
}