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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to