Same app, two very different jobs. One connects a person; the other connects a building. Untangle's OpenVPN does both — here is how each is built, the one addressing rule that decides success, and how to know which one your situation actually needs.
A remote-user VPN ends on a laptop: one person runs OpenVPN Connect, imports a profile, and works. A site-to-site VPN ends on a second firewall: the tunnel is always on, nobody imports anything, and every PC at the branch can reach head-office resources as if a very long cable joined the two buildings. Untangle's OpenVPN app supports both from the same Server tab — the difference is in how you create and deliver the client.
On the head-office firewall you create the branch as a Remote Client, like a user — but when you download its configuration you choose the ZIP file option, because a firewall needs the full set of files, not a single import profile. On the branch firewall you go to Apps → OpenVPN → Client and use Upload Remote Server Configuration File to load that ZIP. From there the tunnel connects automatically and stays up on its own; Arista's own guide describes exactly this flow. The branch firewall then routes its LAN's traffic for head-office addresses down the tunnel.
Both offices cannot use the same LAN range. If head office and branch are both 192.168.1.0/24 — the default on half the routers ever sold — a branch PC asking for 192.168.1.20 cannot know whether that machine is down the hall or across the city, and routing falls apart in confusing, half-working ways. Before building any site-to-site tunnel, renumber one office to a distinct range (head office 192.168.1.0/24, branch 192.168.2.0/24, or move both to a planned scheme like 10.10.1.0/24 and 10.10.2.0/24). This renumbering is dull, unglamorous, and responsible for more failed site-to-site projects than the VPN itself.
Remote-user access is personal and temporary: it exists when the person connects, follows them to any network, and dies with their profile when they leave. Site-to-site is infrastructure: branch printers, the branch's access to the head-office server and Tally data, shared drives — all simply work for everyone at the branch, all day, with nothing to launch. The flip side is behaviour when things break: a down site-to-site tunnel is a branch-wide outage until it reconnects, while a remote user's problem is one person's problem.
One product detail worth knowing: Arista notes the Full Tunnel option cannot be used for site-to-site connections — the tunnel carries traffic between the two networks, which is the split model by nature.
One or two people working from home or the road: remote-user profiles, exactly as the video builds. A second office with its own PCs that must reach head-office systems every day: site-to-site, provided both ends run a firewall that can hold the tunnel — in this app's upload flow, that means another NG Firewall. Plenty of real businesses run both: the branch joined site-to-site, and the owner still holding a personal profile for home. What does not work is stretching remote-user profiles into a fake branch solution — a shared laptop profile at a branch is the shared-key trap wearing a bigger coat.
The video's client creation is step one of both models — watch it, then decide which delivery the new client is for.
▶️ Watch Full VideoNo. In a site-to-site setup the branch firewall itself holds the tunnel and routes for the whole branch LAN. Individual PCs just use the network normally; head-office addresses simply answer.
The ZIP upload flow in this app is designed for another NG Firewall. A generic OpenVPN client elsewhere can connect as a remote client, but clean two-network routing needs care on both ends — keep both ends on the same platform if you want the simple path.
Not reliably. Renumber one office's LAN to a different private range first. This single preparation step decides whether a site-to-site project takes an afternoon or a month.