"The VPN is not working" is four different failures wearing one coat. Untangle's OpenVPN breaks in recognisable families, each with its own evidence and its own fix — here is the order that separates them without guessing, reinstalling, or changing five things at once.
Good troubleshooting is mostly refusal: refusing to change settings at random, refusing to trust the word "connected", refusing to test from the office Wi-Fi. Work the splits below in order. Each one starts with the evidence that identifies it, because in VPN problems the log line and the symptom together are worth more than any single setting.
Evidence: the client retries, times out, or reports TLS handshake failures. Translation: your packets reached nothing that answered. Work the road in order: is the server address in the config still the office's real address (the dynamic-IP failure has its own page in this series)? Is the OpenVPN app actually switched on? If the firewall sits behind the ISP's router, is UDP 1194 forwarded to it? And is the office behind CGNAT, where no inbound connection can arrive at all — check whether the firewall's WAN address matches what the internet sees. Test from a phone hotspot so the office's own network cannot confuse the result.
Evidence: Connected, an address from the VPN pool, and then silence — shares, servers and printers all unreachable. The tunnel is fine; routing and permission are not. First suspect is the Exported Networks list under the OpenVPN Server settings: clients can only reach networks the firewall exports to them, and a LAN that was never exported (or an office renumbered since) produces exactly this emptiness. Second suspect is a stale config: if anyone changed the client's group — Full Tunnel, DNS, exports — after the profile was downloaded, the laptop still runs the old instructions until it imports a fresh file; the video's own fix sequence is this lesson in action. Third: test by IP address, not by name. If 192.168.1.10 answers but the server's name does not, routing is innocent and DNS is guilty — enable Push DNS in the group and re-download.
Evidence: perfect from home, dead from a hotel, a café or one particular house. Place-dependent failures are almost never the server. A home whose LAN range matches the office LAN creates the split-brain routing described in the address-planning page. Some public and hotel networks block or mangle UDP traffic; some corporate guest networks allow almost nothing outbound. Your diagnostic friend is the hotspot test: if the same laptop connects instantly through the phone's data, the server and profile are innocent and the location's network is the culprit — full tunnel for that user, or a different network, is the practical answer.
This split decides where you stand. Everyone at once means server-side: address changed, app off, ISP event, a firewall change over the weekend. One user means their profile or device: regenerate that single client, reissue a fresh config, and check whether their certificate was the one deleted in an offboarding mix-up (it happens to the careful, too — names are similar, Fridays are long). Resist fixing a one-user problem by restarting the whole VPN service and disturbing forty working people.
Read the client log's last lines and the firewall's OpenVPN Status tab together — one shows the knock, the other shows whether the door heard it. Change one thing, retest from outside, and write down what the evidence said before and after. The moment a fix works, you will know which split it belonged to — and the next occurrence becomes a two-minute job instead of a lost afternoon. Almost every Untangle OpenVPN mystery resolves into one of these families; the rare remainder is usually a client app on the laptop itself, cured by removing the profile and importing a freshly downloaded one.
Start with the video's own repair story — the connected-but-wrong-IP fix — then keep this page as the wider map.
▶️ Watch Full VideoA DNS problem, not a tunnel problem. The route is fine; the client is asking the wrong DNS server for office names. Enable Push DNS in the client's group, download a fresh config, and reconnect.
In OpenVPN Connect, open the profile's log view and read the final lines after a failed attempt. Timeouts point at address or port problems, AUTH and certificate lines point at identity, and a clean Connected followed by silence points at routes, exports or DNS.
Server side, in this order: did the office public IP change, is the OpenVPN app still on, and did anything change on the ISP router in front of the firewall. Whole-office failures are almost never forty laptops failing together by coincidence.