DHCP across a VPN: bridge the broadcast or relay it?

A new laptop on the far side of the tunnel gets no address, while the same laptop works at headquarters. The usual first guess is that the tunnel is blocking DHCP. More often the broadcast never had a path: an unconfigured client sends to 255.255.255.255, and an ordinary IP router does not forward that packet. The tunnel is doing exactly what a routed tunnel does.

Two designs can change that, and they are not equivalent. One carries the broadcast; the other relays the request.

The broadcast never crosses the router

A DHCPv4 client with no address sends from 0.0.0.0 to the limited broadcast address on UDP ports 67 and 68. That packet stays on its link by design. A router that forwarded it would be flooding every segment it serves.

So a routed site-to-site tunnel connects the relay to a server. It does not extend the client's broadcast domain, and no firewall rule will make it do so.

What a bridged tunnel actually extends

A deliberately bridged VPN can carry Ethernet broadcast under its supported topology, and then DHCP can cross as local traffic. That is a real option, but it is a Layer 2 design choice. You are extending the failure domain and the access boundary along with the broadcast.

Bridging also changes what a broadcast storm, an ARP sweep or a rogue DHCP server can reach. If you would not plug the remote office into the same switch, do not bridge the tunnel just to hand out addresses. Test that blast radius before you enable it.

It is a larger decision than supplying an address, and it should be made deliberately.

Relay the request instead

The usual answer is a relay on the client's local network. It receives the broadcast, turns it into a unicast request, and puts its own address in the gateway-address field. The server replies to that relay address.

For an illustrative remote office, the relay sits on the office LAN and the server is reached over the site VPN. Configure the scope for that office, the relay and server identities, and the complete return path. Allowing UDP 67 through the tunnel does not tell the server which pool to use.

A relay that forwards but never receives a reply is usually a return-path problem. Check the route back to the relay address before you change the scope.

Separate DHCP from ARP and from tunnel addressing

DHCP rides over UDP/IP. On Ethernet, a host may also use ARP to check whether a candidate address is already in use. That conflict check is a separate link-local operation, not the transport for DHCP messages. Saying DHCP is essentially ARP is wrong; saying the two never relate is too broad.

A VPN client can also get its tunnel address from the VPN protocol or the server's own pool rather than from a DHCP broadcast. An option whose name contains DHCP may describe pushed client settings, not a relayed DHCP packet. Check the server's pool before you assume DHCP is involved at all.

Record the recipient network, the allocation owner, the scope, whether a relay exists, and the expected behavior during an outage. Then test a fresh lease and a renewal through that model. If two sites can serve the same unmanaged pool, you have a conflict waiting for the first roaming laptop.