Nothing was changed. Nobody touched the firewall. And on a random Tuesday the VPN simply stopped for the whole office. When every user breaks at the same time with no change on your side, suspect the address — here is the diagnosis and the permanent fix.
The video builds on a static public IP, and this failure is exactly why that choice matters. Most small-business internet plans hand out a dynamic public IP that the ISP may change after a router reboot, a maintenance window, or nothing visible at all. Every Untangle client config carries the server address from the day it was generated. When the office's number changes, every client in the world is still knocking on the old number — politely, persistently, and forever.
Two quick checks separate an address change from every other failure. First: did everyone break at once? One broken user is a profile problem; the whole office at the same hour is infrastructure. Second: compare addresses. From inside the office, look at the firewall's current WAN address (Config → Network → Interfaces) and compare it with the address inside any client config file, or with what your DDNS name resolves to. Different numbers: diagnosis done. Also note the client's error style — a timeout (silence) means "nothing answered at that address", while an instant refusal or certificate error means something answered but rejected you, which is a different disease entirely.
Untangle includes a Dynamic DNS service (Config → Network → Dynamic DNS): you pick a hostname from a supported provider, the firewall keeps that name pointed at whatever public IP it currently holds, updating it automatically when the number changes. Then set that same hostname under Config → Administration → Public Address — this is the value written into generated client configs — and download fresh config files for everyone. From then on, clients dial a name, and the name quietly tracks every future change. The one-time cost is an afternoon of resending profiles; the benefit is that this entire failure class never recurs.
Before celebrating, check one thing: is your "public" IP actually public? Some ISPs place customers behind carrier-grade NAT, where the address on your firewall's WAN is itself a private or shared address (you may see 100.64.x.x, or the WAN shows a 192.168.x.x from the ISP's own router). In that world no inbound connection can ever reach you — not with DDNS, not with port forwarding, not with prayer — because the internet cannot route to a shared address. DDNS would happily name the wrong, shared doorway. The only real cure is asking the ISP for a genuine public IP (many sell a static IP add-on, which solves this and the dynamic problem in one stroke). Compare the firewall's WAN address with what a "what is my IP" site shows from the office: if they differ, you are behind another NAT layer — find out whose.
If the office depends on VPN daily — Tally, accounts, the owner's evening work — a static public IP from the ISP is cheap insurance and the option the video's setup is built on. It removes the dynamic problem entirely and gives banks, government portals and allow-listed services a stable address to trust. Choose dynamic-plus-DDNS when budgets demand it and the setup is small; choose static the moment VPN downtime starts costing real work. Either way, after any address change — ISP migration, new router, plan change — regenerate configs, resend them, and test from a phone hotspot before calling it done.
Watch the video's Network check at the start of the setup — that one glance at the static IP is the step this entire failure grows out of skipping.
▶️ Watch Full VideoCompare the firewall's current WAN address with the address or hostname your client configs use. If the config holds an old number while the firewall sits on a new one, that is your failure. Everyone breaking simultaneously is the other big clue.
The firewall has a built-in Dynamic DNS client under Config, Network, Dynamic DNS, supporting a range of providers; several providers offer free hostnames, and paid tiers exist. Any of them works — the mechanism matters more than the brand.
No. DDNS only names an address — if that address is a shared carrier address, inbound connections still cannot reach you. You need a real public IP from the ISP; a static IP add-on is usually the simplest way to get one.