The little .ovpn file Untangle gives you is not a settings file — it is a working key to your office network. This page shows what is inside it, how to hand it over without being careless, and how to make one specific key stop working the day you need it to.
Every remote-access horror story in a small office starts the same way: a file sent too casually, copied too widely, or still working long after it should have died. Untangle's design is actually on your side — each client gets its own config with its own certificate — but the design only protects you if you handle the files like what they are: keys.
Open a downloaded .ovpn in a text editor once, just to learn respect for it. You will find the server address and port at the top, then three wrapped blocks: the certificate authority, the client's certificate, and the client's private key. That combination is a complete credential. The OpenVPN client does not ask the file any questions — anyone who imports it into OpenVPN Connect, on any machine in the world, presents themselves to your firewall as that user.
This is also why the video's flow — download, import, connect, done — works without anyone typing a password. Convenience and risk are the same feature here.
Name files after person plus device — priya-laptop, priya-phone — never office-vpn.ovpn. Deliver the file in person on the actual device when you can; when you cannot, use a channel you would trust with a banking password, import it together on a call, and delete the transfer copies afterwards — the one inside the OpenVPN app is the working copy, the ones sitting in Downloads folders and chat histories are pure extra risk. Never post a profile in a team group chat or a shared drive "for convenience": convenience copies have a way of outliving the employee.
If your setup also has username-and-password sign-in turned on, that is a genuine second lock — use it for anyone working from a personal machine.
Do not waste the first hour hoping the laptop turns up. The fix lives on the firewall, not the device:
Notice what made this painless: the profile belonged to one person and one device. This is the payoff of the per-user discipline from the setup guide.
The most common small-office shortcut is one profile — "office" — installed on every laptop. It feels efficient until the first bad day: you cannot tell who connected (the logs show one name), you cannot remove one person's access (the key is everywhere), and the day someone leaves, the only complete fix is reissuing profiles to the entire office at once. If your Remote Clients list currently shows a shared profile, treat migrating to per-person clients as this month's job, not someday's.
Keep a one-line register — name, device, date issued — next to your other IT notes; the Remote Clients list itself mostly serves as this register if names are disciplined. Review the list every few months and delete clients for people and machines that no longer exist; stale profiles are doors nobody remembers installing. And protect the devices themselves: a laptop with a login password and disk encryption turns a lost profile from an incident into an errand, because the thief still has to get past the machine before the key is usable.
Watch the video's download-and-import sequence again with this page in mind — you will see the exact moment the key changes hands.
▶️ Watch Full VideoTechnically it will often connect, and that is exactly the problem. A shared file destroys accountability — logs cannot tell who connected — and makes revocation all-or-nothing. Always create one client per person and device in the Remote Clients list.
Not automatically, but the risk window is real: mailboxes get forwarded, synced and searched. The clean response is to delete that client on the firewall, issue a fresh one under a new name, and deliver it by a safer route. The old file then connects to nothing.
No. Revocation happens only on the firewall, by deleting or disabling the client in the Remote Clients list. Deleting local copies is hygiene; the firewall is the lock.