Hi, > > I am running OpenVPN on Windows using NSSM wrapper for years. I had a > brief discussion on the Hackathon with Samuli about integrating SCM > support directly into openvpn.exe (imagine --daemon for Windows): > > > > sc create OpenVPN$MyTunnel binpath= "C:\Program > > Files\OpenVPN\bin\openvpn" --daemon --config "C:\Program > > Files\OpenVPN\config\MyTunnel.ovpn" --log "C:\Program > > Files\OpenVPN\log\MyTunnel.log" start= auto depend= dhcp sc start > > OpenVPN$MyTunnel > > > > This would install openvpn.exe as a Windows service and run it as the > SYSTEM user — no need for iservice, no need for SYSTEM token hack. Other > than me, perhaps it could cover at least some of the users now running > openvpn.exe directly. > > This is not the direction I want to see us moving towards. Instead I > want to see us daemonizing OpenVPN.exe as LOCAL SERVICE or a custom > service user and delegate privileged operations to a separate service > running as SYSTEM. And we already have the latter: interactive service. > So, not even admin rights is needed in openvpn.exe, let alone SYSTEM. > > IMO, the right approach on Windows is to run a bare minimal code as a > service to get SYSTEM rights and the rest with limited privileges.
Selva, those are two different use-cases. And none is "right" or "wrong". OpenVPN can or should have both. :) 1. I need to run VPN tunnel as a persistent service - something that comes up with computer (Group Policy Client service waits for about 30 seconds on boot to get network access to AD server). And stays on all the time - any user signed in or not. I connect computers with VPN. 2. You need an openvpn.exe (or introduce some openvpn-tui.exe) to be a command line version of openvpn-gui.exe. Something to be run by a regular user or a batch script in an unprivileged context. You connect users with VPN. If we implement both, we can obsolete SYSTEM token hack completely. I have been playing with Lev's patches for the past few days. Tested them, debugged them, did some fixes. There are things to be desired like netsh=>ipcfg, remove or #ifdef the SYSTEM token hack... But those are design choices we should pursue in the future. I believe patches are mature enough to ack them. They should be merged into master to provide wider testing and easier development progress. Regards, Simon
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel