The tunnel says connected, the handshake even looks fine — yet no office files, or no internet at all. This is the most reported WireGuard problem, and it splits cleanly in two once you know where to look.
Before you change a single setting, learn the ten-second diagnosis in the panel above. No handshake and handshake-but-no-access have almost no causes in common, and the fixes live in different places — one out on the internet path, the other inside the firewall's rules, the very rules the setup video configures. Work your family, in order.
Illustrative panel — the client's handshake and transfer lines are the first diagnostic. Always separate 'no handshake' from 'handshake but no access'.
"The VPN connects but nothing works" is two different failures wearing one coat. Open the client and look at latest handshake and transfer:
Every fix below belongs to one of these two families. Guessing across families is how evenings disappear.
This is the step the setup video deliberately spends time on, and the one first-time setups skip. A fresh tunnel on the Untangle app authenticates the device — it does not automatically grant it the whole office. Go back to Apps → WireGuard VPN and review the network access rules and the firewall and routing rules for VPN clients: the tunnel's traffic must be allowed to the LAN subnet and the servers that person uses. Save, then test again. When the handshake was already fine, this fixes the large majority of "connected but useless" reports.
If office resources open but websites do not, and the client is set to full tunnel (AllowedIPs = 0.0.0.0/0), the tunnel is asking the office to carry all internet traffic. Two usual suspects: the firewall is not forwarding/NAT-ing VPN-client traffic out to the internet (on the Untangle route this follows from the same access and routing rules — recheck them), and DNS — the client config should carry a DNS server it can actually reach through the tunnel, typically the firewall/LAN DNS. Setting DNS to a server that only exists on the client's home network makes every website look "down" while the tunnel is perfectly healthy.
Rewatch the access-rules part of the setup video alongside Fix 3 — it is the step that decides whether a connected tunnel can actually reach anything.
▶️ Watch Full VideoMost often, the public IP. On a dynamic connection the firewall's outside address changes, and the client config still points at the old one — you get exactly this: no handshake. A DDNS hostname in the endpoint, updated by the router or firewall, ends this class of failure permanently.
Compare, do not guess. The phone succeeding proves the server, port and internet path are fine — so the laptop's problem is its own config: an old imported file, a mistyped key from a manual edit, or its AllowedIPs/DNS lines. Re-import a fresh config from the tunnel's Remote Client view before deeper surgery.
Yes, and it is often the fastest honest fix for one broken client: delete the tunnel on the firewall, create a new one, import the fresh config. You lose nothing — the tunnel holds no data. Just make sure the old config is removed from the client too, so nobody activates the dead one by habit.