I want to create a VPN instance where: 1) Clients can connect over a public IP. 2) All outgoing connections happen over a NAT gateway. To illustrate: We want to do this because our NAT gateway IP addresses are whitelisted by vendors.

Question

We have an Azure VPN Gateway that we need to have the outgoing IP be a single IP that never changes, so that it can be whitelisted on our clients side.

Answer 1

Hello，

Your goal is to allow VPN clients to connect via a public IP while ensuring that any traffic leaving Azure to your vendor systems always appears to come from one fixed (whitelisted) public IP. In other words, you want to “ingress” via a VPN gateway and “egress” via a NAT device. There are a common patterns to achieve this in Azure:

Using a VPN Gateway with NAT on the Back End

1. Create a Virtual Network with at least two subnets:

  • The Gateway Subnet – for the VPN Gateway.

  • A “Hub” or “Backend” Subnet – where your resources (or a forwarding appliance) reside.

2. Deploy an Azure VPN Gateway in the Gateway Subnet. This gateway will have a dedicated public IP that your VPN clients will use to connect (your “ingress” point).
3. Route the VPN traffic (or traffic coming from the VPN Gateway) into the backend subnet. This might be a corporate app or even an NVA (Network Virtual Appliance) that then makes outbound calls. (Often a hub–spoke model is used.)
4. In the backend subnet, attach an Azure NAT Gateway resource. The NAT Gateway is configured with a static public IP (or a pool that in your case contains a single IP). When your resources or appliance initiate an outbound connection, Azure will use the NAT Gateway—ensuring that all external connections use your whitelisted IP.
5. Ensure that your routing is set up so that outbound internet traffic from your backend subnet is forced through the NAT Gateway (this is automatic once you attach the NAT Gateway resource to that subnet).

Steps in More Detail (Example )

1. Create your Virtual Network:

  • Define your Gateway Subnet (using the subnet name “GatewaySubnet”).

  • Create another subnet (e.g., “AppSubnet”) where your apps, services, or appliances are deployed.

2. Deploy the VPN Gateway:

  • Choose the appropriate SKU (Route-based is typical).

  • Allocate a Public IP address for this gateway.

3. Configure Point-to-Site (or Site-to-Site) VPN as needed so that clients can connect.
4. Deploy a NAT Gateway resource:

  • Reserve a static Public IP Address Resource.

  • Create the NAT Gateway and associate it with the “AppSubnet.”

  • By associating, any outbound connection from resources in that subnet will be translated to use the NAT Gateway’s Public IP address.

5. Set up routing:

  • If necessary, use User-Defined Routes (UDRs) on the “AppSubnet” to ensure all internet-bound traffic is forced through the NAT Gateway.

  • (Note: When you simply attach a NAT Gateway to a subnet, this outbound translation is automatically applied, but make sure that no conflicting routes override this behavior.)

6. Verify the connectivity:

  • From a VPN-connected client, test connectivity to an external resource that can return your public IP (for example, a “What is my IP” service). The reported IP should match your NAT Gateway’s public IP.

---

If the Answer is helpful, please click "Accept Answer" and upvote it.