Two Public IPs on One Azure VPN VM: Which One Does What

Two public IPs on one Azure VPN VM create an expectation that rarely holds: the address clients connect to will also be the address websites see. Three independent decisions produce that outcome, and only the first one is about the tunnel listener. The second is the guest source used for forwarded client traffic, and the third is the Azure outbound method that applies to that source. Change one and the other two stay where they were, so decide each explicitly.

Decision 1: where the tunnel terminates

An Azure public IP is associated with a private IP configuration on the NIC; it is not an address you add inside the guest operating system. Read the mapping instead of assuming it: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Whatever private address that query returns is the one the guest must actually hold.

One NIC can carry several IP configurations, so two public addresses do not require two NICs. If the design does use two NICs, each one brings its own guest routes and next hops, and you have added a routing decision rather than simplified one.

For a service with an explicit local bind, bind to the real guest-private address, never to the public placeholder. A wildcard listener accepts traffic through every IP configuration that reaches it, so constrain entry with the network security group and host firewall rather than hoping the bind order decides.

Decision 2: what source the forwarded client uses

After the gateway decrypts a client request, the packet it forwards is a different packet from the one that arrived at the VPN listener. The guest needs forwarding enabled, a firewall policy that permits the flow, and a source address the cloud design allows. If you translate the inner client address, that translated source is the one Azure will evaluate, not the client inner address.

A narrow SNAT rule can pick a guest-private source, but it cannot overrule a downstream Azure translation. Choose SNAT when you need per-client accountability inside the VM; skip it when the subnet's outbound design already provides a stable public source and a second translation would only add state.

Decision 3: which Azure outbound method wins

Microsoft documents an outbound precedence order: an applicable route to an appliance or gateway takes priority, and subnet NAT Gateway connectivity takes priority over an instance-level public IP on the relevant path. That ordering is why translating to 10.20.0.5 does not prove a website will observe 198.51.100.20. Read the effective route table, the NAT Gateway association and the NIC public IP together before you accept the egress design.

Keep the Azure NIC forwarding setting separate from Linux forwarding. The cloud flag permits packets whose source or destination is not assigned to the NIC; it does not enable net.ipv4.ip_forward, and the guest setting does not grant the cloud permission.

The tunnel socket has its own source decision

WireGuard's Address under wg-quick assigns an address to the WireGuard interface; it is not an outer UDP bind instruction. The encrypted socket source follows the routing table, so a policy route or a second default can move it without touching the interface address. OpenVPN's local option and UDP multihome behave the same way: they concern the listener and its replies, not the internet source of every forwarded client.

Preserve the underlay route that carries the tunnel, and confirm the client still receives authenticated replies from the expected entry arrangement. Do not rely on address-list ordering as a permanent source-selection policy, because the next address added to the NIC can change which one wins.

What to accept, and in what order

Accept three results separately. First, an external client reaches the intended VPN entry. Second, a fresh permitted request from that VPN client leaves through the documented internet exit. Third, unintended listener and forwarding paths stay denied. Record the public-to-private mappings and the guest and cloud owners of each decision in the same place.

A successful tunnel proves only the first part. Test the egress with a fresh flow, because a cached connection can keep using the old source long after the route changed.