Preconfigured VPN Router Checklist: What to Verify at Handoff

A preloaded router arrives with someone else's decisions already baked in: which VPN service it dials, whose account pays for it, what traffic it captures and who holds the password that changes any of that. Treat the handoff as an audit rather than an unboxing. The five steps below are ordered, and each one has a stop condition; if a step fails, the later steps cannot tell you anything reliable about the device. Work through them with the router in front of you and a laptop behind it.

Step 1: take administrative control of the box

Find the management address, log in, and change the administrator password before you connect anything important. On a GL.iNet travel router that address is 192.168.8.1 and the first-run wizard asks you to set the password; other sellers document their own address and may ship a fixed credential printed on the label. If the device arrived with remote support or cloud management enabled, decide now whether that stays on.

ssh [email protected]
cat /etc/openwrt_release
ubus call system board

Those three commands answer who built the firmware, which release it is and what hardware revision you actually received. Write the output into the handoff record, because a later support call will start with exactly those questions. A router that answers SSH but refuses a password change, or that has no documented recovery path, is not a device you can own.

Stop here if you cannot obtain exclusive admin access. Everything after this point assumes you can read and change the configuration without asking the seller.

Step 2: establish whose VPN account the tunnel uses

The tunnel is a subscription in someone's name, and the handoff is incomplete until you know which name. Ask for the provider, the account holder, the renewal date and the exact credential installed on the device. A preloaded configuration that shares one credential across many buyers cannot be revoked for you alone, which matters the day the seller loses control of it.

wg show
uci show network | grep -i -E 'vpn|wireguard|openvpn'
ip route show table all | head -40

On WireGuard the output names the peer and the last handshake time; on OpenVPN the profile sits under /etc/openvpn and the running service shows which profile is active. Record what you find, because a reconnect that silently uses a different endpoint is a change you will want to detect rather than explain away.

Stop here if the account cannot be transferred, renewed or revoked in your own name. A device you can administer but cannot re-provision becomes a brick the day the subscription lapses.

Step 3: test the exit location from a client, not the router

The country printed on the box, the country in the seller's listing and the country of the public address are three different facts. Only the last one affects what a website sees, and it is produced by the provider's endpoint rather than by the shipping address. Run the check from a laptop behind the router with the tunnel up, not from the router's own shell.

curl -s https://ifconfig.me
curl -s https://ipinfo.io/json
dig +short myip.opendns.com @resolver1.opendns.com

Compare the three answers. If they disagree, something between the client and the endpoint is rewriting or proxying traffic, and you should find out what before you rely on the location. Geolocation databases are operator-fed estimates, so a matching country code is supporting evidence rather than proof of a physical path.

Stop here if the exit differs from the one you contracted for, or if the answer changes between queries. A rotating or inconsistent exit breaks region-dependent services and makes every later measurement ambiguous.

Step 4: pin the firmware and the update channel

Preconfigured devices often ship with an older build and a vendor configuration layered over OpenWrt. Before you accept any update, establish whether an upgrade preserves the VPN profile, whether the seller supplies a replacement profile, and who is expected to perform the upgrade. Read the release notes for the model you actually have, not for the model in the listing photo. If the seller answers none of those questions, treat updates as unsupported and freeze the build you have.

cat /etc/openwrt_release
cat /etc/glversion 2>/dev/null
opkg list-installed | wc -l

Keep a copy of the working configuration off the device before you change anything: the WireGuard keys, the OpenVPN profile and the firewall rules that implement the routing policy. A factory reset without that copy removes exactly the configuration you paid for, and the seller may not reissue it.

Step 5: decide what the tunnel covers and what happens on failure

Whole-network routing, selected-device routing, DNS handling, IPv6 and kill-switch behaviour are separate settings that an interface often collapses into one toggle. Check them one at a time, because a connected router proves only that the router itself can reach the endpoint. Test from a downstream client with the tunnel up, then again with it down.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111
nft list ruleset

If IPv6 is enabled on the LAN but not routed into the tunnel, clients may prefer it and leave the VPN path entirely while IPv4 still looks protected. If the kill switch is off, a dropped tunnel falls back to the ISP path, which is a fine choice only when you made it on purpose. Both conditions are invisible from the provider's dashboard.

Write the support split down before you need it. The hardware seller, the firmware maintainer and the VPN operator are three parties with three different recovery procedures, and one contact may cover several roles without covering all of them. The handoff is finished when you can administer the device, renew or revoke the account, reproduce the intended exit, update the firmware without losing the profile, and say exactly what happens when the tunnel drops.