Menu
▾
▴
openvpn-users
|
From: Németh T. N. <nem...@ny...> - 2016-03-04 11:35:18
|
Dear OpenVPN users! I've read that it's not possible to run OpenVPN on Windows from a non-admin user account: https://openvpn.net/index.php/open-source/faq/79-client/275-why-cant-i-run-openvpn-on-windows-from-a-non-admin-user-account.html I've also read that there are some workarounds for Windows. However, I think the real solution would be to split OpenVPN's functionality to a background daemon running with administrative rights and a distinct GUI application which controls the former process via some interprocess communication facility. OpenVPN works this way on my NetworkManager/DBus based linux desktop machine. Why isn't it possible on Windows? Or are you aware of any OpenVPN compatible client program for Windows which is structured this way, thus eliminating OpenVPN difficulties in the enterprise environment? Thank you in advance, Tamás Németh IT sysadmin University of West Hungary, Sopron |
|
From: Samuli S. <sa...@op...> - 2016-03-04 12:11:52
|
Hi, This issue has been fixed recently: it is possible to run OpenVPN as a non-admin user in Windows. We have Git snapshot builds for Windows here: <http://build.openvpn.net/downloads/snapshots/> However, those builds do not (yet) contain a recent enough OpenVPN-GUI. In fact, a lot has been happening on the OpenVPN-GUI side recently: <https://github.com/OpenVPN/openvpn-gui> A while back created a test build that should work as non-admin just fine: <http://build.openvpn.net/downloads/temp/openvpn-install-2.3_guipr18and20-I606-x86_64.exe> Note that the user has to be in the "Administrators" group[1], or in a special "OpenVPN Administrators" group to be allowed to connect. You will also need to ensure that that "OpenVPNServiceInteractive" is running. For example in Powershell you'd do Start-Service OpenVPNServiceInteractive Best regards, -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock [1] Note that if your Windows is non-English, this does not work. This is being worked on. > Dear OpenVPN users! > > I've read that it's not possible to run OpenVPN on Windows from a non-admin > user account: https://openvpn.net/index.php/open-source/faq/79-client/275-why-cant-i-run-openvpn-on-windows-from-a-non-admin-user-account.html > > I've also read that there are some workarounds for Windows. However, I think > the real solution would be to split OpenVPN's functionality to a background > daemon running with administrative rights and a distinct GUI application which > controls the former process via some interprocess communication facility. > OpenVPN works this way on my NetworkManager/DBus based linux desktop machine. > Why isn't it possible on Windows? Or are you aware of any OpenVPN compatible > client program for Windows which is structured this way, thus eliminating > OpenVPN difficulties in the enterprise environment? > > Thank you in advance, > > Tamás Németh > IT sysadmin > University of West Hungary, Sopron > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > Openvpn-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-users > |
|
From: Németh T. N. <nem...@ny...> - 2016-03-05 10:51:45
|
>> Hi, >> >> On Thu, Mar 03, 2016 at 02:06:30PM +0200, Samuli Seppänen wrote: >>> Do we want let any non-admin user on a system launch OpenVPN connections >>> by default? Or do we want the administrator of the system to >>> specifically grant permissions to OpenVPN to each non-admin user? >> >> I think this needs to be a question the installer asks. > >Sounds reasonable. Any other opinions? Well, what if there would be a checkbox in the installer labeled with something like "Only members of this group are allowed to use OpenVPN:" and then a dropdown list of local(?) Windows groups. One of the listed groups migh be "OpenVPN Users - TO BE CREATED" or something like this (assuming that this group hadn't been created before installation) and if chosen, the installer should create this group. Indirect group membership should be checked and anyone running OpenVPN GUI but not allowed to connect should be constantly warned about his/her insufficient permissions. In addition to this OpenVPN should handle both "systemwide" and "personal" VPN profiles. Systemwide profiles should only be created and edited by system admins, but everyone should be able to create and edit his/her own profiles stored somewhere in her/his own user profile, even despite not being able to instruct OpenVPN to connect using these profiles. With respect, Tamás Németh IT sysadmin University of West Hungary, Sopron |
|
From: David S. <op...@sf...> - 2016-03-05 12:35:23
|
On 05/03/16 11:35, Németh Tamás NET wrote: >>> Hi, >>> >>> On Thu, Mar 03, 2016 at 02:06:30PM +0200, Samuli Seppänen wrote: >>>> Do we want let any non-admin user on a system launch OpenVPN connections >>>> by default? Or do we want the administrator of the system to >>>> specifically grant permissions to OpenVPN to each non-admin user? >>> >>> I think this needs to be a question the installer asks. >> >> Sounds reasonable. Any other opinions? > > Well, what if there would be a checkbox in the installer labeled with > something like "Only members of this group are allowed to use OpenVPN:" and > then a dropdown list of local(?) Windows groups. One of the listed groups migh > be "OpenVPN Users - TO BE CREATED" or something like this (assuming that this > group hadn't been created before installation) and if chosen, the installer > should create this group. Indirect group membership should be checked and > anyone running OpenVPN GUI but not allowed to connect should be constantly > warned about his/her insufficient permissions. I'm not convinced providing more features to the average users will help much. The installer should have the average user in mind and provide as few options as ever possible. For the more advanced use cases I would rather propose that this is a command line setting you provide to the installer. The idea is that a user (or most likely an admin) knowing more advanced features are needed should not be that much afraid of reading the needed documentation describing these command line options. We just need to highlight where the documentation can be found. And in an enterprise environment where such features are more commonly used, software installations are very commonly automated through scripts - which again gives a good advantage providing these settings via the command line. -- kind regards, David Sommerseth |
|
From: blz <blz...@gm...> - 2016-03-06 00:48:59
|
On 3/5/2016 4:35 AM, David Sommerseth wrote: > On 05/03/16 11:35, Németh Tamás NET wrote: >>>> Hi, >>>> >>>> On Thu, Mar 03, 2016 at 02:06:30PM +0200, Samuli Seppänen wrote: >>>>> Do we want let any non-admin user on a system launch OpenVPN connections >>>>> by default? Or do we want the administrator of the system to >>>>> specifically grant permissions to OpenVPN to each non-admin user? >>>> I think this needs to be a question the installer asks. >>> Sounds reasonable. Any other opinions? >> Well, what if there would be a checkbox in the installer labeled with >> something like "Only members of this group are allowed to use OpenVPN:" and >> then a dropdown list of local(?) Windows groups. One of the listed groups migh >> be "OpenVPN Users - TO BE CREATED" or something like this (assuming that this >> group hadn't been created before installation) and if chosen, the installer >> should create this group. Indirect group membership should be checked and >> anyone running OpenVPN GUI but not allowed to connect should be constantly >> warned about his/her insufficient permissions. > I'm not convinced providing more features to the average users will help much. > The installer should have the average user in mind and provide as few options > as ever possible. For the more advanced use cases I would rather propose that > this is a command line setting you provide to the installer. > > The idea is that a user (or most likely an admin) knowing more advanced > features are needed should not be that much afraid of reading the needed > documentation describing these command line options. We just need to > highlight where the documentation can be found. > > And in an enterprise environment where such features are more commonly used, > software installations are very commonly automated through scripts - which > again gives a good advantage providing these settings via the command line. Is this why some installers ask the user what sort of installation they want (e.g, "Typical", "Custom"/"Advanced", ...) ? Couldn't something like that that work here? -- blz |
|
From: Németh T. N. <nem...@ny...> - 2016-03-04 16:17:32
|
Thank you very much for your answer. > > I've read that it's not possible to run OpenVPN on Windows from a > > non-admin user account. > This issue has been fixed recently: it is possible to run OpenVPN as a > non-admin user in Windows. Have you solved it by splitting the functionality to a privileged background daemon and an unprivileged GUI as I described earlier, or by applying some other trick? > We have Git snapshot builds for Windows here: > > <http://build.openvpn.net/downloads/snapshots/> I installed the last one on Windows 10, but the GUI didn't even start :-( > However, those builds do not (yet) contain a recent enough OpenVPN-GUI. > In fact, a lot has been happening on the OpenVPN-GUI side recently: > > <https://github.com/OpenVPN/openvpn-gui> Sorry, I was not smart enough to compile this source but as soon as a binary version will be released, i will try it. > A while back created a test build that should work as non-admin just fine: > > <http://build.openvpn.net/downloads/temp/openvpn-install-2.3_guipr18and20-I606-x86_64.exe> > > Note that the user has to be in the "Administrators" group[1], or in a > special "OpenVPN Administrators" group to be allowed to connect. Am I right when I think it's almost as problematic as requiring the user to have administrative permissions as previously? According to my experiences, OpenVPN clients works extremely well and reliably on Linux and Android, and it's also a very good LAN-2-LAN solution for Windows, but it's practically unusable as a "roadwarrior" solution for Windows, as long as administrative rights are needed to run it. I'd like to replace Cisco VPN client on our Windows 10 clients with OpenVPN in an enterprise environment, but its currently impossible. I'm looking forward for the new versions mentioned by you. Many thanks, Tamás Németh IT sysadmin University of West Hungary, Sopron |
|
From: Selva N. <sel...@gm...> - 2016-03-04 16:56:15
|
On Fri, Mar 4, 2016 at 11:01 AM, Németh Tamás <nem...@ny...> wrote: > Thank you very much for your answer. > > > > I've read that it's not possible to run OpenVPN on Windows from a > > > non-admin user account. > > > This issue has been fixed recently: it is possible to run OpenVPN as a > > non-admin user in Windows. > > Have you solved it by splitting the functionality to a privileged > background > daemon and an unprivileged GUI as I described earlier, or by applying > some other trick? > > Actions that require admin privileges is now handled by a service so that openvpn can run without admin rights. The support for this in the GUI is still evolving. Although the functionality is there, error handling has to improve as well as some install time setup is required. > > A while back created a test build that should work as non-admin just > fine: > > > > < > http://build.openvpn.net/downloads/temp/openvpn-install-2.3_guipr18and20-I606-x86_64.exe > > > > > > Note that the user has to be in the "Administrators" group[1], or in a > > special "OpenVPN Administrators" group to be allowed to connect. > > Am I right when I think it's almost as problematic as requiring the user > to > have administrative permissions as previously? > Adding the user to a predefined group is a one time task which could be done at install time. As installation anyway requires admin rights, this is not really a limitation. Also note that the predefined group may be set as "Users" or its equivalent, allowing all users to run openvpn without admin privileges. Currently there is a discussion going on another thread on how the installer should handle this --- should it offer an option to add user to this group, or should all users be in this group by default etc. Feedback from system administrators would greatly help, so please weigh-in your thoughts in that thread or here. Thanks, Selva |
|
From: Selva N. <sel...@gm...> - 2016-03-04 17:16:41
|
On Fri, Mar 4, 2016 at 11:01 AM, Németh Tamás <nem...@ny...> wrote: > > A while back created a test build that should work as non-admin just > fine: > > > > < > http://build.openvpn.net/downloads/temp/openvpn-install-2.3_guipr18and20-I606-x86_64.exe > > > > > > Note that the user has to be in the "Administrators" group[1], or in a > > special "OpenVPN Administrators" group to be allowed to connect. > > Am I right when I think it's almost as problematic as requiring the user > to > have administrative permissions as previously? As Gert pointed out, this special group membership is required only for configs installed by the user in their user profile. For enterprise use, keep configs in the system-wide location and users will be able to start openvpn with no admin rights. Selva |
|
From: Selva N. <sel...@gm...> - 2016-03-05 18:23:01
|
Hi, On Sat, Mar 5, 2016 at 5:35 AM, Németh Tamás <nem...@ny...> wrote: > > > Well, what if there would be a checkbox in the installer labeled with > something like "Only members of this group are allowed to use OpenVPN:" and > then a dropdown list of local(?) Windows groups. One of the listed groups > migh > be "OpenVPN Users - TO BE CREATED" or something like this (assuming that > this > group hadn't been created before installation) and if chosen, the installer > should create this group. Indirect group membership should be checked and > anyone running OpenVPN GUI but not allowed to connect should be constantly > warned about his/her insufficient permissions. > For an average user all this is confusing, while for an admin such hand-holding is redundant. > > In addition to this OpenVPN should handle both "systemwide" and "personal" > VPN > profiles. Systemwide profiles should only be created and edited by system > admins, but everyone should be able to create and edit his/her own profiles > stored somewhere in her/his own user profile, even despite not being able > to > instruct OpenVPN to connect using these profiles. > This is already supported. At the expense of being repetitive let me briefly explain the current situation regarding the interactive service (after my restrict options/configs commit) - Configs may be stored in a system-wide location writeable only by admins, or in user's profile writeable by users - The system-wide profiles may be started by any user with or without admin privileges - User's profiles may be started by those who are either in the "Administrators" group or in "OpenVPN Administrators" group Note that these restrictions are somewhat orthogonal to what networkmanager (nm) does on linux. The rationale for that is another topic. The locations and group names referred to above may be customized in the registry -- system-wide one's in HKLM and user-changeable one's in HKCU Finally, back to "average user" of the GUI, I plan to offer a dialog to add the user to the special "OpenVPN Administrators" group when they try to start a config that would be otherwise rejected by the service. This will obviously cause UAC or password prompt and will work only if the user knows admin password. This is work in progress, any feedback will be most helpful. For all this, the only requirement at installation is to create the group " OpenVPN Administrators" which may be done without any user intervention. Any thoughts? Selva |
|
From: Németh T. N. <nem...@ny...> - 2016-03-05 23:56:01
|
Hi, So, any thougts? Yes, a few minutes after I sent my mail, I realized it's not a good idea to have a group which allows for its members to use both systemwide and personal VPN profiles, because this model does not give enough control to sysadmins and it's insecure. Your original idea of allowing everyone to use systemwide profiles and having a group which makes it possible for its members to use personal profiles is better and more secure. However, I have an additional idea, how to make this security model even more secure and fine grained: What if you add a config option to profile files which is similar to "valid users" of samba's smb.conf? This option might be mandatory in systemwide profiles and optional in personal profiles. Only users and groups listed in this option would be permitted to use the profile containing it. Tamás ________________________________ Feladó: Selva Nair <sel...@gm...> Elküldve: 2016. március 5. 19:22 Címzett: Németh Tamás NET Másolatot kap: openvpn users list (ope...@li...) Tárgy: Re: [Openvpn-users] Allowing all OpenVPN 2.4.x Windows users to run OpenVPN by default? Hi, On Sat, Mar 5, 2016 at 5:35 AM, Németh Tamás <nem...@ny...<mailto:nem...@ny...>> wrote: Well, what if there would be a checkbox in the installer labeled with something like "Only members of this group are allowed to use OpenVPN:" and then a dropdown list of local(?) Windows groups. One of the listed groups migh be "OpenVPN Users - TO BE CREATED" or something like this (assuming that this group hadn't been created before installation) and if chosen, the installer should create this group. Indirect group membership should be checked and anyone running OpenVPN GUI but not allowed to connect should be constantly warned about his/her insufficient permissions. For an average user all this is confusing, while for an admin such hand-holding is redundant. In addition to this OpenVPN should handle both "systemwide" and "personal" VPN profiles. Systemwide profiles should only be created and edited by system admins, but everyone should be able to create and edit his/her own profiles stored somewhere in her/his own user profile, even despite not being able to instruct OpenVPN to connect using these profiles. This is already supported. At the expense of being repetitive let me briefly explain the current situation regarding the interactive service (after my restrict options/configs commit) - Configs may be stored in a system-wide location writeable only by admins, or in user's profile writeable by users - The system-wide profiles may be started by any user with or without admin privileges - User's profiles may be started by those who are either in the "Administrators" group or in "OpenVPN Administrators" group Note that these restrictions are somewhat orthogonal to what networkmanager (nm) does on linux. The rationale for that is another topic. The locations and group names referred to above may be customized in the registry -- system-wide one's in HKLM and user-changeable one's in HKCU Finally, back to "average user" of the GUI, I plan to offer a dialog to add the user to the special "OpenVPN Administrators" group when they try to start a config that would be otherwise rejected by the service. This will obviously cause UAC or password prompt and will work only if the user knows admin password. This is work in progress, any feedback will be most helpful. For all this, the only requirement at installation is to create the group "OpenVPN Administrators" which may be done without any user intervention. Any thoughts? Selva |
|
From: Selva N. <sel...@gm...> - 2016-03-06 00:34:20
|
Hi, Thanks for the comments. On Sat, Mar 5, 2016 at 6:40 PM, Németh Tamás NET <nem...@ny...> wrote: > What if you add a config option to profile files which is similar to > "valid users" of samba's smb.conf? This option might be mandatory in > systemwide profiles and optional in personal profiles. Only users and > groups listed in this option would be permitted to use the profile > containing it. The main reason for two kinds of profile locations and two kinds of users is to do privilege separation in openvpn (the unprivileged worker process + a privileged service) without granting new rights to a limited user unless an admin sprinkles some holy water on it -- the admin has to either put up the config(s) in a special location or add the user to a special group. Any fine-grained control beyond that, imho, is the sysadmin's job. If a particular config should not be used by some users, just don't give them read access to those files. As openvpn will start as user, that's all it takes to protect a system-wide config from a user. Selva |
|
From: Doug L. <su...@dr...> - 2016-05-07 11:36:42
|
Samuli Seppänen wrote: > Hi, > > This issue has been fixed recently: it is possible to run OpenVPN as a > non-admin user in Windows. We have Git snapshot builds for Windows here: Just wondering, Is this special build still required or are these changes now in the current release? Thanks! Doug |
|
From: Gert D. <ge...@gr...> - 2016-05-07 16:53:13
Attachments:
signature.asc
|
hi,
On Sat, May 07, 2016 at 07:36:35AM -0400, Doug Lytle wrote:
> Samuli Seppänen wrote:
> > This issue has been fixed recently: it is possible to run OpenVPN as a
> > non-admin user in Windows. We have Git snapshot builds for Windows here:
>
> Just wondering,
>
> Is this special build still required or are these changes now in the
> current release?
The interactive service will show up in openvpn 2.4 - and in git master
based snapshots. It will not be part of 2.3, because the changes needed
are too intrusive (and, incidentially, drop WinXP support).
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany ge...@gr...
fax: +49-89-35655025 ge...@ne...
|
|
From: Doug L. <su...@dr...> - 2016-05-07 19:15:40
|
Gert Doering wrote: > The interactive service will show up in openvpn 2.4 Thanks for the info! Doug |
|
From: Samuli S. <sa...@op...> - 2016-05-08 07:36:48
|
> hi, > > On Sat, May 07, 2016 at 07:36:35AM -0400, Doug Lytle wrote: >> Samuli Seppänen wrote: >>> This issue has been fixed recently: it is possible to run OpenVPN as a >>> non-admin user in Windows. We have Git snapshot builds for Windows here: >> >> Just wondering, >> >> Is this special build still required or are these changes now in the >> current release? > > The interactive service will show up in openvpn 2.4 - and in git master > based snapshots. It will not be part of 2.3, because the changes needed > are too intrusive (and, incidentially, drop WinXP support). > > gert Hi, Expanding on this answer a bit. You will need to use a recent version of OpenVPN-GUI to make use of the interactive service. One option is to use the Git master snapshots (openvpn-install-master-*) which Gert mentioned: <http://build.openvpn.net/downloads/snapshots> If you're building and packaging OpenVPN yourself, you should build OpenVPN-GUI from Git sources ("master" branch"), or use the OpenVPN-GUI version 11 tarball: <http://build.openvpn.net/downloads/releases/openvpn-gui-11.tar.gz> Version 11/master includes features such as writing the registry keys to HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE. What this means that a normal user can create the required registry keys him/herself. If want to generate the OpenVPN-GUI tarball from Git sources on *NIX, you need a bit of trickery: $ autoreconf -vi $ ./configure --enable-distonly $ make dist-gzip -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock |
|
From: Doug L. <su...@dr...> - 2016-05-08 17:04:22
|
Samuli Seppänen wrote: > > > Hi, > > Expanding on this answer a bit. You will need to use a recent version > of OpenVPN-GUI to make use of the interactive service. One option is > to use the Git master snapshots (openvpn-install-master-*) which Gert > mentioned: > > <http://build.openvpn.net/downloads/snapshots> > I tried out Master today and it works well as a standard Windows 7 user, all routes were added just fine, but I do have a few errors listed in the Windows OpenVPN logs. This is from the latest master (2016.05.05) openvpn-install-master-20160505184903-d54a2488a0-x86_64.exe Is there a list of known issues that I compare with? My log entries show: Sun May 08 12:53:04 2016 us=615112 MANAGEMENT: >STATE:1462726384,CONNECTED,SUCCESS,192.168.200.70,64.136.xxx.xxx,5015,, Sun May 08 12:53:04 2016 Start net commands... Sun May 08 12:53:04 2016 C:\Windows\system32\net.exe stop dnscache Sun May 08 12:53:04 2016 ERROR: Windows ipconfig command failed: returned error code 2 Sun May 08 12:53:04 2016 C:\Windows\system32\net.exe start dnscache Sun May 08 12:53:04 2016 ERROR: Windows ipconfig command failed: returned error code 2 Sun May 08 12:53:04 2016 C:\Windows\system32\ipconfig.exe /flushdns Sun May 08 12:53:04 2016 C:\Windows\system32\ipconfig.exe /registerdns Sun May 08 12:53:04 2016 ERROR: Windows ipconfig command failed: returned error code 1 Sun May 08 12:53:04 2016 End net commands... Doug |
|
From: Gert D. <ge...@gr...> - 2016-05-08 17:35:41
Attachments:
signature.asc
|
Hi,
On Sun, May 08, 2016 at 01:04:15PM -0400, Doug Lytle wrote:
> Sun May 08 12:53:04 2016 us=615112 MANAGEMENT:
> >STATE:1462726384,CONNECTED,SUCCESS,192.168.200.70,64.136.xxx.xxx,5015,,
> Sun May 08 12:53:04 2016 Start net commands...
> Sun May 08 12:53:04 2016 C:\Windows\system32\net.exe stop dnscache
> Sun May 08 12:53:04 2016 ERROR: Windows ipconfig command failed:
> returned error code 2
> Sun May 08 12:53:04 2016 C:\Windows\system32\net.exe start dnscache
> Sun May 08 12:53:04 2016 ERROR: Windows ipconfig command failed:
> returned error code 2
> Sun May 08 12:53:04 2016 C:\Windows\system32\ipconfig.exe /flushdns
> Sun May 08 12:53:04 2016 C:\Windows\system32\ipconfig.exe /registerdns
> Sun May 08 12:53:04 2016 ERROR: Windows ipconfig command failed:
> returned error code 1
> Sun May 08 12:53:04 2016 End net commands...
These bits are not yet "interactive-service'ified".
Patch is sitting in my review queue (*sigh*), so "in the course of the
next few weeks" you should see this pop up in the master snapshots.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany ge...@gr...
fax: +49-89-35655025 ge...@ne...
|
|
From: Doug L. <su...@dr...> - 2016-05-08 18:25:50
|
Gert Doering wrote: > These bits are not yet "interactive-service'ified". > > Patch is sitting in my review queue (*sigh*), so "in the course of the > next few weeks" you should see this pop up in the master snapshots. Thanks for the update Doug |
|
From: Gert D. <ge...@gr...> - 2016-05-16 19:00:09
Attachments:
signature.asc
|
Hi, On Sun, May 08, 2016 at 02:25:42PM -0400, Doug Lytle wrote: > Gert Doering wrote: > > These bits are not yet "interactive-service'ified". > > > > Patch is sitting in my review queue (*sigh*), so "in the course of the > > next few weeks" you should see this pop up in the master snapshots. > > Thanks for the update Here we go - "next few weeks" was quicker than I thought - the patch has been merged today, and is in the latest release on http://build.openvpn.net/downloads/snapshots/ namely http://build.openvpn.net/downloads/snapshots/openvpn-install-master-20160516184848-970312f185-x86_64.exe http://build.openvpn.net/downloads/snapshots/openvpn-install-master-20160516184848-970312f185-i686.exe I would be very interested in hearing whether it works correctly now, that is, DNS is properly flushed, and no errors seen in the log. thanks, gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... |
|
From: debbie10t <deb...@gm...> - 2016-05-18 18:53:28
|
On 16/05/16 19:59, Gert Doering wrote: > Hi, > > On Sun, May 08, 2016 at 02:25:42PM -0400, Doug Lytle wrote: >> Gert Doering wrote: >>> These bits are not yet "interactive-service'ified". >>> >>> Patch is sitting in my review queue (*sigh*), so "in the course of the >>> next few weeks" you should see this pop up in the master snapshots. >> Thanks for the update > Here we go - "next few weeks" was quicker than I thought - the patch > has been merged today, and is in the latest release on > > http://build.openvpn.net/downloads/snapshots/ > > namely > > http://build.openvpn.net/downloads/snapshots/openvpn-install-master-20160516184848-970312f185-x86_64.exe > http://build.openvpn.net/downloads/snapshots/openvpn-install-master-20160516184848-970312f185-i686.exe > > > I would be very interested in hearing whether it works correctly now, > that is, DNS is properly flushed, and no errors seen in the log. > I was curious about this .. it tested out and everything appeared to work except the service did not reply to the request to flush dns. When I tested by command line (interactive service stopped) there was an unknown *ipconfig* error. pings across the tunnel all worked fine .. details below Client log using interactive service: Mon May 18 17:38:11 2016 us=375555 Blocking outside DNS Mon May 18 17:38:11 2016 us=375555 Using service to add block dns filters Mon May 18 17:38:11 2016 us=391142 Blocking outside dns using service succeeded. Mon May 18 17:38:16 2016 us=213522 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up Mon May 18 17:38:16 2016 us=213522 MANAGEMENT: >STATE:1463416696,ADD_ROUTES,,,,,, Mon May 18 17:38:16 2016 us=213522 C:\WINDOWS\system32\route.exe ADD 10.x.x.x MASK 255.255.255.0 10.x.x.x Mon May 18 17:38:16 2016 us=213522 Route addition via service succeeded Mon May 18 17:38:16 2016 us=213522 Initialization Sequence Completed Mon May 18 17:38:16 2016 us=213522 Register_dns request sent to the service Mon May 18 17:38:16 2016 us=213522 MANAGEMENT: >STATE:1463416696,CONNECTED,SUCCESS,10.x.x.x,y.y.y.y,zzzz,, Mon May 18 17:39:37 2016 us=399964 SIGTERM received, sending exit notification to peer Mon May 18 17:39:40 2016 us=970670 TCP/UDP: Closing socket Mon May 18 17:39:40 2016 us=970670 C:\WINDOWS\system32\route.exe DELETE 10.x.x.x MASK 255.255.255.0 10.x.x.x Mon May 18 17:39:40 2016 us=970670 Route deletion via service succeeded Mon May 18 17:39:40 2016 us=970670 Closing TUN/TAP interface Mon May 18 17:39:40 2016 us=970670 Uninitializing WFP Mon May 18 17:39:40 2016 us=970670 Using service to delete block dns filters Mon May 18 17:39:40 2016 us=970670 Unblocking outside dns using service succeeded. Mon May 18 17:39:40 2016 us=970670 SIGTERM[soft,exit-with-notification] received, process exiting Mon May 18 17:39:40 2016 us=970670 MANAGEMENT: >STATE:1463416780,EXITING,exit-with-notification,,,,, === Client log from admin command line: Mon May 18 17:53:34 2016 us=119659 Blocking outside DNS Mon May 18 17:53:34 2016 us=119659 Block_DNS: WFP engine opened Mon May 18 17:53:34 2016 us=135285 Block_DNS: Added permit filters for exe_path Mon May 18 17:53:34 2016 us=135285 Block_DNS: Added block filters for all Mon May 18 17:53:34 2016 us=150906 Block_DNS: Added permit filters for TAP interface Mon May 18 17:53:39 2016 us=807410 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up Mon May 18 17:53:39 2016 us=807410 C:\WINDOWS\system32\route.exe ADD 10.x.x.x MASK 255.255.255.0 10.x.x.x Mon May 18 17:53:39 2016 us=807410 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 Mon May 18 17:53:39 2016 us=807410 Route addition via IPAPI succeeded [adaptive] Mon May 18 17:53:39 2016 us=807410 Initialization Sequence Completed Mon May 18 17:53:39 2016 Start net commands... Mon May 18 17:53:39 2016 C:\WINDOWS\system32\net.exe stop dnscache Mon May 18 17:53:47 2016 C:\WINDOWS\system32\net.exe start dnscache Mon May 18 17:53:47 2016 ERROR: Windows ipconfig command failed: returned error code 2 Mon May 18 17:53:47 2016 C:\WINDOWS\system32\ipconfig.exe /flushdns Mon May 18 17:53:47 2016 C:\WINDOWS\system32\ipconfig.exe /registerdns Mon May 18 17:53:50 2016 End net commands... Mon May 18 17:58:48 2016 us=228451 SIGTERM received, sending exit notification to peer Mon May 18 17:58:51 2016 us=751405 TCP/UDP: Closing socket Mon May 18 17:58:51 2016 us=751405 C:\WINDOWS\system32\route.exe DELETE 10.x.x.x MASK 255.255.255.0 10.x.x.x Mon May 18 17:58:51 2016 us=751405 Route deletion via IPAPI succeeded [adaptive] Mon May 18 17:58:51 2016 us=751405 Closing TUN/TAP interface Mon May 18 17:58:51 2016 us=751405 Uninitializing WFP Mon May 18 17:58:51 2016 us=766993 SIGTERM[soft,exit-with-notification] received, process exiting === Tested with W10 and openvpn-2.3_git (built on May *18* 2016) http://build.openvpn.net/downloads/snapshots/openvpn-install-master-20160518064859-0d8a4ffa22-x86_64.exe regards |
|
From: Doug L. <su...@dr...> - 2016-05-16 20:01:02
|
>>> Here we go - "next few weeks" was quicker than I thought - the patch >>> has been merged today, and is in the latest release on How time seems to fly! :) 64bit version tested on Windows 7 Professional. No errors reported. Doug |
|
From: Gert D. <ge...@gr...> - 2016-05-16 20:11:50
Attachments:
signature.asc
|
Hi,
On Mon, May 16, 2016 at 04:00:55PM -0400, Doug Lytle wrote:
> >>> Here we go - "next few weeks" was quicker than I thought - the patch
> >>> has been merged today, and is in the latest release on
>
> How time seems to fly! :)
>
> 64bit version tested on Windows 7 Professional. No errors reported.
Thanks! 2.4 getting closer :-)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany ge...@gr...
fax: +49-89-35655025 ge...@ne...
|
|
From: Selva N. <sel...@gm...> - 2016-05-18 19:35:19
|
missed to cc: the list Hi, On Wed, May 18, 2016 at 2:53 PM, debbie10t <deb...@gm...> wrote: > On 16/05/16 19:59, Gert Doering wrote: > > Hi, > > > > On Sun, May 08, 2016 at 02:25:42PM -0400, Doug Lytle wrote: > >> Gert Doering wrote: > >>> These bits are not yet "interactive-service'ified". > >>> > >>> Patch is sitting in my review queue (*sigh*), so "in the course of the > >>> next few weeks" you should see this pop up in the master snapshots. > >> Thanks for the update > > Here we go - "next few weeks" was quicker than I thought - the patch > > has been merged today, and is in the latest release on > > > > http://build.openvpn.net/downloads/snapshots/ > > > > namely > > > > > http://build.openvpn.net/downloads/snapshots/openvpn-install-master-20160516184848-970312f185-x86_64.exe > > > http://build.openvpn.net/downloads/snapshots/openvpn-install-master-20160516184848-970312f185-i686.exe > > > > > > I would be very interested in hearing whether it works correctly now, > > that is, DNS is properly flushed, and no errors seen in the log. > > > I was curious about this .. it tested out and everything appeared to > work except > the service did not reply to the request to flush dns. When I tested by > command > line (interactive service stopped) there was an unknown *ipconfig* error. > pings across the tunnel all worked fine .. details below > > Thanks for testing. > > Client log using interactive service: > > Mon May 18 17:38:11 2016 us=375555 Blocking outside DNS > Mon May 18 17:38:11 2016 us=375555 Using service to add block dns filters > Mon May 18 17:38:11 2016 us=391142 Blocking outside dns using service > succeeded. > Mon May 18 17:38:16 2016 us=213522 TEST ROUTES: 1/1 succeeded len=1 > ret=1 a=0 u/d=up > Mon May 18 17:38:16 2016 us=213522 MANAGEMENT: > >STATE:1463416696,ADD_ROUTES,,,,,, > Mon May 18 17:38:16 2016 us=213522 C:\WINDOWS\system32\route.exe ADD > 10.x.x.x MASK 255.255.255.0 10.x.x.x > Mon May 18 17:38:16 2016 us=213522 Route addition via service succeeded > Mon May 18 17:38:16 2016 us=213522 Initialization Sequence Completed > > Mon May 18 17:38:16 2016 us=213522 Register_dns request sent to the > service > That means the service received the request and will execute them silently :-) . The dnscache restart, dns flush and register-dns are executed by interactive service asynchronously (as it takes some time) and currently we do not have a way for the service to report back to openvpn at the end of such operations. However, it will log those actions in the windows event log. Also output of "ipconfig /displaydns" soon after the flush should show an empty or a freshly-populated list of cached entries. Client log from admin command line: > Mon May 18 17:53:34 2016 us=119659 Blocking outside DNS > Mon May 18 17:53:34 2016 us=119659 Block_DNS: WFP engine opened > Mon May 18 17:53:34 2016 us=135285 Block_DNS: Added permit filters for > exe_path > Mon May 18 17:53:34 2016 us=135285 Block_DNS: Added block filters for all > Mon May 18 17:53:34 2016 us=150906 Block_DNS: Added permit filters for > TAP interface > Mon May 18 17:53:39 2016 us=807410 TEST ROUTES: 1/1 succeeded len=1 > ret=1 a=0 u/d=up > Mon May 18 17:53:39 2016 us=807410 C:\WINDOWS\system32\route.exe ADD > 10.x.x.x MASK 255.255.255.0 10.x.x.x > Mon May 18 17:53:39 2016 us=807410 ROUTE: CreateIpForwardEntry succeeded > with dwForwardMetric1=20 and dwForwardType=4 > Mon May 18 17:53:39 2016 us=807410 Route addition via IPAPI succeeded > [adaptive] > Mon May 18 17:53:39 2016 us=807410 Initialization Sequence Completed > Mon May 18 17:53:39 2016 Start net commands... > Mon May 18 17:53:39 2016 C:\WINDOWS\system32\net.exe stop dnscache > Mon May 18 17:53:47 2016 C:\WINDOWS\system32\net.exe start dnscache > Mon May 18 17:53:47 2016 ERROR: Windows ipconfig command failed: > returned error code 2 > That message is misleading (a common error string used for all those four commands) --- it most likely refers to the net.exe command just above it, but not sure why that one failed. It may be useful to check the status of the dnscache service when this happens. > Mon May 18 17:53:47 2016 C:\WINDOWS\system32\ipconfig.exe /flushdns > Mon May 18 17:53:47 2016 C:\WINDOWS\system32\ipconfig.exe /registerdns > Mon May 18 17:53:50 2016 End net commands... Selva |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X