Why router admin stops answering after a VPN change

You changed a route or a firewall rule to test a tunnel on the router, and now the admin page does not answer from the laptop that was fine ten minutes earlier. The reflex is to blame the VPN. Most of the time the tunnel is healthy and one of three other things broke: no route back to the router's own address, an input policy that drops the request, or a web service that is not listening on the address you are calling. All three look identical in the browser, which is why people restart the tunnel for an hour and learn nothing.

Here is the myth worth killing first: a working tunnel is not a way back in. It is a new network attachment with its own trust questions, and it can quietly remove your old management path while opening a new one nobody reviewed.

The tunnel was never the management path

Forwarding and input are different jobs. "Can a client reach the NAS through the tunnel?" is a forwarding question about packets that pass through the router. "Can I open the router's SSH port?" is an input question about packets addressed to the router itself. A pass rule written for forwarded traffic does nothing for the second, and that is the most common reason a tunnel that carries traffic perfectly still refuses your admin session.

The converse mistake is trusting an interface name. A tunnel is encrypted to the peer, not to every service behind it, and the word VPN in an interface label says nothing about which sources should be allowed to log in.

Layer one: is there a route to the router's own address?

Start on the client and ask the kernel where the packet will go. On Linux, ip route get 10.6.0.1 prints the chosen route, the outgoing interface and the source address. If it reports the default route toward your ISP, the packet never enters the tunnel, and no rule on the router can save it.

The tunnel side has its own version of the question. WireGuard treats AllowedIPs as a cryptokey routing table: on each end it declares which source addresses a peer may use and which destinations get sent to that peer. If the client entry does not include the router's tunnel address, the client has no route for it. If the server entry for that client does not cover the client's tunnel address, the server drops the packet before any firewall rule is consulted.

Confirm the exact address you expect to reach before debugging policy. A stale DNS record or a cached neighbor entry from before the change sends you to an address the router never owned.

Layer two: the input policy, not the forwarding policy

Firewalls evaluate rules on the interface where the packet arrives. On pfSense and OPNsense, the interface tab and the rule order decide whether traffic to the firewall's own services is allowed; a rule that lets LAN clients out to the internet is not a rule that lets a tunnel peer open the web GUI. On OpenWrt with firewall4, each zone carries an input policy, option input 'ACCEPT' or 'REJECT', and a tunnel interface in a zone with input REJECT will refuse management connections while still forwarding traffic if forwarding is permitted.

Do not disable the anti-lockout rule to make the new path work. That rule keeps the LAN management address from being locked out by a bad rule; it protects the LAN subnet, not the tunnel subnet you just created. Add one narrow rule for the administrator source and leave the safety net alone. The pfSense admin access documentation covers where those controls live.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Layer three: is anything listening on that address?

A service can be running and still be unreachable because it bound to one address. OpenWrt's uhttpd keeps explicit listener entries in /etc/config/uhttpd, for example list listen_http '0.0.0.0:80'; a build that binds the LAN address only accepts nothing on the tunnel address, and products that expose a listen-interface setting behave the same way. The listener commands above answer this directly.

Then separate refusal from silence. nc -vz 10.6.0.1 443 returning a refused connection means the packet reached the router and something rejected it, either a closed port or an explicit reject rule. A hang until timeout means the packet was dropped or never routed. That distinction tells you which layer to inspect next, and it costs five seconds.

A VPN interface is a boundary, not a recovery path

Encryption protects the wire; it says nothing about who may open the admin page. Once the tunnel works, resist the urge to solve reachability by permitting everything on the tunnel interface. Give administrators a rule keyed to their own tunnel address or a separate admin-only tunnel, and keep ordinary users, the NAS, the cameras, the family laptops, away from the management port. A peer that needs a file share should not be one rule away from the router's login.

The router's role changes the answer. A router that terminates the tunnel may legitimately accept administrators from it, while a router that only uses the tunnel as an internet exit usually should not. In both cases the subnet permit is not the login, so keep account authentication and transport security enabled.

The compensating move people make after a lockout is worse: enabling WAN administration or forwarding a port to the web GUI. That turns a short outage into a permanent exposure, and the login page is then reachable by every scanner on the internet. Test the denied side as well as the allowed side, so a peer that should not have admin access times out or is refused instead of receiving a login prompt.

Test with a fresh connection too. A stateful firewall keeps existing flows in its state table, so the SSH session you already have open can survive a change that blocks every new connection. That is how a lockout stays invisible until the next reboot or the next laptop sleep.

Prepare the way back before you touch policy

Write down four things before the first change: how you will reach the device if the tunnel dies, such as a serial console, a provider console or a machine on the LAN; where the current config is exported to; which single rule or route you are about to modify; and how you will revert exactly that item. On OpenWrt, sysupgrade -b /tmp/backup.tar.gz captures the configuration, and edits stay pending until uci commit, which gives you a cheap undo if you notice in time. pfSense keeps a configuration history, and AutoConfigBackup helps only if it was already enabled. If the router runs a fail-closed rule set, confirm the maintenance path you planned is not inside the traffic that rule blocks, and remember that a reboot re-applies persistent rules rather than clearing them.

Change one boundary per attempt, then test from a new connection rather than the shell you are holding open. If the test fails, revert that one change before touching the next layer. The tunnel can stay up the whole time, but its green status icon is not evidence that you can still get in.

Quick pass before you walk away:

• Can you reach the router from a source that does not depend on the rule you just edited?
• Does the input policy on the tunnel interface allow only the administrator source?
• Is the management service bound to an address that exists on the tunnel?
• Have you tested one denied peer and one fresh session?
• Is the WAN administration surface still closed?