Reach the router admin page over VPN, not the WAN

The router admin page opens in two seconds from the sofa and times out from a hotel room, while the VPN client reports connected throughout. What you have is a way out, not a way back: the tunnel carries your traffic to the internet and stops there. Reaching a device inside your own LAN needs a session that terminates on something with a route into it. That is a design decision rather than a setting, and it determines whether the rest of the work is possible at all.

The distinction is easy to lose because one product can do both jobs. A commercial exit client and a remote-access server can speak the same protocol on the same port, and the difference is which side owns the address space behind the endpoint.

Which side of the tunnel owns the LAN

For administration the endpoint has to sit inside the network you want to reach, or hold an authorised path into it. A router running its own VPN server qualifies; so does a small always-on host with a fixed address and a route to the LAN. An exit service operated by a third party does not, because its endpoint has no interface on your LAN and no rule that would let one appear. This is the check to finish before touching anything else.

Firmware rarely labels that difference, so read what the feature does rather than what protocol it names. WireGuard, OpenVPN and IKEv2 all appear on both sides of the market: one build sends household traffic outward, another accepts your remote device. A client-only build cannot be turned into a server by configuration, however the menu is worded.

Making the return route exist

A WireGuard server on the router has an interface address such as 10.8.0.1/24 and a peer entry for the laptop. The client decides which destinations it will send into the tunnel, and a list containing only the tunnel subnet leaves the LAN invisible however the server is configured. Both ends have to agree, and only one of them is usually edited.

wg show wg0 allowed-ips
ip route get 192.168.1.1

The first command reports what each peer is permitted to send from the server's point of view; the second reports where a LAN address would actually go on the client. A LAN destination that resolves to the tunnel interface is routing that works, and one that leaves through the physical gateway will never arrive no matter what the firewall says. Add the LAN prefix to the client's allowed list and the same two commands become a verification step rather than a diagnosis.

The strongSwan forwarding documentation describes the same hop for IPsec gateways, where forwarding and a source-NAT rule are what connect a tunnel client to an internal host. The addressing differs; the requirement does not.

Who may open the admin page

Access control belongs on the router, not in the intention to be careful. Permit only the authenticated tunnel identity or source range that needs the page, and read the router's own input chain as well as any forwarded LAN policy. A rule that lets the wired LAN reach the admin page says nothing about a client arriving on the tunnel interface. Write the exception for a specific identity, then keep a second identity that should be refused.

The listener is the other half and it is invisible in firewall output. ss -ltnp shows the address the web server is bound to, and a service bound to the LAN address alone will not answer on the tunnel address however permissive the rules are. Rebinding it or adding an address is a configuration change on the router, not a firewall change.

Keep authentication and transport validation switched on in the same pass. Reachable is not trusted, and every device inside a tunnel is not thereby an administrator. The tunnel credential and the router account are separate privileges with separate lifecycles, so a lost laptop can have its key revoked without resetting every administrator's password.

Testing from outside, not from the sofa

Test from a network you do not control. Connect through the approved tunnel, open a fresh admin session, and change something harmless that you can see reflected in the page. From the sofa you are proving that the LAN works, which was never in doubt.

Then test the refusals with the same care. Attempt the page without the tunnel and confirm it fails, and confirm the administration service is not listening on the WAN address at all. A page that is merely unlinked is not access control, and a WAN listener showing a login form is still a WAN listener. If a password is the only thing between the internet and the router's console, the design is a password.

Household services deserve a look while you are there. Tightening management rules often breaks the guest network or the resolver the family devices use, and that surfaces days later as an unrelated complaint.

Keeping a way back while you change things

Before changing routes or tunnel settings remotely, prepare an independent way back. An existing session can survive the change that already blocks new connections, which is exactly how people lock themselves out while watching a session that still works. The options are concrete: a scheduled reboot to a known configuration, console or physical access, a second tunnel that does not depend on the setting being edited, or out-of-band management where the hardware offers it. Choose one and prove it before the maintenance window instead of during it.

Keep the record short and current: which host terminates the tunnel, which identities may reach the page, which address the service binds to, and how a lost device is revoked. That list doubles as the recovery plan, because it says where each dependency lives. A missing return route is a routing problem to repair, and it is never a reason to publish administration on the WAN.