VPN Gateway drops tunnels when NAT rules feature enabled

Question

Hi All,

I am very new to Azure (but have 20+ years experience in networking) so apologies of this is something simple im missing here.

I have successfully configured a site-to-site VPN tunnel between an on-prem Meraki MX firewall and a VPN Gateway configured in Azure. The tunnel comes up and all looks ok. So no problems there.

The issue im having is that when i apply any NAT rules to the Azure VPN Gateway, the tunnel immediately drops and refuses to come back up again until i remove the NAT rules. I have checked that the addressing at the AZURE side, and the On-Prem side is as it should be and that this is reflected in the traffic rules in both AZURE and on the Meraki side and as far as i can see, all should be well. I just cant get the tunnel to come back up with NAT rules applied.

Can anyone shed some light on this or have seen this before ?

Cheers all
Shaun

Answer 1

Further to the above, Just ran a VPN diag and it came back with this..

'The connection is not available in the VPN gateway because of configuration conflicts'

Where can i see exactly what conflicts its referring to ?

Cheers
Shaun

Answer 2

Hi @shaun Phillips
Can you provide more information? post screenshots from the error and nat configuration

There are no overlaps in the network? from on-premise to Azure

Best

Answer 3

Hi martins-jackson

Thanks for the reply.

these are the screenshots i took from the VPN diags tool. First the VPN Gateway itself.

And the connection attached to it...

the real address path is basically ....on prem inside range of 10.10.255.8/30... talking to the end point on 10.3.0.4/24 in VNET 'B'. The VPN Gateway itself sits in VNET 'A' on 10.2.1.0/24 in front of VNET 'B'. VNETS 'A' & 'B' are configured with a VNET peering where VNET 'B' is configured to use the VPN Gateway in VNET 'A' .

Without NAT applied the above works perfectly. All of this is configured in a lab environment so the IP addresses are not live.

I need to get this working with NAT as the real world application I have in mind will need to support overlapping address space at multiple on-prem sites. So I configured the following NAT rules

Ideally, its the top two dynamic rules i need so that i can overload the pre NAT source address of 10.10.255.8/30 toward the 10.3.0.4 endpoint so it looks like 192.168.254.1/32, and also egress NAT 10.3.0.4 so it looks like 1.1.1.1/32 toward the on prem sites. (the on-prem sites will have no relationship with each other and 1.1.1.1 in the lab just represents 'Some Public IP Address' which will not appear on the on-prem sites.)

I tried it with the top two NATS applied and the tunnel dropped and would not come back up. Then i tried it with the static NAT types you see in the bottom two rows. Same result. The tunnel immediately drops and will not come back up unless i remove the NAT associations with the connection.

I know the VPN Gateway can do what im trying to get it to do as i have seen it working like this (at least with the static NAT types i should say). But as im new to Azure Im struggling to workout where im going wrong here. Im also not sure what other info may be useful to you so please let me know if you need anything else.

Hope this explains things a little better and thanks again for the help.

Cheers

Answer 4

Hi all. I've had exactly the same issue and raised this with MS support. It turns out that traffic selectors are not supported on the remote end of the gateway. The documentation states that traffic selectors are not available on the Azure VPN Gateway (we have them disabled) but in our on-premises VPN gateway (pfsense used for testing), the remote network was set to the outside NAT network.

We were told to set this to 0.0.0.0/0 which is another of disabling the traffic selector on the on-premises side. However, the pfsense seemed to interpret this as the LAN network. It might be that we need to configure it in routed mode but yet to test.

Perhaps try to disable any traffic selectors on your on-premises end. Any incorrect configuration also causes the tunnel to be torn down but the gateway doesn't highlight what the problem is- very frustrating.

Here is some additional info about the ingress and egress:

Each NAT rule defines an address mapping or translating relationship for the corresponding network address space:

1. Ingress: An IngressSNAT rule maps an on-premises network address space to a translated address space to avoid address overlap.

• An example of this would be Azure has a Vnet of 10.0.0.0/16 with a VM IP of 10.0.1.5. the AzureVM needs to connect to an on-premises server with 10.0.1.5 but cannot because that address overlaps with what Azure has for its address range. So, we create a IngressSNAT rule on the virtual network gateway when translates 192.168.1.5/32 to 10.0.1.5/32. So, the AzureVM connects to 192.168.1.5 which gets translated at the VNG (Virtual Network Gateway) from 192.168.1.5
• Egress: An EgressSNAT rule maps the Azure VNet address space to another translated address space.
• An example of this would be Azure has a Vnet of 10.0.0.0/16 with a VM IP of 10.0.1.5. the OnpremServer1 with the IP 192.168.0.5 needs to connect to AzureVM1 (10.0.1.5). But the CX already has 10.0.0.0/16 in use elsewhere and wants to use 172.28.1.5/32 to connect to the AzureVM1. So, we create a EgressSNAT rule on the virtual network gateway when translates 10.0.1.5/32 to 172.28.1.5/32. So when servers that are on-premises such as OnpremServer1 they use the IP address of 172.28.1.5 it will get translated at the VNG from 172.28.1.5 to 10.0.1.5. When the traffic returns to on-premises, they will see as the sender address 172.28.1.5.

For each NAT rule, the mapping fields specify the address spaces before and after the translation: Internal mapping for IP range that will be translated for example 10.0.1.5. External mapped is the result 172.28.1.5

Answer 5

It depends on the on premises firewall type. You essentially don't want to specify the LAN IP addresses spaces in your config, eg leave them blank.