Remote Access Stopped Working After Router Restart
It worked for months. Then one power cut, one router restart — and from home, the office PC simply does not exist anymore. Nothing broke. Three addresses changed at once, and each one can stop you.
✍️ Technical Anshu🪟 Windows 10 / 11⏱️ 6 minute read
🎥 Watch the full video — the Tailscale setup that survives every restart, shown live
A router restart on a dynamic-IP connection quietly reshuffles three different addresses: the office gets a new public IP from the ISP, the office PC may get a new LAN IP from the router, and your DDNS name needs time to catch up. A traditional port-forwarding setup depends on all three staying put, which is why it feels haunted — it works for weeks, then dies overnight without anyone touching a setting. Work through the three in order and you will find your fault in minutes.
What Changed Overnight — Address Checklist
Public IP saved in your RDP shortcut182.68.44.21
Public IP the office has this morning117.203.88.140CHANGED
Forwarding rule points to LAN IP192.168.1.105
Office PC LAN IP after restart192.168.1.112CHANGED
☝️ The two silent changes that kill most remote access setups after a restart — neither sends you any warning
1
First Suspect — Your Public IP Changed
If you connect by typing an IP address directly, that address is almost certainly stale. On a dynamic connection the ISP reassigns it at most reconnects
Ask someone at the office to open a browser and search what is my IP, then try connecting to the new number
If it connects, you found the fault — and also the reason it will keep happening. Move to a DDNS name, or better, to a method with a permanent address (Fix 4)
Never share the new IP by saving it in fresh shortcuts everywhere. That just rebuilds the same trap for the next restart
2
Second Suspect — the Office PC Got a New LAN IP
This is the one most people miss, because it hides inside the office where everything looks normal.
The router gives LAN addresses by DHCP. After a restart, the office PC can easily receive a different one than before
Your port forwarding rule still points at the old LAN IP — so incoming connections are delivered to an empty address, or worse, to another device entirely
On the office PC, run ipconfig and compare its IPv4 address with the target in the forwarding rule
Fix it permanently with a DHCP reservation in the router — bind the office PC's MAC address to one fixed LAN IP, so a restart can never move it again
3
Third Suspect — DDNS and Caches Are Still Catching Up
If you connect by DDNS name, give the updater time — after an IP change the name can hold the old address for several minutes, and your home PC may cache it even longer
Check what the name holds right now with ping yourhostname and compare it with the office's real public IP
Clear your home PC's cache with ipconfig /flushdns and test again, ideally from mobile data
Also confirm the office PC itself finished waking up — a PC still installing updates or sitting at a login prompt after the power returned can look identical to a network failure
4
The Permanent Fix — an Address That Never Changes ⭐
Every fault above exists because the system is built on addresses that move. The method in the video removes all three moving parts at once.
Install Tailscale on the office PC and the home device, signed in to the same account
The office PC gets a permanent 100.x Tailscale address that survives router restarts, ISP changes and even a different connection altogether
No port forwarding means no forwarding rule to point at the wrong LAN IP — so the second suspect disappears too
After the next power cut, the office PC simply comes back online in your Tailscale machine list, and you connect exactly as before
⚠️ While you are fixing this, fix the exposure too. If the old setup reached the office by forwarding port 3389, the restart did not make you safer — that port was visible to the whole internet the entire time it worked. Moving the same PC behind Tailscale and deleting the forwarding rule closes that door for good.
🎥 Watch the Restart-Proof Setup in the Full Video
The video builds the Tailscale connection end to end — the same one that does not care how many times the router restarts.
Why did it break on a restart when I changed nothing?
Because on a dynamic connection, a restart is itself a change. The ISP session is rebuilt and usually given a new public IP, and the router rebuilds its DHCP table, which can hand your office PC a new LAN address. Your settings stayed identical — the addresses underneath them moved.
Will buying a static IP stop this problem completely?
It removes the first suspect — the public IP never changes. But the office PC can still get a new LAN IP and break the forwarding rule, so reserve its LAN address in the router as well. And a static IP with an open RDP port is a permanent, unchanging target for attackers, which is why a private mesh network is the safer long-term answer.
How can I check quickly whether it is the public IP or the LAN IP that changed?
From home, ping your DDNS name or check your current public IP against the saved one. Then ask the office to run ipconfig on the target PC and compare with the forwarding rule. One of the two comparisons will disagree — that is your fault, and it takes under five minutes.
This guide is based on the Technical Anshu no static IP remote access video • Stuck on any step? Ask in the video comments — help is available there 🙏