Remote panel access without a fixed IP: use dynamic DNS

What dynamic DNS does and what it leaves alone

Most small sites reach the internet over a connection with a dynamic public address. The provider's DHCP server hands the router an address. It leases the address for 24 hours to a few days. It can hand out a different one after the lease ends or the router reconnects. A dynamic DNS provider gives that moving address a stable name, such as plant1.example.net. An update client, usually built into the router's setup interface, watches the WAN address and notifies the provider the moment it changes. The provider republishes the record under the name. That loop is the whole mechanism: watch the address, detect the change, push the update.

The name does one job. It keeps pointing at the site's current public address. It does not forward a port, change a firewall rule, or supply a public address where the provider hands the site a shared one. Think of it as the sign on the door. The name brings a connection to the right building. The forwarding rule or the tunnel decides whether the door lets anyone in.

The WAN address test that decides the job

Before any name or rule, read the router's WAN address on its status page and compare it against the private and shared-carrier blocks. An address inside one of these blocks means the site has no public address of its own. No amount of name maintenance repairs that.

With carrier-grade NAT, the internet has no route to your router at all. That is why some sites cannot be reached from outside no matter how carefully the name is kept. The dynamic DNS name is still worth running for the record, but the reachable path has to come from a public address on the account or from a tunnel the site dials outward.

Give the panel a local address that never moves

A forwarding rule sends each incoming connection to a destination on the LAN, so that destination has to stay the panel. Reserve the panel's address in the router's DHCP reservation table. Or set a manual address comfortably outside the pool the router hands out. Write down the subnet mask, gateway and DNS values the site network uses. Enable the panel's own web access feature and note the port it listens on. The panel's manual prints that port, so take it from the manual, not from a guess.

From a laptop on the same LAN, open the panel's address in a browser and check the web page loads. A ping reply shows the address is alive. The loaded page shows the web service answers. Once the local side works, the remaining job is the rule itself, and the port forwarding check that tests each step is the shortest way to find where a rule is wrong.

Worked example: a plant router on a 24 hour lease with a 300 second DNS TTL

Inputs, each with its source:

• WAN address shown on the router's status page: 203.0.113.45, one of the addresses reserved for documentation examples under RFC 5737, used here for illustration.
• Provider DHCP lease: 24 hours, the typical figure for small-site broadband.
• Panel web port, from its manual: TCP 443, the usual HTTPS port.
• Dynamic DNS record TTL: 300 seconds, a common short default among DDNS providers, who keep TTLs short so a changed address spreads quickly.
• Update client: the one built into the router.

The rule: the WAN address must sit outside the four blocks in the table above. The update client republishes the record as soon as the WAN address differs from the published one. Answers already cached on other machines keep the old address until the record's TTL runs out.

The arithmetic:

1. Address check. 203.0.113.45 sits outside 10.0.0.0 to 10.255.255.255, outside 172.16.0.0 to 172.31.255.255, outside 192.168.0.0 to 192.168.255.255, and outside 100.64.0.0 to 100.127.255.255. The site holds a public address, so an incoming path is possible.
2. Staleness bound. A name resolved just before an address change can keep answering with the old address until its TTL expires: 300 seconds ÷ 60 = 5 minutes. That is the worst window. A connection that does a fresh lookup after the client's update lands on the new address at once.
3. Frequency. With a 24 hour lease, a renewal usually re-awards the same address. Changes tend to follow a router reboot, an outage or a provider swap, so the 5 minute window opens occasionally, not on a schedule.

Result: the hostname tracks the site within 5 minutes of any change, and the site can accept incoming connections.

Decision: run the update client on the router and reach the panel through a VPN on the router. Forward TCP 443 to the panel's reserved address only when there is no VPN and the web page is the only thing needed. The stopping threshold stays the table above: an address inside any of the four blocks ends the plan here.

VPN first, one forwarded port second

A VPN terminates on the router or a small gateway at the site. It gives you a route into the LAN without exposing the panel to the internet. A WireGuard-style tunnel listens on UDP 51820 by default, so the site opens exactly one UDP port. The panel's web page is then opened through the tunnel with its ordinary LAN address. The VPN router setup for remote PLC and HMI access walks through that side of the job.

Forwarding is the fallback. Forward exactly one port, the panel's documented web port, to the panel's reserved LAN address, and restrict the rule to the source addresses that need it. The panel's browser screens can start and stop a machine, so never open its web port to the whole internet as a quick test. Internet-wide scanners find open services fast.

One hostname resolves to one address, so a second site needs its own name and its own client. When panels spread across many sites all need the same kind of access, one tunnel per site on one naming pattern keeps the map readable.

Check the path from outside

Test from a connection that is genuinely outside the site. A phone on cellular data is the usual tool.

1. Resolve the hostname on the phone and compare the answer with the router's current WAN address. A match says the name is current. A mismatch says the update client is not publishing, and that gets fixed before anything else.
2. Open the path: through the tunnel, browse to the panel's LAN address; with forwarding, browse to the hostname and its port.
3. Record what happens: page loads, timeout, or refusal. A timeout with a matching name points at a closed path. The name itself is doing its job.

An inside test can mislead, because routers handle connections to their own forwarded ports in different ways. A page that loads from the office floor says little about the path from town. When the outside test times out, work through remote HMI access times out away from town in this order: address public, name current, rule pointed at the panel's reserved address, panel web service enabled, tunnel up.

Recommendation: Put the dynamic DNS update client on the router, reserve the panel's LAN address outside the DHCP pool, and reach the panel through a VPN terminated at the site with one UDP port open. Forward the panel's single documented web port only when the site holds a real public address and no VPN is possible, and restrict that rule to the source addresses that need it. If the WAN address sits in a private or shared-carrier block, skip forwarding entirely: get a public address from the provider or dial a tunnel out to a server that holds one.

Questions