New Router, Same VPN Server: Move Its Public Entry

You plug in the new router, the internet comes back, and the VPN client on your phone still points at an address that no longer answers. Nothing on the VPN server changed, because the server never moved. The router was the public entry point, and replacing it replaced the address, the forwarding rule and possibly the dynamic DNS updater at the same time.

Treat the swap as two handoffs, not one, and keep a local way into the admin interface while you work.

Write the handoff down before unplugging

Record the LAN prefix, the server address and how it is assigned, the listener and transport the VPN actually uses, the inbound rule that publishes it, and the name clients have saved. Then note which machine updates the dynamic DNS record today: it may be the router, the server itself, or a separate agent on another host. Do this while the old admin pages still load. A screenshot of the inbound rule beats a remembered port number.

Add the private prefixes clients are supposed to reach, and how devices on the LAN send replies back to them. Both are easy to forget because the replacement wizard talks about internet access, not about return paths. Also export the old configuration if the vendor supports restoring it, while accepting that a backup from one model rarely imports cleanly into another.

Keep that record somewhere protected. A router backup can contain credentials for the WAN link. Treat the export file like a password rather than like a settings note.

Move the address, then the forward

If the new router keeps the same LAN prefix, give the server the reservation it had, or an equivalent static assignment. If the prefix changes, update the server address first and any listener binding that names it, because a forward pointing at the old address will silently send traffic nowhere.

Then recreate exactly one inbound rule for the transport the VPN uses. The manufacturer guides that describe forwarding to a local server show the mechanism, not a universal recipe, so map the rule to your actual protocol and port rather than to a list from a blog. A forward on the new router cannot remove carrier-grade NAT sitting upstream of it, and no local rule will make a private address reachable from the internet if the provider already shares one with you.

Confirm the server's own firewall still permits that traffic. Check whether a second gateway sits between the router and the internet, because many providers hand out a combined modem and router. Read the WAN address on the new device and compare it with the address clients resolve. If those differ, your forward is landing on something that is not the edge.

Decide who updates the public name

Endpoint updates need one owner and only one. If the old router published the name, configure a supported updater on the replacement and confirm the record actually changed. If the server was already publishing it, leave that arrangement alone rather than adding a competing updater that flaps between two addresses.

When the deployment publishes both address families, read both the A and the AAAA record. Each has to point at a service that is genuinely listening and permitted through its own firewall path, and a working IPv4 mapping says nothing about the IPv6 side. Also keep the identity checks in the client profile: a changed public address is not a reason to accept a certificate or peer key that does not match.

Prove the swap from outside

Test with an authorised external connection and a fresh session, not from inside the LAN. An inside test against the public address depends on hairpin behaviour and exercises a different path than a real client will.

Follow the sequence a client follows: resolve the name, negotiate the tunnel, authenticate, then perform one operation against a private resource. That last step is the one people skip, and it is the only one that proves the return path. If login succeeds but the private operation fails, compare the new LAN prefix, the routes the client selected and the resource's reply path against your handoff notes.

Only after all four steps pass is the old router safe to retire. Unplug it, then repeat the external test once more. A stale record that still resolves to the old address fails at the very first step, and that is easier to diagnose while the old device is still on the shelf.

Keep the new mapping with your recovery notes

File the final server assignment, the inbound rule and the name of the update owner next to the procedure for reaching the router locally. The next replacement should start from that page instead of from a traceroute.

If the tunnel still fails from outside after everything above, check whether the public address the router reports matches the one clients resolve. That single comparison separates a DNS problem from a forwarding problem, and it takes less time than reading another port-forwarding guide.