When is NAT-T natting performed on Azure policy based basic VNet gateway, IKEv1 site-to-site connection

Question

I have a strange requirement for IKEv1 VPN to a Cisco ASA and Checkpoint system with Azure.

We setup two Azure policy based VNet gateways, virtual networks and associated virtual machines.

The connection has to be IKEv1 AES-256-SHA1-DHGroup2 site-to-site connection per their test and production environments so we setup one for test and production.

The third party system does not support RFC1918 addressing within VPN tunnels (encryption domain) and/or Peers. There must be publicly assigned IP addresses for the VPN tunnel, as well as a publicly routed IP address for the peer.

They recommend using subnets within the tunnel negotiations, and using your access-lists to narrow this down to specific hosts (subnet SA's vs. host SA's). In the event you need to “hide” multiple hosts behind a single IP address, you should PAT using a publicly assigned address to be included in the VPN tunnel. NAT-T (UDP Encapsulation of IPSEC) is not supported due to global configuration items which affect multiple customers.

My question is when is NAT-T performed when connecting to an Azure virtual network gateway in policy-based (IKEv1) mode on site-to-site (S2S) connections? Is it done at all or when is it performed? Is it only performed if there is a load balancer out front?

Answer 1

To clarify: Have you gone through this suggestion : Site-to-Site – VPN connection over IPsec (IKE v1 and IKE v2). This type of connection requires a VPN device or RRAS. For more information, see Site-to-Site: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-site-to-site-resource-manager-portal

Point-to-Site – VPN connection over SSTP (Secure Socket Tunneling Protocol). This connection does not require a VPN device. For more information, see Point-to-Site: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal

VNet-to-VNet – This type of connection is the same as a Site-to-Site configuration. VNet to VNet is a VPN connection over IPsec (IKE v1 and IKE v2). It does not require a VPN device. For more information, see VNet-to-VNet: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal

Multi-Site – This is a variation of a Site-to-Site configuration that allows you to connect multiple on-premises sites to a virtual network.

Only the traffic that has a destination IP that is contained in the virtual network Local Network IP address ranges that you specified will go through the virtual network gateway. Traffic has a destination IP located within the virtual network stays within the virtual network. Other traffic is sent through the load balancer to the public networks, or if forced tunneling is used, sent through the Azure VPN gateway

Answer 2

I think I tried to answer the same questions on the MSDN forum. Just re-iterate the answers:

1. NAT-T is performed on the outer packets/addresses of IPsec packets.
2. Azure VPN gateway does NOT perform any NAT/PAT functionality on the inner packets in/out of IPsec tunnels. So if you use public IP addresses inside of your on-premises network and your Azure virtual network they will stay the same to/from the Azure VPN gateways and IPsec tunnels.
3. You can use public IP address spaces as "private" IP addresses on your Azure VMs / Azure virtual network. These will be treated like "private" addresses by the Azure VPN gateways. We will not NAT those inner packets.

Hope this helps.

Thanks, Yushun [MSFT]