Portable VPN Client Without Admin Rights: What Still Breaks

Portable describes the installer, not the kernel. A client can arrive as one executable on a USB stick and still need a tunnel device, a route table entry and a resolver write before the first packet moves. Which of those three the target machine will let you touch decides whether that build works there at all. The probes below answer the question in the order the client will hit them.

Portable covers three different promises, and only one is free

No installer means the vendor did not register a service, ship an uninstaller or add a menu entry. No administrator means an ordinary account can start the client and finish a connection. No host change means the machine looks identical after you quit. Download pages that say portable usually promise only the first of those, and the other two are where deployments fail. A build can also be portable in the narrow sense that it runs from read-only media with no dotfile writes at all, which still says nothing about the network stack.

The expensive promises are the second and the third. A single executable that needs an adapter, a route or a resolver write is asking the operating system for authority the portable label never covered.

Find the privileged helper the client will call

Almost no VPN client moves packets by itself. On Windows the data path runs through WFP filters and the Base Filtering Engine, on macOS through a NetworkExtension provider the user approves in System Settings, and on Linux through a tun device plus the routing stack. The binary you copied is a control surface for those components, not a substitute for them. Ask which component the client expects, then confirm that it is installed, running and usable by your account.

Linux is the easiest place to prove the point because the check is one syscall. Opening /dev/net/tun and asking the kernel for a device requires CAP_NET_ADMIN, and the kernel TUN/TAP documentation states both the ownership rule and the capability. Run the probe as the account that will launch the client, not as root.

ls -l /dev/net/tun
ip tuntap add dev vpntest mode tun
ip link delete vpntest

A permission error on the middle line is the answer you were looking for: this account cannot create a tunnel interface, so any userspace client that needs one fails at connect time rather than at download time. The last line removes the test device and prints nothing when it works. If both lines succeed, the host changed nothing permanent.

Test route and resolver changes before the first connect

Split tunnelling turns a connection into a routing decision, while a full tunnel turns it into a default route replacement. Both are writes to the host network stack, and both fail for an unprivileged account even when the client itself starts cleanly. The resolver is the third write, and on systemd hosts it is usually the one that breaks last. That ordering matters when you are deciding where to spend an elevated install.

A route probe needs a destination you actually care about, so substitute a subnet from your own profile instead of the placeholder below. The device name has to exist for the route to attach to anything.

ip route add 10.20.0.0/16 dev vpntest
ip route del 10.20.0.0/16
resolvectl query intranet.example.internal

The first line returning RTNETLINK answers: Operation not permitted means the account cannot install the private route the profile requires. The second line proves the same right in reverse, which matters because a client that can add routes but not remove them leaves a broken table behind. The resolver query then shows whether private names resolve through the tunnel or leak to whatever resolver the host already trusts.

Run all three while the test device still exists, then delete it. A route pointing at a device that is gone is the most common reason a laptop loses connectivity after a failed connect.

Decide what has to survive the session

Deleting the folder is not a cleanup plan. Adapters, routes, resolver settings, trusted certificates and stored credentials can each outlive the process, and a boot-time service may restore some of them without asking. Write down what the client is allowed to leave behind before you run it, not after the first failed disconnect.

The practical rule is to snapshot the three surfaces you are about to change and compare them afterwards. Record interfaces, the main routing table and the resolver state before the first connect, then repeat the same three reads once the client has exited.

ip -brief addr show
ip route show table main
resolvectl status

Anything present in the second capture and absent from the first needs an owner. Either the client removes it on exit, or you remove it with the same commands that created it, and that removal belongs in the deployment notes rather than in someone memory of what happened. On Windows the equivalent reads are Get-NetAdapter, Get-NetRoute and Get-DnsClientServerAddress, which need no elevation but show the same leftovers.