Tuesday, 16 December 2014

Allow non admin users to connect with OpenVPN client

On Windows OpenVPN creates VPN tunnels and then changes the routes to send all relevant traffic down the tunnel. This is a problem for normal user accounts which do not have permissions to change the routes. Even when a user is given this permission, processes they invoke are not granted this permission by default. The easiest way around this is to make the user an administrator on their machine and set the OpenVPN-Gui shortcut to run as an administrator - however this then gives the user account full admin access to the machine. Not something that is a good idea in many situations.

Most of the guides I found on the internet seemed to be geared towards people who had admin rights and just wanted to avoid the UAC prompt.

A workaround to this that allows "normal" users to use the OpenVPN clinet on Windows without disabling UAC or similar is described below:

First log in with an account that has admin rights and open a command prompt as an administrator. Give the user account permission to edit network settings by adding them to the "Network Configuration Operators" group:
net localgroup "Network Configuration Operators" <username> /add
Next we need to allow this user account to be used for batch services so that scheduled tasks in their name will run. Go to Start -> Run and type "gpedit.msc" then hit enter. Browse to the following entry and add the username of the VPN user.
Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Log on as a batch job 
Finally create a task to start the VPN GUI shortly after the user logs on to the computer by opening "Task Scheduler" (Start -> Run -> taskschd.msc) and selecting "Create a task". This is the step that pulls the solution together as in scheduled tasks you can control the permissions that a task is run with, plus you can automate the startup.

  1. General Tab
    1. Name - Set to OpenVPN
    2. When running the task, use the following user account - set to the user who will be using the VPN
    3. Run only when user is logged in - select this
    4. Run with highest Privileges - select this
  2. Triggers Tab
    1. New Trigger
    2. Begin Task - At log on
    3. Specific User - Set to user who will be using VPN
    4. Delay task for - set to 30 seconds
  3. Actions Tab
    1. New Action, Start a program
    2. Browse to c:\program files\openvpn\bin\openvpn-gui
  4. Conditions Tab
    1. Start the task only if the computer is on AC power - DESELECT THIS or the VPN will only be available when laptop is plugged in
  5. Settings Tab
    1. No changes from defaults

Now test the connection by logging in as the user. The VPN client should automatically start in the system tray shortly after the user logs in and they should be able to bring up the VPN tunnel and access resources over it.

This guide was written based on a Windows 8.1 Pro laptop - it should also apply to Windows 7 but some of the screens might be slightly different. It was based partly on the more advanced solution at http://community.openvpn.net/openvpn/wiki/Nonprivileged - that will automatically do all the above for any user that logs on so is great for a machine many users could use, or an auto deployment system. As a one off for a single user it is more complicated than required though and the 3 steps above have the same end result.


  1. Hi

    I try your procedure but still a UAC prompt

    I've created a GPO to create this :
    > restricted group : "Network Configuration Operators" for my test user
    > Add logon as Batch for my test user
    > create schedule task
    >> IdUtilisateur %LogonDomain%\%LogonUser%
    >> Run with highest Privileges HighestAvailable
    >> Program/script c:\program files\openvpn\bin\openvpn-gui.exe
    >> i did not set a trigger, user will run manually

  2. OpenVPN can run on both UDP port and TCP, meaning that it combines HHTP over SSL as its de facto transmission model, making it nearly impossible to block.

  3. This works very well. I used these instructions to set up some remote employees with vpn access while having regular non-admin accounts. Well done.

  4. Thank you very much!
    Excelent guide!
    Works fine!

  5. I just tried it now, and it worked like charm (without the Scheduled task part) the app does not need to leverage permissions to work, I just had to add the route manually to the remote site


  6. I forgot to thank you, so THANK YOU


  7. Excellent!!! I tested with FortiGate Client VPN and worked perfectly.

  8. Kudos to Neal Harrington, the force is strong with this one! Works great under Win10. I had to change the "Network Configuration Operators" from the first step to "Netzwerkkonfigurations-Operatoren" because of the german localization in my OS. Thank you!

  9. Works perfectly. Thank you very much!

  10. Many thanks to you Neal Harrington. Believe me or not I've spent 6 months finding this solution. After googling and trying several non-working solutions like using ovpn as a service, run-as, scheduled tasks with high privileges and others and none worked for me. So I used a work-around solution by adding static routes to avoid starting ovpn gui with admin prev. It somehow soled the problem and worked fine before I changed the network configuration. Now we need to get access to the LAN IPs behind the PCs connected to this VPN. After I shared internet of the ovpn interface and assigned static IP addresses to it this ovpn-TAP-windows bug (there's information about this bug) started to bother me. The ovpn connection could start or not start (mostly not) depending on the "bug decision". After adding some strings to the ovpn configuration file it fixed the problem but I faced the "old issue" with running ovpn gui with admin privs. So finally I found your solution. I might look like not a high-class Windows admin which I'm actually not, but anyway thank you again. Alexander Golovanov