Why a LAN Host ARPs for an OpenVPN Client Address

Reachability problems between a LAN host and a VPN client often trace back to the address plan itself. Give that host an interface on 10.0.100.0/22 and it treats every address from 10.0.100.0 through 10.0.103.255 as directly connected, including a client pool quietly placed at 10.0.101.0/24. The reply never goes to a router, because from the host's point of view no router is involved. The packet is addressed to a neighbour and asked for on the wire.

That mechanism sits behind a whole family of reports: the tunnel is up, the server has a route, and the LAN host still cannot reach the client.

The /22 That Swallows the /24

Read the prefix as a range, not as a string. A /22 holds 1,024 addresses, and 10.0.100.0/22 spans 10.0.100.0 to 10.0.103.255, so a pool at 10.0.101.0/24 sits entirely inside it. The mistake survives review because the pool's first octets look different from the LAN's first octets, and only the third octet reveals the containment. Write both ranges out numerically before declaring them separate.

The same containment can appear in reverse. A pool that looks free because nothing currently uses it may still fall inside a prefix some site router advertises, and the address plan is the only document that shows it.

On-Link Means ARP, Not Routing

When a host with a /22 interface sends to 10.0.101.25, the kernel compares the destination against the interface's prefix and finds a match. The packet becomes a neighbour lookup rather than a routed one, and on Ethernet the neighbour lookup is an ARP request for that address. If the address belongs to a VPN client behind a routed gateway, no host on the LAN owns it, so the request goes unanswered and the packets are dropped. The tunnel is not at fault, and the client never sees the traffic.

This is why the failure looks asymmetric and occasionally intermittent. The VPN host can often reach the LAN because its own routes point the right way, while the LAN host cannot answer, and anything caching a stale ARP entry makes the symptom flicker.

TUN, TAP and What Each Carries

A TUN device carries IP packets, and a TAP device carries Ethernet frames. A routed TUN link does not need to carry ARP to deliver IP reachability, which is exactly why the unanswered request above is expected rather than broken. TAP with a deliberate bridge can extend the broadcast domain and make ARP work, but it changes what the client can see, requires endpoints that support the same framing, and is a redesign of the network model rather than a repair for an overlapping prefix. Switching a routed deployment to TAP to cure an address-plan error trades a small problem for a larger one.

Record where the ARP request appeared and which system emitted it before drawing conclusions. The sender is telling you what it believes about the destination, not what the tunnel does.

Design a Pool That Cannot Overlap

Pick a pool outside every connected prefix and every advertised site prefix, then add the routes that make it reachable in both directions. A range such as 10.8.0.0/24 in an unused part of the plan is easy to reason about, and a LAN that needs to reach it gets a static route pointing at the VPN server. Change the allocation, the advertised routes, the permitted source addresses and the firewall rules together, because they describe one design rather than four settings.

Source NAT on the server can hide the pool behind a LAN-routable address, and it is a legitimate migration tool. It also rewrites the source, so the LAN loses the ability to attribute connections to individual clients and to apply per-client rules.

For acceptance, use the real client's assigned address and a real application request from a LAN host, then confirm the reply follows the planned gateway rather than the wire.