Site to site IPSec VPN over Express Route

Ali Shaikh 0

We have a requirement from the customer to build IPSec over Expressroute circuit. In Azure we have a Hub and spoke topology. Resources deployed in the spoke needs to communicate with on-prem networks using the IPsec tunnel. It is observed that traffic from Azure is not going via the IPSec tunnel.

Currently IPSec us not configured with BGP and its only using traffic selectors to route traffic.

Routing over IPSec:

On Prem Network: 172.16.1.240/32

Azure Network: 10.247.218.128/26

Routing over ER (BGP):

On Prem Network: 172.16.1.0/32

Azure Network: 10.247.218.0/24

Log Analytics indicate the traffic is taking the route over ER circuit and not the IPSec VPN. As per Azure documentation Longest prefix match should be the route selection criteria. I am struggling to understand why the traffic is not routing through IPSec tunnel.

Marcin Policht 29,885 Reputation points MVP

2024-12-13T04:25:34.34+00:00
As far as I can tell, this behavior likely stems from the route selection precedence in Azure's routing infrastructure. Azure follows specific rules when evaluating and selecting routes, and while longest prefix match is one criterion, other factors may override it.

This includes the following:

Route Type Precedence Azure uses a hierarchy for route selection, where system-defined routes (like those for ExpressRoute) take precedence over user-defined routes (UDRs) for the same destination, even if the UDR has a longer prefix match.

ExpressRoute Prefix Advertisement The BGP route for 172.16.1.0/32 advertised via ExpressRoute might be prioritized over the IPsec VPN route because:

ExpressRoute is a Microsoft-managed route, and Azure treats these routes as higher precedence compared to custom IPsec routes.

Traffic selectors in IPsec VPN are typically only used to establish the tunnel and are not actively enforced for routing decisions in Azure unless explicitly configured.

Overlapping Prefixes

You mention that IPsec is using 172.16.1.240/32 while ExpressRoute advertises 172.16.1.0/32. If the system route for 172.16.1.0/32 via ExpressRoute exists, it might override the longer prefix match of 172.16.1.240/32 due to route type precedence.

Traffic Selector Scope Traffic selectors do not directly impact Azure's route selection; they only negotiate which traffic is allowed to pass through the IPsec tunnel. If Azure's routing table directs traffic via ExpressRoute, it will bypass the tunnel, regardless of the selectors.

To address this, you might consider the following:

Option 1: Use a User-Defined Route (UDR)

Create a UDR for the Azure subnets that need to communicate with the on-prem network.

Add a UDR with the destination 172.16.1.240/32 (or other specific prefixes for on-prem) and specify the virtual network gateway (used for the IPsec tunnel) as the next hop.

Associate the UDR with the subnets where the spoke resources are deployed.

Option 2: Advertise More Specific Prefixes via IPsec If possible, configure the on-premises side of the IPsec VPN to advertise the specific prefix 172.16.1.240/32 instead of or in addition to 172.16.1.0/32. This ensures the IPsec route is considered a better match by Azure's routing logic.

Option 3: Adjust ExpressRoute Advertisements

If you can, stop advertising 172.16.1.0/32 via BGP over ExpressRoute. This will force Azure to route traffic for 172.16.1.240/32 through the IPsec tunnel.

Option 4: Configure BGP for the IPsec VPN Enabling BGP for the IPsec VPN allows you to advertise routes dynamically. Azure will evaluate all routes and prioritize based on longest prefix match and route type precedence.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
Ali Shaikh 0 Reputation points

2024-12-13T04:44:59.1466667+00:00

Thank you Marcin for detailed and a quick response on this.

I would like to make some changes to the original question where I mistyped a subnet prefix. The correct details are here below.

Routing over IPSec:

On Prem Network: 172.16.1.240/32

Azure Network: 10.247.218.128/26

Routing over ER (BGP):

On Prem Network: 172.16.1.0/24

Azure Network: 10.247.218.0/24

Another resource that I did not mention in my question earlier was an Azure virtual Firewall which sits in the Hub subnet. All traffic from spokes are routed to the Azure FW using UDRs with default route pointing to the Azure Firewall internal IP.

I have already tried option 1 and option 2 but that did not resolve this issue. I will have a go at option 3 and option 4 as you suggested.

Thank you for your input on this.

1 answer

KapilAnanth-MSFT 48,081 Reputation points Microsoft Employee

2024-12-16T06:50:42.4933333+00:00
@Ali Shaikh ,

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I see you are following Configure a Site-to-Site VPN connection over ExpressRoute private peering.

Wrt your verbatim,

1 . I am not sure how you say Azure advertises "10.247.218.128/26 over IPSec" and "10.247.218.0/24 over ExR"

This is not correct

Azure will always advertise the entire Azure VNET's range(and peered VNETs) in both the case.

See : Traffic advertised from Azure

This means, you have to make sure that the OnPrem routes the traffic to Azure in the desired way. i.e., either via VPN Device or ExR

2 . You also mentioned On Prem Network advertises "172.16.1.240/32 over IPSec" and "172.16.1.0/24 over ExR"

In this case, traffic from Azure to OnPREM destined to 172.16.1.240/32 should go via IPSec tunnel only.

I believe this is because BGP is not employed here

I see the recommendation here is to use BGP, refer : Route Traffic from Azure to on-premises networks

And the only option mentioned here is to Advertise more specific prefixes on the VPN BGP session when there is a overlap between the address prefixes of the ExR and VPN.

I would suggest you start using BGP if you would like to route traffic via IPSec

Kindly let us know if this helps or you need further assistance on this issue.

Thanks,

Kapil

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.
Please sign in to rate this answer.
Ali Shaikh 0 Reputation points

2024-12-19T21:39:50.8766667+00:00

HI Kapil,

Thank you for following up on this.

I think I have sorted the issue, but I will need to test it. Since all traffic was going through the Azure firewall and it was being sent to a public IP address (168.217.20.x/24 which I did not mention and I just used a private IP 172.16.1.0/24 range to explain my scenario) which was used internally only and not over the internet, the Azure Firewall was source NAT'ng the traffic when it was traversing the firewall to its private IP address. We had to oberride the behavior by excluding the public IP address from SNAT.

When this was done, I could see the traffic appear on the on-prem firewall on the IPSec tunnel interface.

KapilAnanth-MSFT 48,081 Reputation points Microsoft Employee

2024-12-23T05:36:49.99+00:00

@Ali Shaikh ,

I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this!

Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others", I have converted our comments into an answer.

I'd greatly appreciate if you could "Accept" the answer as this can be beneficial to other community members reading this thread.

Cheers,

Kapil
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Site to site IPSec VPN over Express Route

1 answer

Your answer