A VPN Client With a LAN Address Is Not on the LAN

The client connects, receives 10.50.0.200, and cannot reach the server at 10.50.0.20 even though both numbers sit in the same /24. The belief behind that configuration is that an address from the LAN prefix makes the client part of the LAN. It does not. The client is on a point-to-point link, the server believes the destination is local, and the missing piece is a neighbour answer that nobody is sending.

The myth: same prefix means same segment

An address prefix tells a host which destinations it can reach directly and which need a router. It does not tell the host how the destination is physically attached, and it certainly does not guarantee that the destination can answer a link-layer request. Those are different questions, answered by different tables on the host. The mask answers the first one and the neighbour table answers the second, and only the first is under your control from the VPN side.

When the server sends to 10.50.0.200, it compares the destination with its own mask, decides the address is on-link, and asks the local segment for the hardware address that owns it. That request goes out on the Ethernet interface, and the VPN client is not there to hear it.

Nothing in the client's configuration can fix that from its side. The reply path depends on a device that is on the LAN answering on the client's behalf, or on the client having an address that the server does not consider local.

What the local host actually does with the address

The behaviour is easy to observe and worth observing before you change anything. Look at the neighbour table on a LAN host after it tries to reach the client: an incomplete or failed entry is the whole diagnosis in one line. That line also tells you the fault is local to the segment rather than somewhere inside the tunnel.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

The route lookup will report the destination as on-link through the Ethernet interface, which is exactly the problem. If the neighbour entry stays incomplete while the VPN session is up, you have confirmed that the missing piece is link-layer resolution rather than routing or firewall policy.

Run the same check from a host in a different subnet and compare. A host that reaches the client through a router does not need a neighbour entry at all, and that difference is the design decision in miniature.

How proxy ARP supplies a next hop

Proxy ARP makes the gateway answer the link-layer request on behalf of a destination it can reach through another interface. The LAN host receives a hardware address, sends the frame to the gateway, and the gateway forwards the packet into the VPN session. From the host's point of view the client simply looks like it is behind the gateway. Nothing about the client's configuration changes.

MikroTik's RouterOS ARP documentation describes that use for dial-in clients that borrow the connected LAN's address space. The mechanism is a neighbour-resolution fix, and it works because the gateway is genuinely on both paths.

That is not the same as bridging the client into the LAN. The gateway still has to forward the packet to the right active session, and its routing and firewall policy still have to permit the service. Proxy ARP changes who answers the neighbour request, not who is allowed to talk.

Read the platform's mode names carefully. RouterOS separates proxy-arp from local-proxy-arp, and the second handles traffic entering and leaving the same interface. They are not interchangeable spellings, and enabling both indiscriminately is not a shortcut.

What proxy ARP does not give you

It does not supply broadcast or multicast discovery. A client that needs to find a service by broadcast will still fail, because the gateway forwards unicast to the session and does not make the client a member of the LAN's broadcast domain. Discovery protocols that rely on broadcast are a common source of "it works for one thing and not another" reports on borrowed-address designs.

It does not reserve the address. If the borrowed number also sits in a DHCP pool or a static assignment, two devices can end up with the same address and the resulting behaviour depends on timing. A successful login is not a reservation.

And it does not remove the need to coordinate with whoever owns the LAN. A proxy ARP entry that surprises the address-plan owner is a support incident waiting for a quiet week.

Compare with a separately routed pool

The alternative is to give VPN clients their own prefix and let LAN hosts route to it. The server then sends off-link replies to its gateway, the gateway routes the prefix to the VPN endpoint, and no neighbour resolution is needed on the LAN segment at all. That is a smaller number of moving parts than a borrowed address plus a proxy answer.

That design is easier to reason about and easier to audit, because the client range is visibly separate from the LAN range. It costs a route, a return path and an access rule, which is the same set of things the proxy ARP design needs in a less obvious place.

Choose between the models deliberately rather than by accident. Proxy ARP repairs one specific relationship; a routed pool avoids needing that repair. Write down which one you chose and why, and the next person will not have to rediscover it from a failed neighbour entry.