VirtualBox VPN Gateway for the LAN: Bridge, Route, Return

Bridge the gateway VM onto the LAN, advertise the LAN to clients, and add the pool route to the LAN router. A worked IPv4 example with real return paths.

Remote users need to reach a printer and a file server on a physical LAN, and the only always-on Linux box is a VirtualBox VM. Bridging the VM onto that LAN is the first half. The second half is a return route that every LAN device will actually use, and that is the part most setups miss. When it is missing, the tunnel connects, the client pings the gateway, and nothing else answers.

Use addresses that can be reached

Set the VM's LAN adapter to the Bridged Adapter attachment approved for that network, and give it an address through the normal allocation process. The VM then appears on the physical LAN like any other host. Its default route must still use the real gateway, so the encrypted transport to the VPN peer stays reachable. Do not use the default VirtualBox NAT address as the LAN's next hop, because that address lives behind a virtual NAT and is not on-link for the host or for other LAN machines.

LAN router:          192.168.70.1/24
VirtualBox host:     192.168.70.5/24
VPN gateway VM:      192.168.70.10/24
Example LAN service: 192.168.70.40
VPN client pool:     10.80.0.0/24

Check for overlap with remote users' home networks before choosing the pool. An overlap turns into a routing ambiguity that no amount of server configuration fixes.

Advertise the LAN, then forward

For a server whose authentication and transport are already managed, the networking lines look like this. The push tells an accepting client how to reach the LAN, and it does not make the VM forward anything by itself.

dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"

Enable IPv4 forwarding in the VM's persistent network configuration, and permit the client pool to reach the intended LAN services at the VM's forwarding boundary. Permission to reach the VPN listener is a separate rule, and it is already working if the tunnel came up.

The return route belongs on the LAN router

LAN devices reply through their default gateway, which is the LAN router at 192.168.70.1. That router has no idea where 10.80.0.0/24 lives unless it is told. Add the pool route to the router's supported persistent configuration, pointing at the VM's LAN address. Adding it only on the VirtualBox host repairs paths that consult that host, which is not every device on the LAN.

ip route add 10.80.0.0/24 via 192.168.70.10

The destination's own firewall still has to permit the client pool as a source. A route carries the packet; it does not grant the service.

If the LAN router cannot be changed, scoped source translation on the VM is the alternative. It makes replies return without the route, and it hides the individual client addresses from the LAN service.

Follow one packet end to end

A client at 10.80.0.25 sends to 192.168.70.40 through the tunnel. The VM forwards the packet onto the LAN. The service replies to its router, which selects the VM for the client pool, and the VM returns the packet through OpenVPN. Every hop in that sentence is a place where the design can fail.

Test with the real application from a remote client, then repeat after reloading the managed configuration on both the VM and the router.

If the client can reach the VM but not the service, check the router's route first. If the service receives the request and the client never sees the reply, the return path is the suspect.

Skyldar greinar