Does disabling ARP break your VPN? It can, on the outer hop

Two packets travel in the same connection and obey different rules. One is the private packet the tunnel carries, which the virtual interface handles without any Ethernet header. The other is the encrypted packet that leaves the machine over the access link, and that one still needs a local next hop resolved to a hardware address. Confusing the two is how people disable address resolution on the wrong interface and then wonder why the tunnel never starts.

One packet inside another, two delivery models

The virtual interface in routed mode accepts IP packets. It has no Ethernet header, no broadcast domain and no addresses to resolve inside it, so the inner packet is delivered by the tunnel itself. Whatever happens on the access network is a separate layer of delivery.

inner packet: private address -> tunnel device -> the VPN process
outer packet: endpoint address -> access route -> next-hop hardware address

That outer packet is an ordinary unicast frame when it leaves an Ethernet interface, and it needs the destination hardware address of its next hop. Address resolution provides it, and the next hop is usually the local gateway rather than the remote server. Understanding that the lookup is for the gateway, not for the endpoint, is most of the diagnosis. Write both addresses down before you change anything.

Find the neighbour that actually matters

Ask the routing table which next hop the endpoint uses, then inspect the neighbour table for that hop. The endpoint itself rarely appears there, because it is not on the local link.

ip route get 198.51.100.20
ip neigh show 192.168.0.1

If the entry is present and reachable, the outer path is fine and the fault is elsewhere. If it is missing or in a failed state, the link, the gateway address or a policy that blocks resolution is the place to look. Changing cipher settings on the tunnel cannot help in either case. Note the state string the neighbour table reports, because it distinguishes an attempt in progress from a permanent failure.

A learned entry can hide the dependency

A cached entry keeps working for a while after whatever created it is gone, so a test performed minutes after a change can pass for the wrong reason. Wait for the entry to age out, or delete it deliberately, before concluding that resolution is unnecessary.

The reverse mistake is equally common: an unresolved entry is treated as proof that the tunnel is broken. In practice it points at the local segment, at a duplicate address, or at a port security rule that drops the frames carrying the answer. Check the switch port before you touch the VPN configuration.

Read the timing as evidence. An entry that resolves and then expires repeatedly suggests a flapping link or two devices answering for one address, while an entry that never resolves at all points at the gateway address or at filtering on the access port.

Decide between dynamic resolution and a fixed entry

Dynamic resolution is the default for a reason: it follows the hardware when a gateway is replaced and needs no coordination with anyone. A static entry is defensible when the network is deliberately managed and the pairing of address and hardware address is part of a documented design.

Either way, apply the choice to the access interface that carries the outer packet. Turning resolution off on that interface does not harden the tunnel; it removes the client's ability to reach the gateway that carries it, and the failure looks like a dead VPN rather than a local addressing problem.

Keep the other stack in mind

IPv6 does not use address resolution in the same form; it uses neighbour discovery. The layered question survives unchanged: how does the actual outer packet reach a local next hop, and what proves that the answer is current.

Check the same two facts on the other stack before declaring the design complete, because a tunnel that carries both families has two outer paths to consider. Record which one you verified and which one you assumed.