VPN Router LAN and WAN: What to Record Before You Buy
A VPN label says nothing about VLANs, WAN failover or tunnel roles. Write the exact capabilities down for the model and firmware you intend to deploy.
Treat a VPN-ready label as one feature on a box that must also route, segment and fail over, since the label says nothing about how many separate networks the device can hold. Start by writing a capability record for the exact model and firmware, then compare that record against the flows the site needs. Marketing pages list sockets; they rarely list VLAN membership, failover policy or tunnel scope. The record takes about twenty minutes and settles most purchase arguments before the hardware arrives.
Pin the Exact Box Before Anything Else
Model names travel across firmware generations, and the same enclosure can ship with a different switch driver depending on the release. Read the board identity from the device itself rather than from the carton, so every later claim is tied to something you can reproduce. One command covers model, board name and firmware release on OpenWrt, and the equivalent screens exist on most business firmware.
ssh [email protected] 'ubus call system board'
cat /etc/openwrt_releaseWrite those strings into the record, never shortened. Then separate the ordinary routing job from the tunnel job. A device that forwards packets well may still refuse to terminate a tunnel, and a device that terminates a tunnel may have no way to keep two local networks apart. Treating those as one requirement hides the mismatch until the unit is already racked, configured and half trusted.
Record the LAN Structure, Not the Port Count
Four sockets usually mean one switch, and a switch means one broadcast domain unless VLANs are configured. That is fine for a flat home network and wrong for a site that wants a guest segment, a management segment and an isolated camera segment on the same box. Record which ports belong to which VLAN, which VLANs reach the CPU, and which interfaces carry addresses.
Where the firmware offers VLANs, the interface list decides how many distinct policies you can write. A VLAN that is defined on the switch but never assigned as an interface has no address and no firewall zone, so it cannot enforce anything on its own.
| Field to record | Example entry | Review stops if |
|---|---|---|
| Ports and VLAN membership | ports 1-4 untagged on VLAN 10, port 5 trunk with VLAN 10 and 20 | the datasheet offers only a socket count |
| Routed interfaces | br-lan 192.168.88.1/24, vlan20 192.168.99.1/24 | two subnets cannot hold separate policies |
| WAN method and failover | DHCP on wan, PPPoE on wan2, policy route to wan2 on loss | only one uplink is configurable |
| Tunnel role and scope | WireGuard peer on the router, only 192.168.88.0/24 routed inside | the router can only pass another tunnel through |
Read the switch state rather than trusting the menu. On older OpenWrt targets the switch tool prints the configured devices, and on DSA targets the bridge tooling reports the same facts per port, which is why the firmware release belongs in the record.
Write Down the WAN and Failover Behaviour
Access method, address ownership and failover order belong on one line per uplink, because a tunnel that survives a WAN change depends on all three. A PPPoE session reconnects with a new address and drops the tunnel with it, while a DHCP uplink that keeps its lease may not.
Failover also needs a policy decision. Sending all traffic to the backup link is easy; keeping the tunnel on the primary while ordinary web traffic uses the backup requires policy routing, and not every firmware exposes it. Note whether the tunnel is bound to one uplink, and what the device does to established sessions when that uplink disappears. Capture the routing table as evidence, not the failover checkbox.
Test One Permitted Flow and One Denied Flow
The record is only worth keeping if the device can be accepted against it. Pick one flow that must work, one that must not, and run both from a client on the segment in question. A tunnel that carries every subnet is a failure when the requirement was one subnet.
Then confirm the denial, since a permissive default is the usual surprise. The guest segment must not reach the management address, and the check should show a timeout or refusal rather than a login page.
curl -sS --max-time 8 https://api.ipify.org
ping -c 2 192.168.99.1
ip -4 route get 192.168.99.1If the allowed flow works and the denied flow also works, segmentation is missing even though the menus suggested otherwise. If both fail, the tunnel scope or the return path is wrong, and the WAN record usually explains which. Keep the two results with the capability record so the next reviewer sees what was accepted, on which firmware, and on which date.