Azure VPN Gateway - VNET address space advertised

Von Jackson 1

Our company has multiple S2S connections established with customers. Our VPN Gateway has BGP enabled, however none of our S2S connections are using BGP. For most connection we need to NAT our ranges to prevent overlapping with customers. Problem we're having is that the complete 10.x.x.x address space of our VPN Gateway VNET is being advertised with the proposal. What is the reason for this? Is there a way to prevent that address space from being advertised with the proposal.

1 answer

GitaraniSharma-MSFT 47,006 Reputation points Microsoft Employee

2022-05-06T12:58:54.37+00:00
Hello @Von Jackson ,

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

I understand that you have multiple S2S connections established and your VPN gateway has BGP enabled but the connections do not have BGP enabled, however, the complete 10.x.x.x address space of your VPN Gateway VNET is being advertised. And you would like to know the reason behind this and if there is a way to prevent this from happening.

By design, the Azure VPN gateways advertise the following routes to your on-premises devices and you cannot exclude the Vnet address range:

Your virtual network address prefixes.

Address prefixes for each local network gateway connected to the Azure VPN gateway.

Routes learned from other BGP peering sessions connected to the Azure VPN gateway, except for the default route or routes that overlap with any virtual network prefix (if BGP is enabled on the connections).

Refer : https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-vpn-faq#what-address-prefixes-will-azure-vpn-gateways-advertise-to-me

If you are facing an address overlap issue, you can opt for NAT on your Azure VPN Gateway to connect multiple networks with overlapping IP addresses.
Please refer : https://learn.microsoft.com/en-us/azure/vpn-gateway/nat-overview
https://learn.microsoft.com/en-us/azure/vpn-gateway/nat-howto

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

----------------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.
Please sign in to rate this answer.
Von Jackson 1 Reputation point

2022-05-06T19:15:24.623+00:00

Thanks for your reply and detailed explanation. All that makes sense and we're already NAT'ing addresses on the VPN gateway once the conneciton is established. The problem is that the customers are seeing the address space of the VPN gateway (10.x.x.x) being advertised with the intial IKE proposal, but the NAT rule on the gateway can only be associated to the connection AFTER it's established and connected.

NAT rules cannot be associated with connection resources during the create connection process. Create the connection resource first, then associate the NAT rules in the Connection Configuration page.

So, again the customer is seeing the 10.x.x.x network before we even get to applying to NAT rule on the VPN gateway. Any way to prevent that?

Thanks

risolis 8,701 Reputation points

2022-05-06T19:46:55.88+00:00

Hi @Von Jackson

I just wanted to add a small comment.... You are mentioning that BGP is enabled on your VPN GW but none of your S2S are not running it. Can I get more details on the configuration if possible?

Have you checked this option configuration "BGP Route Translation"?

BR,

GitaraniSharma-MSFT 47,006 Reputation points Microsoft Employee

2022-05-17T11:59:25.007+00:00

Hello @Von Jackson ,

Apologies for the delay in my response.

Could you please provide the requested details by @risolis .
You mentioned that BGP is enabled on your VPN gateway but none of your S2S are not running it. Why is this?

Also you mentioned that "customers are seeing the address space of the VPN gateway (10.x.x.x) being advertised with the intial IKE proposal", could you please clarify this statement? Where exactly do you see the address space of the Vnet? is it in the traffic selectors?

Per design, The policy or traffic selectors for route-based VPNs are configured as any-to-any (or wild cards).
Refer : https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-vpn-faq#what-is-a-route-based-dynamic-routing-gateway

On the Azure side, with default settings the VPN gateway always configures a traffic selector of 0.0.0.0/0 e.g. it will never restrict the address ranges. If your on-prem device restricts the subnet range by using a narrow traffic selector, the effective Traffic Selectors will be the combination of Traffic Selectors on both sides.
If you use the UsePolicyBasedTrafficSelectors feature, the traffic selectors used by the VPN gateway will be virtualnetwork_addressrange <-> localnetwork_addressrange. Again, if your on-prem device restricts them, the effective Traffic Selectors will be the combination of Traffic Selectors on both sides.

What is the traffic selector configured on your on-prem device? Also, could you please confirm if you are using UsePolicyBasedTrafficSelectors feature?

Regards,
Gita

Von Jackson 1 Reputation point

2022-05-19T20:07:47.913+00:00

Sorry, I posted my original reply as an answer as opposed to comment. Screenshot and posted here

GitaraniSharma-MSFT 47,006 Reputation points Microsoft Employee

2022-05-20T13:36:25.713+00:00

Hello @Von Jackson ,

Thank you for the update.
Could you also provide the below requested details?

You mentioned that "customers are seeing the address space of the VPN gateway (10.x.x.x) being advertised with the initial IKE proposal", could you please clarify this statement? Where exactly do you see the address space of the Vnet? Is it in the traffic selectors?

What is the traffic selector configured on such customer's on-prem device? Also, could you please confirm if you are using UsePolicyBasedTrafficSelectors on your connections?
Refer : https://learn.microsoft.com/en-us/azure/vpn-gateway/ipsec-ike-policy-howto#supported-cryptographic-algorithms--key-strengths

Regards,
Gita

Von Jackson 1 Reputation point

2022-05-20T14:43:31.05+00:00

So, maybe that statement "being advertised with the initial IKE proposal" was misleading. The customers are seeing the address space of the gateway VNET in the traffic selector. We're not using PolicyBasedTrafficSelectors. We have over 25 connections with customers and almost all of them report the same thing. As you can imagine, it's hard to know what each customer has configured on their side for the traffic selectors. I know this is hard to diagnose by blind troubleshooting 'so to speak'. I just want to how/why the VNET address space of the gateway is being advertised when we're not providing it to the customer?

risolis 8,701 Reputation points

2022-05-22T08:41:49.143+00:00

Hello @Von Jackson

Thanks for your answer as well as @GitaraniSharma-MSFT .

I wonder if you have configured or stated on your NAT rules the GW Vnet space....

BR,

risolis 8,701 Reputation points

2022-05-22T08:56:21.373+00:00

BR,

Accept Answer and Upvote, if any of the above helped, this thread can help others in the community looking for remediation for similar issues.

GitaraniSharma-MSFT 47,006 Reputation points Microsoft Employee

2022-05-24T13:04:41.36+00:00

Hello @Von Jackson ,

Thank you for the update.

Could you please share the NAT rules configured on one connection where you see this issue?
Are you using an EgressSNAT rule to map the Azure VNet address space to another translated address space?
NOTE : The VNet routes advertised to connections without EgressSNAT rules will not be converted.

Regards,
Gita

Von Jackson 1 Reputation point

2022-05-24T19:12:56.643+00:00

Well, that's why I mentioned that I probably mislead with the NAT rule statement. This is occurring before I even apply the NAT rule. I never apply any NAT rules until the connection is completely established. Also, the gateway VNET address is not configured on any of the NAT rules. I think it's just certain Cisco devices that see the address space come across because I just established a S2S connection with another customer and they didn't mention the gateway VNET address space being advertised :) Very strange. I'll ask to confirm though.

risolis 8,701 Reputation points

2022-05-25T04:50:33.017+00:00

Thanks for the details provided above.

Cheers!

Accept Answer and Upvote, if any of the above helped, this thread can help others in the community looking for remediation for similar issues.

GitaraniSharma-MSFT 47,006 Reputation points Microsoft Employee

2022-05-25T15:12:02.747+00:00

Hello @Von Jackson ,

I agree that this issue is getting complicated with so much detail.
Let us start over.

If I have to paraphrase the issue, I would say : You have S2S connection established between your Azure VPN gateway and many customers and they are seeing the VPN gateway's VNET address space advertised to them in their initial IKE traffic selectors even before you add any NAT rules to the connection. Please correct me if I missed something.

Now, you mentioned that you observed this issue with certain Cisco devices.
So, I will come back to my previous comment posted 8 days ago now :
"If you use the UsePolicyBasedTrafficSelectors feature, the traffic selectors used by the VPN gateway will be virtualnetwork_addressrange <-> localnetwork_addressrange. Again, if your on-prem device restricts them, the effective Traffic Selectors will be the combination of Traffic Selectors on both sides."

If the customers seeing this issue are using Cisco ASA, then it is by design.
Refer : https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices
Cisco ASA versions 8.4+ add IKEv2 support, can connect to Azure VPN gateway using custom IPsec/IKE policy with "UsePolicyBasedTrafficSelectors" option.
Refer: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps

Please check this and provide an update on same.

Regards,
Gita

GitaraniSharma-MSFT 47,006 Reputation points Microsoft Employee

2022-06-09T09:42:24.817+00:00

Hello @Von Jackson , I'm following up on this thread to check if you have any new updates on this issue?
Sign in to comment