OpenVPN / OpenVPN/openvpn3

macOS needs admin/sudo for ovpncli and cannot run ovpncliagent with ovpnagent from /Applications/OpenVPN Connect.app due to OVPNAGENT_NAME_STRING discrepancy

Open
#310 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
1.2k
Forks
467
PR merge metrics
No merged PRs in 30d

Description

Hello,

I am working on a script for our devops team that will allow us to connect to openvpn from the command line and authenticate using SSO.

tl;dr: is there a way to compile the ovpnagent server alongside the ovpncli and ovpncliagent clients on macOS? There is a discrepancy between the OVPNAGENT_NAME_STRING in the OpenVPN Connect.app ovpnagent (agent_ovpnconnect.sock) and the one that ovpncliagent (ovpnagent.sock) from openvpn3 expects.


For some background, we are using macOS 14.5 and have installed:

  • the commercial OpenVPN connect app Version 3.4.9 (4830) with /Library/Frameworks/OpenVPNConnect.framework/Versions/Current/usr/sbin/ovpnagent OpenVPN Agent (Mac) 0.1.1 [OpenSSL]
    • we would like to delete the OpenVPN connect app since it is written using Electron and bloats its .app size to 241.5MB
  • openvpn2 OpenVPN 2.6.10 command line client from homebrew
    • we are unable to use this at all since it does not seem to support the --sso-methods command line argument
  • openvpn3 OpenVPN cli 1.0/OpenVPN core 3.9_git:master mac arm64 64-bit command line client (as described in the README.rst of this repo) since it does not exist as a formula in homebrew

Ideally, we only want to have openvpn3 installed and used from the command line, but have run into a couple of issues:

  1. ./ovpncli ~/profile.ovpn --sso-methods openurl,webauth,crtext --auto-sess --auth-retry --persist-tun --timeout=-1 does not work due to the following errors:

# TUN Error: utun_error: cannot open available utun device
# EVENT: TUN_IFACE_CREATE utun_error: cannot open available utun device

  1. sudo ./ovpncli ~/profile.ovpn --sso-methods openurl,webauth,crtext --auto-sess --auth-retry --persist-tun --timeout=-1 works as expected and fixes the issue described in 1), but, ideally, we don't want engineers to have to type their sudo password every day when they connect, so we then tried using the ovpncliagent which does not require administrator privileges since it taps into the ovpnagent which is started on login from the root user.

See:

  1. ./ovpncliagent ~/profile.ovpn --sso-methods openurl,webauth,crtext --auto-sess --auth-retry --persist-tun --timeout=-1 fails due to error

Transport Error: socket_protect error (UDP)
Client terminated, restarting in 2000 ms...
EVENT: RECONNECTING
Contacting via UDP
EVENT: WAIT
UnixCommandAgent: transmitting bypass route to /var/run/ovpnagent.sock
{
"host" : "",
"ipv6" : false,
"pid" : 1605
}

From the issue linked below, it seems like the above error seems to occur when the ovpnagent from the commercial OpenVPN connect app is not running, but macOS begins this process for us automatically at login, so that's not our problem. I also tried manually terminating ovpnagent and then running sudo /Library/Frameworks/OpenVPNConnect.framework/Versions/Current/usr/sbin/ovpnagent, but that leads to the same issue as described above.

See:


Something interesting I noticed is that the OpenVPN connect app Version 3.4.9 ovpnagent uses

  • HTTP Listen: http-listen /var/run/agent_ovpnconnect.sock UnixStream 1

While the openvpn3 uses

  • UnixCommandAgent: transmitting bypass route to /var/run/ovpnagent.sock

Perhaps the discrepancy here is the fact that openvpn3 uses /var/run/ovpnagent.sock and the OpenVPN Connect.app ovpnagent uses /var/run/agent_ovpnconnect.sock? I think this might be the problem which is preventing the ovpncliagent compiled from this project to work correctly.

$ stat /var/run/agent_ovpnconnect.sock
16777234 164137969 srwxrwxrwx 1 root daemon 0 0 "May 21 11:03:20 2024" "May 21 11:03:20 2024" "May 21 11:03:20 2024" "May 21 11:03:20 2024" 4096 0 0 /var/run/agent_ovpnconnect.sock

$ stat /var/run/ovpnagent.sock                                                                   
stat: /var/run/ovpnagent.sock: stat: No such file or directory

In openvpn3, this string is defined in openvpn3/openvpn/ovpnagent/mac/ovpnagent.cpp:

ret = ovpnagent("/var/run/" OVPNAGENT_NAME_STRING ".sock", logfile, append, pidfile, user, group);

It seems like the likely source of this discrepancy is that OVPNAGENT_NAME_STRING is agent_ovpnconnect in the commercial OpenVPN Connect.app and ovpnagent in this repo.

Should I be manually compiling the ovpnagent from this repo and use it alongside the ovpncliagent? As far as I can tell, the ~/src/build-openvpn3/test/ovpncli directory only includes ovpncli and ovpncliagent, which are both the clients, but not the ovpnagent http web server which comes from the OpenVPN Connect.app and runs as root on login.

It sounds like, to fix this, I will probably also need to compile the ovpnagent and add it as a launch item that is invoked by root; are there instructions for this anywhere in the repo?

Thanks!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with openvpn/ovpnagent/mac/ovpnagent.cpp and the ovpncliagent entry point, then compare the socket names shown for the commercial agent and openvpn3. Check README.rst for build guidance and determine whether the repository agent can be built and launched with these clients; done requires clear supported instructions or a confirmed explanation of the incompatibility.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, macos
Domain
cli, networking
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.