New Hotspot Client Stuck on Obtaining IP Is Not a VPN Fault

A phone joins the hotspot, sits at "Obtaining IP address", and eventually gives up. The natural conclusion is that the phone's VPN is interfering with DNS, so people start editing resolvers and appended rules. That is the wrong stage. The client never received a local address, and without one it has no gateway, no resolver and nothing to forward, so no VPN setting on the host phone can explain the failure. Association, local address assignment and onward forwarding are three separate stages, and only the last one involves the tunnel.

The three stages, and which one you are in

Association comes first: the client joins the hotspot's wireless network. A wrong password, a WPA3 mismatch or a radio compatibility problem fails here, and the client usually says so. Address assignment comes second: for IPv4 the client asks for a lease and receives an address plus local gateway settings, while IPv6 normally uses router advertisements instead of DHCP, as the AOSP tethering documentation describes. Onward access comes third: the host phone forwards permitted traffic to whichever upstream path it selected, which may or may not be its tunnel.

The wording on the client tells you the stage. Stuck at obtaining an address is stage two, before any packet leaves for the internet. Connected, with an address, but nothing loads is stage three, where routing, names and tunnel coverage all matter. Diagnosing stage three while the client is stuck in stage two is how a five-minute lease problem becomes an afternoon of DNS edits.

The myth: a routed VPN turns local DHCP into a remote request

A routed tunnel moves IP packets for the destinations it selects. A DHCP discover is a broadcast on the hotspot's own segment, and the tethering service on the phone answers it locally, which is why the client can get an address while the tunnel is up. Only a deliberately bridged or relayed design sends that exchange somewhere else, and that is a different arrangement with a different failure signature.

So "the VPN server is not answering DHCP" is not a diagnosis, it is a model error. The local broker is on the phone. If it stops answering, the reasons are local: the tethering service, the client limit, the lease pool, or a client that never completed association properly. None of those live on the remote side of the tunnel.

What an existing client working actually proves

If a laptop that was already connected still works while the new phone does not, the hotspot and the upstream path are broadly alive. That comparison is useful and it is not proof of which component is at fault, because the working client may simply be holding a lease from before the change and renewing it quietly.

Two local limits are worth checking while you are there. The hotspot serves a finite lease pool and a configurable client limit, so a device that joined and slept can hold an address while a new one waits. And a client that remembers a static configuration from another network will not ask for a lease at all, which looks identical from the outside and is fixed at the client, not on the phone.

Keep the comparison local and reversible

On a device where policy allows it, compare one new-client join with the tunnel inactive and then active, keeping the hotspot and the client otherwise unchanged. Record the phone and client versions, the selected profile and the exact stage that failed. On a managed phone, request the approved comparison instead of disabling enforcement to get a cleaner test.

A consistent tunnel-dependent lease failure is useful evidence about local policy or an implementation interaction. It is not a licence to flush every forwarding and NAT rule on the device. Those rules protect unrelated traffic, and a broad forwarding accept does not explain why a local DHCP service stopped answering.

Do not paper over a missing lease with a guessed static address either. A deliberate static configuration needs the real subnet, the gateway, the allocation plan and a collision check. Changing the client's DNS supplies none of those, and it leaves the next device with the same failure.

What a lease does not prove

Getting an address proves admission to the local network, not protection by the phone's tunnel. Once the client holds a lease, evaluate the downstream path on its own: does the client's traffic actually route through the phone, do lookups resolve where you expect, and does the outside address match the exit you intended? Those are stage-three questions and they deserve their own test rather than being folded into the join.

Work the stages in order and the failure stops moving. A client stuck at obtaining an address is a local tethering question; a client with an address and no pages is a forwarding or naming question; a client with pages and the wrong exit is a tunnel coverage question. Keeping them apart is most of the debugging.