Re: [Openvpn-devel] problem with beta3 and wintun
To All 3, Thank you with your help I found the issue. UAC was disabled in the registry on this image. IIRC we had trouble updating some software by automated script and turning UAC off was required. After re-enabling UAC, wintun started normally. On Thu, Sep 10, 2020 at 12:33 AM Gert Doering wrote: > Hi, > > On Thu, Sep 10, 2020 at 12:10:25AM -0700, Marvin Adeff wrote: > > Please allow me to back up a moment and restate this: > > As a matter of mailing list etiquette - could you please not post > this with > > Subject: Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback > > I do try to figure out what is "patch related" and what is "new problems", > and *this* is certainly not related to the NCP PATCH. > > > > 1. I installed the beta3 msi from the web site logged in as a user that > has admin privileges. But no elevation was used to install it, just > double-click on the file. > > 2. I only used the GUI as installed, with no elevation, to start > OpenVPN. > > 3. With TAP selected in my .ovpn config file, everything works > normally. > > 4. I am reporting that (from the same login) if I change the .ovpn to > use wintun (all edits done through the GUI selection), it fails with the > error I showed below. > > Is the interactive service running? > > If tap is used, do you see "routes installed using service" or do you > see netsh commands in the openvpn log? > > > Is 4. what you are saying is not supported? In our use, as we have done > for the past decade, the client boxes are used for M2M monitoring. OpenVPN > has to connect on bootup (.ovpn config file contains inline certificates) > regardless if there is a user logged in or not as M2M monitoring occurs in > the background. And if a user does login, most often it is with > credentials that have admin privileges. I am trying to understand if what > you???re telling me is that this will no longer work, or if we will need to > do something different now? My testing used the GUI to see how things will > work with wintun so we can continue testing. > > > > Do I need to NOT use the GUI to get wintun to work? > > Wintun needs SYSTEM privileges. > > To get such, you either need to run OpenVPN "at boot" via openvpnsrv2 > (which has SYSTEM privileges), *or* you need to use the interactive service > via the GUI. > > Due to some Vista-related quirks in the GUI, the GUI will not use the > iservice if it's run elevated (run-as-admin). If I understand Selva > right, it *should* work if you "just run it", even if the user has > admin privs, as long as UAC is active (as Win10 runs user processes > unprivileged, even if the user is part of the Admin group). > > > The error message you have posted hints at "the interactive service is > not being used" - which could be due to "it is not running" or "GUI is > running elevated". > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hi On Thu, Sep 10, 2020 at 3:10 AM Marvin Adeff wrote: > Selva, > > Please allow me to back up a moment and restate this: > 1. I installed the beta3 msi from the web site logged in as a user that > has admin privileges. But no elevation was used to install it, just > double-click on the file. > 2. I only used the GUI as installed, with no elevation, to start OpenVPN. > 3. With TAP selected in my .ovpn config file, everything works normally. > 4. I am reporting that (from the same login) if I change the .ovpn to use > wintun (all edits done through the GUI selection), it fails with the error > I showed below. > > Is 4. what you are saying is not supported? > This use case is fully supported and should work. If it's not working, as lev said, something is not right. Please share the full connection log with verb=4 and we may spot something. > In our use, as we have done for the past decade, the client boxes are used > for M2M monitoring. OpenVPN has to connect on bootup (.ovpn config file > contains inline certificates) regardless if there is a user logged in or > not as M2M monitoring occurs in the background. And if a user does login, > most often it is with credentials that have admin privileges. I am trying > to understand if what you’re telling me is that this will no longer work, > or if we will need to do something different now? My testing used the GUI > to see how things will work with wintun so we can continue testing. > > Do I need to NOT use the GUI to get wintun to work? > Connections started at boot using OpenVPNService will also work with wintun (2.5_beta3 and newer). You do not have to use the GUI. When an admin user logs in to Windows the elevated privileges in the token are disabled by default , so the user starting any process including OpenVPN-GUI will run in the *correct* unprivileged mode. Privileges are acquired only when/if a UAC prompt appears and the user consents to it, or when explicitly using run-as-admin. So, OpenVPN-GUi will run without enabling privileges for all users and that is the right way to run the GUI. So does a million other programs. This is the default behaviour of Windows since Vista and is a good thing. Selva ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN
Hi Arne, I understand your concern and apologize for the delay. We have been busy with the release of wolfSSL 4.5.0. I will make sure that the fixes necessary for OpenVPN support will be prioritized. Sincerely Juliusz On 10/09/2020 12:18, Arne Schwabe wrote: Am 22.07.20 um 16:02 schrieb Juliusz Sosinowicz: Hi Arne, thank you for your feedback. I tested the patch on the latest master version at the time of writing and it looks like these requirements were added in the last week which is why I wasn't able to address them before.I will look into the new issues and get back to you when they are fixed. I agree that most of these functions only require exposing existing functionality on our side. We already progressed to OpenVPN 2.5-beta4 now. I think it is fair to say that WolfSSL missed the window to be included in 2.5.0. And seeing that these rather simple fixes take now over 1,5months does not exactly inspire confidence that WolfSSL is committed to maintaining OpenVPN support. Arne ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN
Am 10.09.20 um 14:11 schrieb Juliusz Sosinowicz: > Hi Arne, > > I understand your concern and apologize for the delay. We have been busy > with the release of wolfSSL 4.5.0. I will make sure that the fixes > necessary for OpenVPN support will be prioritized. > > Sincerely > Juliusz I think the best way forward is to include wolfSSL support into OpenVPN master now and if we have proper a proper support of wolfSSL that is kept up to from your side then it will be part of the next release. And otherwise we remove the support before the next release. That should our concerns of wanting to see ongoing support and also your concern of it not being included. Arne signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN
Am 22.07.20 um 16:02 schrieb Juliusz Sosinowicz: > Hi Arne, > > thank you for your feedback. I tested the patch on the latest master > version at the time of writing and it looks like these requirements were > added in the last week which is why I wasn't able to address them > before.I will look into the new issues and get back to you when they are > fixed. > > I agree that most of these functions only require exposing existing > functionality on our side. We already progressed to OpenVPN 2.5-beta4 now. I think it is fair to say that WolfSSL missed the window to be included in 2.5.0. And seeing that these rather simple fixes take now over 1,5months does not exactly inspire confidence that WolfSSL is committed to maintaining OpenVPN support. Arne signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Fix best gateway selection over netlink
Thanks a lot. Your patch has been applied to the master and release/2.5 branch. (I have lightly tested this on Linux 4.19.9 and stared a bit at the code. Antonio is the master of this code and if he says it's good, it is :-) ) commit 505d5ad8fadcdc56bae07f4b95c05acd93a47c24 (master) commit 7a9fefb6e2ea28967a09956eeb041b687ca0e335 (release/2.5) Author: Vladislav Grishenko Date: Tue Sep 8 17:36:25 2020 +0500 Fix best gateway selection over netlink Signed-off-by: Vladislav Grishenko Acked-by: Antonio Quartulli Message-Id: <20200908123625.23179-1-themi...@yandex-team.ru> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20900.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Fix TUNSETGROUP compatibility with very old Linux systems.
Patch has been applied to the master, release/2.5 and release/2.4 branch. commit a4e0ac0604460ea2431acb7481d6ffb7a3fc6298 (master) commit 43e70c78c34b90b15b6bfdac9c1911853defca10 (release/2.5) commit a1dc800348937d6993f5008140081f66a695026a (release/2.4) Author: Gert Doering Date: Wed Sep 9 17:37:25 2020 +0200 Fix TUNSETGROUP compatibility with very old Linux systems. Signed-off-by: Gert Doering Acked-by: Arne Schwabe Message-Id: <20200909153725.1158-1-g...@greenie.muc.de> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20932.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v3] Fix best gateway selection over netlink
Hi, On 08/09/2020 14:36, Vladislav Grishenko wrote: > Netlink route request with NLM_F_DUMP flag set means to return > all entries matching criteria passed in message content - > matching supplied family & dst address in our case. > So, gateway from the first ipv4 route was always used. > > On kernels earlier than 2.6.38 default routes are the last ones, > so arbitrary host/net route w/o gateway is likely be returned as > first, causing gateway to be invalid or empty. > After refactoring in 2.6.38 kernel default routes are on top, so > the problem with older kernels was hidden. > > Fix this behavior by selecting first 0.0.0.0/0 if dst was not set > or empty. For IPv6, no behavior is changed - request ::/128 route, > so just clarify the sizes via netlink route api. > > Tested on 5.4.0, 4.1.51, 2.6.36 and 2.6.22 kernels. > > Signed-off-by: Vladislav Grishenko Thanks for taking care of this issue and for digging into the sitnl code. The change is really contained and and easy to review. Tested a bit and it works as expected. Acked-by: Antonio Quartulli -- Antonio Quartulli ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 0/4] Allow setting up OpenVPN in TLS mode without CA
Am 09.09.20 um 20:23 schrieb tincanteksup: > > > On 09/09/2020 11:21, Arne Schwabe wrote: >> Am 09.09.20 um 10:04 schrieb François Kooman: >>> On 9/8/20 6:38 PM, Arne Schwabe wrote: I really wonder which large deployment want to do that instead of a CA. I really understand the need for small and simple deployments. But for larger deployments a CA + CRL seems more useful for everything that I can come up with. >>> >>> It would be more for the situation where you already have a "parallel >>> trust", e.g. through an OAuth API where a CA would be redundant. Just >>> having an API to register fingerprints (which would act as a CRL at the >>> same time by simply removing fingerprints) is easier than having a >>> complete CA with CRL. >>> >>> Of course, all of this can also be done by using a CA, and something can >>> be said that if you operate on that scale you can also handle the extra >>> "cost" of a CA... >> >> I am happy to review a patch that adds a allow_no_ca or similar flag to >> the tls-verify option that allows this but I don't have a real >> motivation to implement it myself. >> >> Just allowing ca not set with tls-verify script being set is a bit too >> dangerous for my taste. >> > > I too would like to see an external list of fingerprints be made available. > https://community.openvpn.net/openvpn/ticket/1323#ticket Yes it would be nicer but this is for small setups and reconnects and quick and cheap. I don't want this feature to evolve into a second PKI infrastructure just worse. Arne signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix TUNSETGROUP compatibility with very old Linux systems.
Am 09.09.20 um 17:37 schrieb Gert Doering:
> Our code works on "very old Linux" (Fedora-1), but needs a #define
> for TUNSETGROUP to compile. Everything else is there.
>
> While at it, fix TUNSETGROUP error message.
>
> Reported-By: noloader on Trac
> Trac: #1152
>
> Signed-off-by: Gert Doering
> ---
> src/openvpn/tun.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
> index 923131ad..651cb871 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -1993,6 +1993,11 @@ open_tun(const char *dev, const char *dev_type, const
> char *dev_node, struct tun
>
> #ifdef ENABLE_FEATURE_TUN_PERSIST
>
> +/* TUNSETGROUP appeared in 2.6.23 */
> +#ifndef TUNSETGROUP
> +# define TUNSETGROUP _IOW('T', 206, int)
> +#endif
> +
> void
> tuncfg(const char *dev, const char *dev_type, const char *dev_node,
> int persist_mode, const char *username, const char *groupname,
> @@ -2032,7 +2037,7 @@ tuncfg(const char *dev, const char *dev_type, const
> char *dev_node,
> }
> else if (ioctl(tt->fd, TUNSETGROUP, platform_state_group.gr->gr_gid)
> < 0)
> {
> -msg(M_ERR, "Cannot ioctl TUNSETOWNER(%s) %s", groupname, dev);
> +msg(M_ERR, "Cannot ioctl TUNSETGROUP(%s) %s", groupname, dev);
> }
> }
> close_tun(tt, ctx);
>
Hm, it does not hurt, so...
Acked-By: Arne Schwabe
signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hi Marvin, > 1. I installed the beta3 msi from the web site logged in as a user that has > admin privileges. But no elevation was used to install it, just double-click > on the file. > 2. I only used the GUI as installed, with no elevation, to start OpenVPN. > 3. With TAP selected in my .ovpn config file, everything works normally. > 4. I am reporting that (from the same login) if I change the .ovpn to use > wintun (all edits done through the GUI selection), it fails with the error I > showed below. This doesn't look right. Could you provide a relevant part of a log file? For example, below is my recent connection log with beta3 and wintun: 2020-09-10 10:27:05 interactive service msg_channel=584 2020-09-10 10:27:05 ROUTE_GATEWAY 100.64.0.1/255.240.0.0 I=20 HWADDR=84:fd:d1:e8:1e:6c 2020-09-10 10:27:05 open_tun 2020-09-10 10:27:05 Ring buffers registered via service 2020-09-10 10:27:05 wintun device [OpenVPN Wintun] opened The first line means the openvpn-gui uses interactive service, which is used to open wintun device (which requires SYSTEM privileges) and setting up tun interface (which requires elevated privileges). Symptomes you mentioned are the same when GUI is run under elevated privileges and interactive service is not used, but it is impossible to say if this is the case without seeing logs. ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] problem with beta3 and wintun
Hi, On Thu, Sep 10, 2020 at 12:10:25AM -0700, Marvin Adeff wrote: > Please allow me to back up a moment and restate this: As a matter of mailing list etiquette - could you please not post this with Subject: Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback I do try to figure out what is "patch related" and what is "new problems", and *this* is certainly not related to the NCP PATCH. > 1. I installed the beta3 msi from the web site logged in as a user that has > admin privileges. But no elevation was used to install it, just double-click > on the file. > 2. I only used the GUI as installed, with no elevation, to start OpenVPN. > 3. With TAP selected in my .ovpn config file, everything works normally. > 4. I am reporting that (from the same login) if I change the .ovpn to use > wintun (all edits done through the GUI selection), it fails with the error I > showed below. Is the interactive service running? If tap is used, do you see "routes installed using service" or do you see netsh commands in the openvpn log? > Is 4. what you are saying is not supported? In our use, as we have done for > the past decade, the client boxes are used for M2M monitoring. OpenVPN has > to connect on bootup (.ovpn config file contains inline certificates) > regardless if there is a user logged in or not as M2M monitoring occurs in > the background. And if a user does login, most often it is with credentials > that have admin privileges. I am trying to understand if what you???re > telling me is that this will no longer work, or if we will need to do > something different now? My testing used the GUI to see how things will work > with wintun so we can continue testing. > > Do I need to NOT use the GUI to get wintun to work? Wintun needs SYSTEM privileges. To get such, you either need to run OpenVPN "at boot" via openvpnsrv2 (which has SYSTEM privileges), *or* you need to use the interactive service via the GUI. Due to some Vista-related quirks in the GUI, the GUI will not use the iservice if it's run elevated (run-as-admin). If I understand Selva right, it *should* work if you "just run it", even if the user has admin privs, as long as UAC is active (as Win10 runs user processes unprivileged, even if the user is part of the Admin group). The error message you have posted hints at "the interactive service is not being used" - which could be due to "it is not running" or "GUI is running elevated". gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Selva, Please allow me to back up a moment and restate this: 1. I installed the beta3 msi from the web site logged in as a user that has admin privileges. But no elevation was used to install it, just double-click on the file. 2. I only used the GUI as installed, with no elevation, to start OpenVPN. 3. With TAP selected in my .ovpn config file, everything works normally. 4. I am reporting that (from the same login) if I change the .ovpn to use wintun (all edits done through the GUI selection), it fails with the error I showed below. Is 4. what you are saying is not supported? In our use, as we have done for the past decade, the client boxes are used for M2M monitoring. OpenVPN has to connect on bootup (.ovpn config file contains inline certificates) regardless if there is a user logged in or not as M2M monitoring occurs in the background. And if a user does login, most often it is with credentials that have admin privileges. I am trying to understand if what you’re telling me is that this will no longer work, or if we will need to do something different now? My testing used the GUI to see how things will work with wintun so we can continue testing. Do I need to NOT use the GUI to get wintun to work? Marvin > On Sep 9, 2020, at 9:56 PM, Selva Nair wrote: > > Hi, > >> On Thu, Sep 10, 2020 at 12:19 AM Marvin wrote: >> Hi Selva, >> >>> The GUI did not have this error unless run as administrator which you >>> should not and will never work. >> So you are saying that if OpenVPN is installed by a user who has admin >> privileges (as our case does) that v2.5 with wintun will not work? > > You mean OpenVPN started using the GUI? If so, no, I'm not saying that. The > GUI just works even with beta1 or with beta3. On Windows user's processes run > with limited privileges even if the user is an "admin". At least that is the > default because of UAC. > > Installation can be done when logged in as admin or as a limited user > (provided you know admin credentials) as the installer prompts for elevation > as required. > > That qualifier I added was because: the GUI running with privileges (admin) > has been discouraged in 2.4 ever since we introduced the interactive service. > And that continues with 2.5. It will work for some things and not for some > other things. Same with running the GUI with interactive service disabled. As > such uses are not supported, don't complain about it :) > > Selva ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
