That L2TP Address Is IPCP, Not a DHCP Lease on the LAN

The inner address comes from PPP negotiation, not from the office DHCP server. See which stage assigns it, why the LAN cannot reply, and what to check.

The connection comes up and the adapter shows an address in the office range, so the natural conclusion is that the VPN gave you a LAN address and therefore put you on the LAN. Neither half of that is quite right. L2TP carries a PPP session, and PPP negotiates the inner IPv4 address with IPCP. That address is a session parameter agreed between two peers, not a lease handed out by the office DHCP server, and holding it does not make you a neighbour on the office wire.

Two addresses in one connection

There are two independent negotiations in an L2TP connection. The outer one establishes a protected path between your device and the VPN endpoint over whatever network you already have. The inner one is the PPP session, and it is where your session address and the peer's address are agreed. Internet traffic may leave under a third address entirely, the endpoint's public one, which is why a VPN check page and the adapter address rarely match.

Keeping those three roles separate answers most of the questions people bring to this layer. A private number on the VPN interface is normal and expected. It says nothing about whether the endpoint changed your public exit, and it does not by itself decide which destinations your traffic reaches.

What IPCP does, exactly

IPCP is the IPv4 control protocol for PPP. Each side sends Configure-Request messages describing the options it wants, and the address option is one of them. A client that has no address yet typically asks with 0.0.0.0, and the server responds with a Configure-Nak carrying the address it wants the client to use. The client then requests that address, and the session comes up with a local and a remote address.

That exchange is documented in the PPP and IPCP specifications, and it explains a detail that looks like a bug: the address is chosen by the server from its own policy, which may be a pool, a per-user setting or an address tied to the authenticated identity. When the pool is exhausted, or the policy conflicts with the request, authentication can succeed while address negotiation fails, and the client reports a connection that never settles.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

A pppd log line naming a local and a remote address is the successful end of that negotiation. Its absence, next to a successful authentication, points at the address stage rather than at credentials.

Why the LAN cannot reply to you

An address from the far side's range creates an expectation that hosts on that LAN can reach you, and mostly they cannot unless the server routes your session address back into the tunnel. Being inside a pool is a statement about allocation, not about topology. The office file server has no route to your session address unless the VPN server forwards it, and it may not be permitted to even if it does.

This is also why overlapping ranges cause trouble out of proportion to their apparent size. If the pool overlaps a LAN the client already uses, the client's routing table now has two claims on the same prefix, and the wrong one often wins for reasons that have nothing to do with the tunnel.

Verify the session, then the route

Check the interface first, then the routes, then one destination that matters. Each step has its own failure mode, and testing all three at once produces a conclusion you cannot defend later.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

If the public check shows the endpoint's address while a private destination times out, the tunnel is carrying your default route and the far side is not answering for that destination. If the private destination answers but the public check does not change, the profile is split-tunnelling and only some traffic uses the session.

Keep the three stages apart

Authentication, address negotiation and forwarding fail differently, and each has a different owner. Credentials are an identity problem, IPCP exhaustion is a server policy problem, and a missing return route is a network design problem. Reporting all three as "the VPN is broken" guarantees a slow fix.

Record the assigned address, the pool it came from and whether the LAN is supposed to reach it. That single note prevents the next person from assuming a DHCP lease and hunting for a scope that was never involved.

Zvinyorwa zvakafanana