No internet on a Windows VPN? The address pool is the suspect

Windows shows the tunnel as connected and labels it No Internet Access, which people read as a Windows quirk. It is a statement about what the client received: no usable default gateway, no working resolver, or no path back for the addresses inside the tunnel. When the server is a Windows Incoming Connection, a single setting explains most such reports. The label is not a diagnosis, but it narrows the search to three places.

Read the lease before you change it

Run ipconfig /all on the client and find the VPN adapter among the entries. The address, the default gateway and the DNS server it lists are the facts you need, and they are frequently different from what the administrator assumes was handed out.

Three patterns map to three faults. An address in 169.254.0.0/16 means the client received nothing at all and assigned itself a link-local address. A plausible address with no gateway means the pool was served without the option that gives the client a default route. A complete lease that still reaches nothing points at forwarding or translation on the server side.

Write the values down before touching the server. The next step compares them with the range the server believes it is handing out, and memory is a poor substitute for a lease.

Why automatic assignment can leave no gateway

The Incoming Connections entry has its own IPv4 properties, separate from the physical adapter. The default there offers to assign addresses automatically, which relies on the connection's built-in allocator to supply an address, a mask, a gateway and DNS.

On a standalone workstation that allocator has no scope to draw from unless something else on the machine provides one, so the client can end up with a link-local address or with an address but no gateway. The connection looks established because the link came up, while the configuration behind it is incomplete.

That is why switching to a specified range fixes so many of these reports. You stop asking a service that may not be running to invent a lease and start stating the lease yourself.

The same confusion appears when someone expects the LAN router's DHCP server to serve tunnel clients. Broadcast discovery does not cross a routed tunnel, so that server never sees the request. Assuming otherwise is the most common reason a pool is blamed for a client that never asked it anything.

Set an explicit range the server can route

Choose a small block inside a subnet the server can reach, outside the range the LAN router hands out, and outside any other pool on the network. If the server sits on 172.20.10.0/24 and the router holds 172.20.10.1, a short block near the top of that subnet, say 172.20.10.201 to 172.20.10.209, keeps tunnel leases clear of the handout the router already manages.

Enter it in the IPv4 properties of the Incoming Connection, reconnect the client, and read the adapter again before changing anything else. A second reading is what tells you whether the pool was the fault or merely one fault among several.

These commands print the resulting configuration and the routes the client now has:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

The gateway in the lease should be an address the server holds, and the client's default route should point at it. If the lease is complete but no route exists, the server assigned without pushing a gateway, and the pool settings are still the place to look.

An address is not an internet path

Receiving a lease only moves packets from the client to the server. For internet access the server must forward those packets and translate them toward its own uplink, and that is a separate configuration with its own failure modes.

Internet Connection Sharing is the shortcut. It turns the internet-facing adapter into a shared gateway and runs its own addressing, which may rewrite that adapter's address and leave an existing NAT rule pointing at a value that no longer exists. Record the original settings before enabling it.

The routed alternative keeps the addressing stable and asks you to configure forwarding and translation explicitly. Neither approach is wrong; mixing them halfway produces a tunnel with a lease and no egress, which is exactly the symptom you started with. Pick one model and finish it before adding the other.

Rule out the outer path first

No pool can help if the tunnel never forms. The protocol decides what the path must carry: PPTP wants TCP 1723 and GRE, which is IP protocol 47 rather than a port; L2TP/IPsec wants UDP 1701 plus 500 and 4500; SSTP wants TCP 443.

A router that forwards the port but not the protocol produces a connection attempt that never authenticates. That is a different failure from a tunnel that forms and then reaches nothing, and the two should not be debugged together.

Test from the same LAN and from the remote network. If the LAN attempt works and the remote one never reaches authentication, the outer path is the problem. If both authenticate and only the remote client has no internet, go back to the pool and the egress.