ExpressRoute Private peering and Configure S2S VPN over ExpressRoute as well as configure the NAT for VPN gatewa

Hi @Harish Peddapally , Appreciate your detailed response. I have follow up question, is this going to work if that there's two disjoint CIDR of network advertised separately,
let say for example we advertise via BGP in ExpressRoute is the CIDR of 192.168.0.0/16 on-premise network routing to Azure, And in S2S over ExpressRoute connection we don't use BGP but we advertise to that IPsec tunnel is the 10.100.0.0/16 address space on-prem network to Azure, and that 10.100.0.0/ have overlapped one VNet in Azure and we're going to use the NAT of the S2S

Hi John Emil Billones,

Thanks for the detailed follow-up and great question.

Yes, your scenario of advertising two disjoint CIDR blocks over ExpressRoute and S2S VPN with NAT can work effectively, given some important considerations:

1.Advertising Disjoint CIDRs

• You can advertise one CIDR (e.g., 192.168.0.0/16) over ExpressRoute private peering using BGP.
• Separately, advertise a different CIDR (e.g., 10.100.0.0/16) over the IPsec S2S VPN connection (without BGP).
• As long as these CIDRs are disjoint, Azure will route traffic appropriately based on prefix matches.
• Azure supports this approach to let you encrypt specific traffic via VPN while other traffic flows over ExpressRoute.

2.Handling the Overlapping VNet Address Space with NAT

• Since your Azure VNet has an overlapping address space with the 10.100.0.0/16 on-prem range, you will need to use Azure VPN Gateway NAT capability on the S2S VPN connection.
• This NAT translates IP addresses for traffic on the VPN tunnel, allowing the overlapping on-prem 10.100.0.0/16 to map to a non-conflicting IP range in Azure, preventing conflicts.
• NAT rules must be carefully planned — for example, mapping on-prem 10.100.0.0/16 to a different range like 172.16.x.x when traffic enters Azure.
• Remember that NAT only applies to the VPN connection, not ExpressRoute.

3.Routing and Preference

• The ExpressRoute path has routing priority by default. So, if there is any overlap or more specific prefixes advertised on VPN, Azure routes traffic accordingly based on prefix specificity.
• Since your CIDRs are disjoint, routing should split correctly with ExpressRoute handling 192.168.0.0/16 range and VPN (with NAT) handling 10.100.0.0/16.
• Ensuring no overlapping or conflicting advertisements in routes to avoid routing issues.

4.Additional Recommendations

• Ensure GatewaySubnet is sized properly (/27 or larger) if VPN and ExpressRoute gateways coexist.
• Test connectivity carefully, especially encrypted traffic flows and NAT translations.
• Update firewall and NSG rules to accommodate NAT translated IPs.

5.Relevant official docs you might want to review again:

Site-to-Site VPN over ExpressRoute Private Peering: https://v4.hkg1.meaqua.org/en-us/azure/vpn-gateway/site-to-site-vpn-private-peering

NAT configuration on VPN Gateway: https://v4.hkg1.meaqua.org/en-us/azure/vpn-gateway/nat-howto

Configure ExpressRoute and VPN coexistence: https://v4.hkg1.meaqua.org/en-us/azure/expressroute/expressroute-howto-coexist-resource-manager

Feel free to reach out if you want assistance on this.

Thanks,

Harish

Your explanation is very helpful. But there's another thing that makes the set-up more complex.
We are also having Azure Firewall in the VNet, and our plan is to create a UDR and with GatewaySubnet is attached, and we want to route that traffic through Azure firewall(NVA) to spoke(conflicted IP).
Does the set-up will still work and Do you have any inputs or suggestion on that set-up?

should we remove the associated route in GatewaySubnet? if yes, how can we route the traffics from on-prem to spoke (conflicted IP) through azure firewall?

Hi John Emil Billones,

Good day, i hope you are doing great!

Thanks again for your great follow-up! You’re absolutely right, introducing Azure Firewall into the mix adds another layer of complexity, but it’s a perfectly valid and achievable setup when done correctly. Let’s walk through how this architecture can work, and clarify your questions around GatewaySubnet UDRs, traffic flow, and routing on-prem to a conflicting spoke via Azure Firewall.

1. High-Level Architecture Flow:

Here’s the simplified traffic pattern based on your topology:

On-prem (10.100.0.0/16, NAT’d)

→ Azure VPN Gateway (S2S with NAT)

→ Azure Firewall (in Hub VNet)

→ Spoke VNet (overlapping range)

This ensures encrypted on-prem traffic traverses through the firewall before reaching the destination spoke network.

2. Should You Associate a UDR with the GatewaySubnet?

Microsoft strongly recommends not associating any UDRs to the GatewaySubnet. The VPN Gateway manages its own system routes, and attaching UDRs can disrupt VPN or ExpressRoute connectivity or cause unexpected behaviors.

Instead of applying a route table directly on the GatewaySubnet, manage routing using UDRs on the spoke and hub subnets to steer traffic through Azure Firewall.

Reference: Azure virtual network traffic routing​

3. How to Route On-Prem Traffic Through Azure Firewall to a Conflicted Spoke:

Step 1 – Enable NAT on the VPN Gateway:

Translate your on-prem 10.100.0.0/16 to a non-overlapping address range (for example, 172.16.100.0/24) using SNAT on the S2S connection. This allows traffic to enter Azure safely without conflicting with your spoke VNet.

Reference: Configure NAT on Azure VPN Gateway

Step 2 – Use UDRs on Spoke Subnets:

On the spoke network, create a UDR sending traffic bound for the translated on-prem range (e.g., 172.16.100.0/24) to the Azure Firewall private IP. This ensures return traffic flows through the firewall for inspection and logging.

Step 3 – Configure Routes on AzureFirewallSubnet (Hub):

On the subnet hosting Azure Firewall, create a route to send traffic destined for the spoke’s IP range (e.g., 10.100.0.0/16) directly to the spoke VNet via VNet peering. Double-check that route propagation doesn’t create loops or override system routes.

Step 4 – Firewall Policy Rules

Add appropriate DNAT/SNAT or network rules to:

Accept traffic from the NAT’d on-prem range (e.g., 172.16.100.0/24)

Forward it to the target spoke IPs This setup ensures symmetric two-way communication through the firewall.

4. Important Considerations:

• Avoid placing UDRs on the GatewaySubnet; rely on UDRs in the spoke and hub subnets for route control.
• Ensure VNet peering between hub and spoke allows both directions of traffic flow.
• Add proper allow rules on Azure Firewall for both inbound (from NAT’d on-prem range) and outbound (to spoke networks).
• Disable route propagation on spoke route tables to avoid on-prem BGP routes overriding your custom paths.
• Confirm GatewaySubnet is at least /27 to support coexistence of ExpressRoute and VPN gateways. Reference: Hub-spoke network topology in Azure

By following this model, your Azure Firewall will correctly handle NAT’d VPN traffic between on-prem and Azure spokes, maintaining a secure, inspected path even when overlapping address spaces exist.

i hope this helps, please do let me know if you have any questions on this.

Thanks,

Harish.

Hi John Emil Billones,

Greetings for the day!

Just checking to see if you have a chance to check my previous response and helped, do let me know if you have any further questions on this.

Thanks,

Harish.