Azure P2S VPN Static IP: Why the Client Address Changes

Every Azure point-to-site client receives an address from the pool when it authenticates, and keeps it only for the life of that connection. There is no reservation table, no per-user mapping, and no gateway setting that means "always give this person 172.16.0.10". That single mechanism explains both symptoms people run into later: an NSG rule that stops matching a user it used to match, and an allowlist that quietly admits a machine nobody added on purpose. Replacing the rule with a cleverer IP rule fixes neither, because the thing the rule names is reassigned on a schedule you do not control.

The pool is capacity, not identity. It exists so that concurrent tunnels get unique addresses, and it recycles them the moment a lease ends. Once that is clear, the useful question stops being "how do I pin this client" and becomes "what can I write a rule against that the gateway will not recycle".

What the gateway actually does when a client connects

The gateway keeps the configured client address pool and treats it as a lease table. On connect it takes the next free address, in practice the lowest one available, and assigns it to the tunnel adapter until the client disconnects or the lease expires. Order decides, not identity: whoever reconnects first after a quiet period takes the lowest address that happens to be free at that moment.

Pool size hides the behavior. A lab pool one or two addresses larger than the number of testers looks deterministic, because the same laptop tends to reconnect in the same order each morning. Add a third machine, resize the pool, or leave a session connected over lunch, and the pattern breaks. The address was never stable; the queue was.

Any change to the point-to-site configuration also resets the lease space. A different authentication type, a resized pool, a new pool range, or a gateway that is torn down and rebuilt all send clients back into a pool that no longer maps to their old addresses. Nothing about that change touches your NSG, which is why the breakage looks spontaneous.

You can watch it happen in about a minute. Connect, note the tunnel address in the client's connection details, disconnect, connect a second machine, then reconnect the first. The address you get back depends on what the second machine is holding, and no portal setting will restore the earlier one on demand.

An NSG keyed on the client IP is really a rule on connection order

The rule people write first is the obvious one: an inbound rule on the management VM's NIC or on its subnet, with the VPN client's internal address as the source. It is short, it passes the test on the day it is written, and it fails as soon as the pool has more than one free address.

Two failure modes follow, and only one of them looks like a bug. A legitimate user is denied because someone else currently holds the address the rule names, which arrives as an annoying support ticket. Or an unintended user is allowed because they inherited an address the rule still trusts, which arrives as nothing at all until someone audits access.

Because the rule follows the lease, the effective policy reads "the first person to connect gets management access". That is a description of connection order dressed up as intent, and no amount of rule hygiene makes it express intent.

The client lease and the gateway address are different objects

Most of the confusion comes from one word. The gateway has a public IP that is comparatively stable; clients have private addresses from the pool that are not. For a non-zone-redundant VPN gateway the public IP is dynamically allocated, but it survives a resize, a reset, and routine maintenance — it changes when the gateway itself is deleted and recreated. Zone-redundant and zonal gateway SKUs use a Standard SKU public IP, and that allocation has to be static.

That stability is what an on-premises peer needs in its configuration, and it says nothing about identifying an individual client. When a partner asks which address they will see, the answer is the gateway's public IP under site-to-site, or a shared NAT range — never a laptop's tunnel lease.

Group pools give you a range worth writing rules against

Virtual WAN point-to-site supports user groups, and each group can be assigned its own client address pool. Membership is decided by identity, so the range a client lands in becomes predictable: operations in one range, contractors in another, and the range is something a firewall or NSG rule can name without guessing.

The resulting rule set has a shape you can review:

• one pool per audience, sized for peak concurrent sessions rather than headcount;
• group membership handled through identity, not by editing rules whenever someone joins;
• NSG or Azure Firewall rules written against pool ranges, never against individual leases;
• a separate hub or gateway for audiences that must never share a range.

Allowlisting an entire pool is honest but coarse: every connected client in that range gets the same access. That is a policy decision worth stating out loud instead of discovering during a review. Anything that still needs a per-person answer belongs at the resource, through role assignments, not at the packet filter.

When the deployment cannot move to Virtual WAN

Plenty of gateways stay as plain VPN gateways, and moving to Virtual WAN is not a casual change. The practical answer is to move the per-user decision off the packet filter and onto something that already knows who the user is.

Resource-level identity is the cheapest version. Storage, SQL, and Key Vault all support Entra ID authentication with per-user or per-group role assignments, so the VPN only has to prove network reachability. A jump host with named accounts does the same job for administrative work, because the host records the human and the tunnel just carries packets. Registering clients in DNS and allowlisting the name rather than the number moves the rule up a layer. Application-layer identity — a certificate subject, a token claim, a group membership — works when the application, not the network, is the thing asked to decide.

For a partner who insists on a fixed source address, the answer is site-to-site or ExpressRoute with a defined peer prefix. They allowlist the peer prefix, the address that appears on their side belongs to the gateway, and it does not change when somebody reboots a laptop.

Check the pool before you edit another allowlist

Two pool properties cause most of the behavior people blame on the client. A pool that is too small recycles leases quickly, so addresses appear to move constantly and any address-based rule looks flaky by design. A pool that overlaps the on-premises ranges or the virtual network space creates routing ambiguity that no firewall rule repairs.

Put three things on one page before touching a rule: the point-to-site pool, the virtual network address space, and the on-premises ranges. They must not overlap, and the pool needs room for every simultaneous client plus a margin for reconnects.

Then close the loop in this order:

• Connect from two machines in both orders and compare the addresses; if they can swap, no address-based rule is safe.
• Check whether the gateway is Virtual WAN; if it is, use group pools instead of per-address rules.
• Ask what happens when a rule matches the wrong person; if the answer is an access incident, move the control to identity.
• Record which range belongs to which group in the same repository as the NSG definitions.
• Re-test after any pool, authentication, or gateway change, because those changes rewrite the mapping without announcing it.