How do I get NAT working across Azure VPN?

PW 15

I’ve set up a test environment and connected to Azure with my home computer using a pFsense router. I can get NAT over Azure VPN working in one direction from my home side; however, as soon as I set NAT up for the address in Azure, the connection fails. IKE Phase 1 connects fine. During IKE Phase 2, the log says that it’s matching all the NAT IPs, child_sa changes state to Installed, but then immediately destroys the connection. I've checked and double checked the requirements and limitations for Azure NAT over VPN and couldn't find anything amiss. Again the VPN connection works both without NAT and with NAT on the Pfsense side, but not with NAT set up on Azure side. Below are my Azure NAT settings:

azurenat

and the pfsense log:

pfsense logs

KapilAnanth-MSFT 34,926 Reputation points Microsoft Employee

2023-01-20T09:07:04.3233333+00:00
@PW

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

I understand that you are facing issues configuring Azure VPN NAT.

Can you please share more details on this?

Are you meaning to say Ingrees NAT works and Egress NAT does not work?

You have mentioned that the connection immediately gets destroyed after creating, can you specify if the connection is being torn by Azure end or OnPrem end?

Also, the images you have shared are not visible. Can you please share them once again.

Cheers,

Kapil
KapilAnanth-MSFT 34,926 Reputation points Microsoft Employee

2023-01-23T06:06:17.45+00:00
@PW

From your latest comment, I see you have an configuration of

Ingress static, internal: 10.0.0.0/24, external: 100.100.0.0/24

Egress static, internal: 10.4.0.0/16, external: 100.64.0.0/16

And your OnPrem address range is 10.0.0.0/24

May I know if the setup is working only with the Egress static rule?

i.e,

Azure becomes 100.64.0.0/16

And your Onprem address range becomes110.0.0.0/24

Make sure the address space in LNG is configured to be 110.0.0.0/24

Cheers,

Kapil
PW 15 Reputation points

2023-01-23T21:20:22.0966667+00:00

Azure NAT VPN.txt

Attached is a single text file that I pasted both PFSense IPSEC logs in, one working, one not. It's the complete log of an image posted earlier.
The setup doesn't work with either Egress rule only, Ingress rule only, or both rules applied.

The setup does work if only the on-prem PFsense router is doing NAT on it's side. For instance, I'm able to ping 110.0.0.1 (on-prem NAT address) from a server in Azure that is on 10.4.0.0/16 network.

If there's no NAT translating on either side, the tunnel works and both devices on either side can ping each other.

If I turn NAT off in Azure, but leave the Remote Network on the Pfsense as 100.64.0.0, the tunnel connects and stays connected. Obviously, I just don't have access to the 10.4.0.0 network since the address is still set as the NAT.

Azure config:

Virtual Network: 10.4.0.0/16

IngressNAT: int 10.0.0.0/24 -> ext 110.0.0.0/24

EgressNAT: int 10.4.0.0/16 -> ext 100.64.0.0/16

LNG: 110.0.0.0/24

PFSense config:

Firewall rules are open.
KapilAnanth-MSFT 34,926 Reputation points Microsoft Employee

2023-01-25T05:05:55.5566667+00:00

@PW

To further troubleshoot the issue, we will need a specialized 1:1 session, where a support engineer can have a screen share session to pinpoint the issue. If you have a support plan you may file a support ticket.

In case you require one-time free support, please send an email with subject line “Attn:kaananth | How do I get NAT working across Azure VPN?” to AzCommunity[at]Microsoft[dot]com

with the following details, I will follow-up with you.

• Reference this Q&A thread URL

• Azure Subscription ID

• Azure resource ID

Note: Please do not share any PII data as a public comment.

We will post a summarized answer once the issue is resolved.

Cheers,

Kapil

1 answer

Silvia Wibowo 2,851 Reputation points Microsoft Employee

2023-01-19T23:56:33.2766667+00:00

Hi PW, please use IP address in the range of RFC 1918 or RFC 6598 for your NAT target.

Reference: IP Addresses in VNet.

Please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is how.
Please sign in to rate this answer.
PW 15 Reputation points

2023-01-20T02:31:43.7566667+00:00

Unfortunately, I changed it to 100.64.0.0/16, but with the same result. The log is the same as my original post with the exception of the different NAT address.

Silvia Wibowo 2,851 Reputation points Microsoft Employee

2023-01-20T05:50:59.12+00:00

Hi PW, what is the SKU of your Azure VPN Gateway?

NAT is supported on the following SKUs: VpnGw2~5, VpnGw2AZ~5AZ.

Do you use BGP or static routing?

If your SKU is correct, please confirm the IP CIDR and NAT rule, is this accurate:

home 10.0.0.0/24 -> PFsense router -> internet -> Azure VPN Gateway -> Azure vNet 10.4.0.0/16

NAT Rule on Azure VPN Gateway:

Ingress static, internal: 10.0.0.0/24, external: 100.100.0.0/24

Egress static, internal: 10.4.0.0/16, external: 100.64.0.0/16

NAT Rule on PFsense: ?

PW 15 Reputation points

2023-01-20T19:38:05.2233333+00:00

SKU is VpnGw2. We do not use BGP or static routing. What you have is correct. The NAT rule for the PFsense is as follows:

When NAT is turned off on the Azure side, the VPN connection works and I'm able to ping a 110.0.0.x address from a server in Azure on the 10.4.0.0/16 network.

Edit: I turned off the Azure NAT and the tunnel connected immediately even with the wrong Remote Network on the PFsense side. Granted, I didn't have access to the Azure network because of the wrong Remote Network, but I thought it was worth mentioning in case it was any help in troubleshooting.

Brian Davis 41 Reputation points

2023-02-14T23:06:45.1466667+00:00

Greetings @PW. Did you ever get a resolution on this issue? I'm having a very similar one and was curious if you were able to solve this yet.

Brian Davis 41 Reputation points

2023-02-14T23:10:54.4366667+00:00

Greetings. Just curious if there was any resolution on this? I'm having a very similar issue. Thanks.

Silvia Wibowo 2,851 Reputation points Microsoft Employee

2023-02-15T01:10:46.02+00:00

Hi @Brian Davis , have you reviewed NAT limitations?

Could you please detail out your settings:

home CIDR? -> on-prem router -> internet -> Azure VPN Gateway -> Azure vNet CIDR?

NAT Rule on Azure VPN Gateway:

Ingress/Egress static/dynamic, internal: CIDR?, external: CIDR?

Brian Davis 41 Reputation points

2023-02-15T18:29:01.7266667+00:00

@Silvia Wibowo Thanks for the reply. I'm trying to use the scenario listed here as a guide: https://learn.microsoft.com/en-us/azure/virtual-wan/nat-rules-vpn-gateway#ingress-snat-vpn-site-with-statically-configured-routes. Essentially I have overlapping network ranges at 2 on-prem locations just like this example, only different address schemes.

I have reviewed the NAT limitations (thanks for the link BTW) and I don't think they apply to my scenario. I'm using a Virtual Network Gateway of SKU VpnGw2AZ. It's route-based and I'm trying to establish a site-to-site IPsec-based tunnel from Azure to an on-prem device. I'm not using BGP and I'm not using policy-based traffic selectors. My network sizes are /24. I'm using a combination of the Azure Virtual Network Gateway and the Azure Local Network Gateway to represent on-prem devices. Here's what I'm seeing. If I create a local network gateway object that represents the on-prem network and then create the connection in the Virtual Network Gateway, I can see the tunnel come up. I create my IngressSNAT rule and try to apply it to the connection. The tunnel goes down and I can see from the TunnelDiagnosticLog in Log Analytics that the stateChangeReason_s has an entry for AlwaysWildcardTrafficSelectors changed. If I disassociate the rule, the tunnel will come back up. I don't understand why adding the rule would cause the connection to drop. This seems very similar to the above post and one other I've seen. Is there a resolution? This seems like it would be the most basic of scenarios so I'm confused as to why this doesn't work unless NAT functionality isn't used very much at all. My alternative is to use a virtual appliance that I know will work if I'm not able to get this resolved with the native Azure offering. Any feedback would be greatly appreciated. Thanks.

Brian Davis 41 Reputation points

2023-02-15T23:51:33.1833333+00:00

@Silvia Wibowo Thanks for your reply. Apologies, if I post this twice as already replied but it doesn’t show up.

I’m using this article as a guide: https://learn.microsoft.com/en-us/azure/virtual-wan/nat-rules-vpn-gateway

It’s very much the same as my scenario with different addresses. I’m trying to implement an IngressSNAT rule on one connection due to overlapping ip schemes at on prem offices. I’m using an Azure Virtual Network Gateway in combination with Local Network Gateway objects that represent the on prem locations. I have reviewed the NAT limitations and I honestly don’t think they apply in my situation. The virtual network gateway is route-based and I’m not using policy-based custom selectors. Also my IP schemes are /24, etc.

I can configure a local address object and a virtual network object and the tunnel will come up. However, when I try to link the IngressSNAT rule, the connection will drop. In Log Analytics, I can see the tunnel has disconnected with a reason similar to “any to any wildcard selector changed”. I don’t understand why assigning a NAT rule would cause the tunnel to drop. Any help would be greatly appreciated.

Brian

Silvia Wibowo 2,851 Reputation points Microsoft Employee

2023-02-16T21:23:44.7366667+00:00

Hi @Brian Davis , although definition and configuration may be the same or similar, the documentation link you provided is for VPN Gateway NAT on Virtual WAN.

Once you configure Ingress SNAT, your on-prem address range will change. If you're not using BGP routing, you need to adjust IP address range for your Local Network Gateway configuration to the external.

This lab may explain it better: https://github.com/dmauser/azure-vpn-s2s-nat

Brian Davis 41 Reputation points

2023-02-17T18:45:58.6933333+00:00

@Silvia Wibowo Thanks for the clarification. I'm trying this again on a new connection. I'm following the official article referenced from the lab you shared: https://learn.microsoft.com/en-us/azure/vpn-gateway/nat-howto. However in both the lab and this article, the Azure end is being NAT'ed. That is not needed in my case. I assume that it's not a requirement to NAT the Azure end, correct? Also, one difference the lab has is the creation of a local network gateway for the Azure end. This isn't mentioned in the official article and I assume it's not required as well? It would seem that only the on-prem environments would need local network gateway objects correct?

Thanks.

Brian Davis 41 Reputation points

2023-02-20T21:24:51.4833333+00:00

@Silvia Wibowo Unfortunately, I can confirm after another attempt that the tunnel comes up when I disassociate the NAT Ingress rule. When I associate the NAT Ingress rule, the tunnel changes to a "Disconnected" state with the stateChangeReason_s as AlwaysWildcardTrafficSelectors changed. Again, I don't understand why associating a NAT rule would cause the tunnel to go down. Also, I have confirmed this behavior doesn't occur when associating an Egress NAT rule. Any thoughts as to what's going on here? Thanks.

Silvia Wibowo 2,851 Reputation points Microsoft Employee

2023-03-05T22:27:58.6466667+00:00

Hi @Brian Davis , it seems that Azure VPN Gateway and your on-premises VPN device couldn't agree on IKEv2 Traffic Selectors. Traffic selectors are used during the CHILD_SA (tunnel creation) Phase 2 to set up the tunnel and to determine what traffic is allowed through the tunnel. The two IKE gateway peers must negotiate and agree on their traffic selectors; otherwise, one side narrows its address range to reach agreement. The policy or traffic selectors for route-based VPNs are configured as any-to-any (or wild cards).

One last configuration to try: setting Azure VPN Gateway as "InitiatorOnly" or "ResponderOnly" instead of "Default". If this doesn't work, I'm out of ideas.

Brian Davis 41 Reputation points

2023-03-08T15:51:55.12+00:00

Thanks @Silvia Wibowo I'll look into the behavior with that setting more closely.
Sign in to comment