Re: [Openvpn-users] openvpn dns resolution on osx
Hi, On Mon, Jun 7, 2021 at 7:36 PM Noah wrote: > > Hi there, > > I am running osx 10.15.7 and installed the openvpn v3.2.7 client. > > Has anybody documented a decent way to be able to resolve hosts that are > reachable by the VPN. We have resolvers at the site I can get > resolution from when using the dig @ command. Any really good > solutions are welcome. 1. OpenVPN 3.2.7 is several years old and should not be used. The current version is 2.5.2, which should work fine on macOS 10.15.7. 2. On macOS, "dig", "ping", and some other command line programs use different DNS resolution than almost all other macOS programs. ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Strange problem: I'm disconnected after ~100s
Hi, On Mon, Aug 3, 2020 at 9:53 AM Gert Doering wrote: > > Hi, > > On Mon, Aug 03, 2020 at 02:30:54PM +0200, Thierry Fournier wrote: > > Anyone has an idea ? > > Without log, I never have ideas... put "verb 3" or "verb 4" into > the client config and see what it says. Tunnelblick has a button that copies "diagnostic info" to the Clipboard, ready to be pasted. The info includes the logs along with a lot of other useful info. Although security certificates are removed automatically, you may want to remove other sensitive info before posting it publicly. See Read Before You Post [1]. Best regards, Jon Bullard [1] https://tunnelblick.net/cBeforeYouPost.html ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN with OSPF there is no proper guide or support
Hi, On Wed, Apr 29, 2020 at 3:43 AM Gert Doering wrote: > > Hi, > > On Wed, Apr 29, 2020 at 09:03:20AM +0200, free...@tango.lu wrote: > > Ok so after a bit of research and finding half baked articles such as: > > https://superuser.com/questions/1283125/proper-configuration-for-quagga-ospf-on-an-openvpn-network > > > > Which makes me think OSPF is only possible with the old tap interfaces, > > what the OpenVPN dev team even want to remove in the future, why is > > there no proper support of OSPF in routed tun tunnels? > > Not sure where that rumor is coming from. No removal of TAP device > support is planned. I don't know where the rumor started, but I can understand why it is plausible: (A) The OpenVPN developers discourage the use of TAP connections, saying, for example "Layer 3 is for a number of reasons the better choice anyways" [1]; (B) The "OpenVPN Connect" Android and iOS apps do not support TAP connections [1][2]; and (C) Apple has deprecated loading the system extension that Tunnelblick uses to create a TAP device and, on the latest version of macOS, pops up a warning saying the extension "will be incompatible with future versions of macOS" [3]. Best regards, Jon Bullard [1] https://openvpn.net/vpn-server-resources/faq-regarding-openvpn-connect-android/#Why_does_the_app_not_support_TAP-style_tunnels [2] https://openvpn.net/vpn-server-resources/faq-regarding-openvpn-connect-ios/#Why_doesnt_the_app_support_tap-style_tunnels [3] https://tunnelblick.net/cTunTapConnections.html ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] [ext] Re: OpenVPN GUI 11
Hi, On Thu, Apr 16, 2020 at 8:25 AM Ralf Hildebrandt wrote: > > * Jonathan K. Bullard : > > > Just for the record, the best way to install configurations in > > Tunnelblick is to drag the configuration(s) and drop them on the > > Tunnelblick icon in the menu bar. The user can install "incomplete" > > .ovpn files, too, as long as the cert/key/etc. files the .ovpn files > > reference are readable by the user. > > Jonathan, just let me say: Tunnelblick rocks. > > You put so much thought into this piece of software. It's a joy > running it. It's so much more sane than openvpnGUI on Windows (no > offense intended). Thanks! I try! > The only thing which is currently giving me gripes is that "the > configuration file you're currently using is outdated and some distant > version of openvpn might not be able to connect" - warning. > > (My) users don't comprehend this. They don't grasp that it's just a > warning . > > They see this warning as error "rendering their current installation > faulty/non working" - while it's working perfectly. Yeah, it's a problem. And I'm about to add more such warnings now that macOS has started displaying cryptic warnings about system extensions not working in future versions of macOS. Inspired by your comment, I'm going to rewrite these warnings to stress that the configuration works now. Maybe users will at least read the first sentence of the warning. But I'm not getting my hopes up. For administrators with some control of their users' computers or installations of Tunnelblick, you can set a Tunnelblick preference to disable these warnings. Unfortunately there's a separate preference for each of the different warnings. > For over a year we're sending out config files which don't trigger the > warning, but people still use the old files - and a new Tunnelblick, > since (thank Lord!) it auto updates! Consider having the config files update, too, using our "new, simpler" mechanism [1]. (But note that until they update their config files to updatable config files, they won't update : ) The new way of having config files update requires that you distribute "Tunnelblick VPN Configurations" [2], not plain .ovpn files, so that will be a problem if you distribute the same configuration file(s) for users of all platforms. Colin, please accept my apologies for hijacking your thread. Just want to set the record straight! Cheers, Jon Bullard [1] https://tunnelblick.net/cNewUpdatableConfigurations.html [2] https://tunnelblick.net/cPkgs.html ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN GUI 11
Hi, On Wed, Apr 15, 2020 at 10:19 AM Colin Ryan wrote: > > Folks, > > Per a previous email (and thanks for the help), I've been playing around > with the 11 GUI. > > > One thing that has come up is wondering if there is anyway to generate a > situation where if a user is presented a complete (i.e. embedded certs) > .ovpn config file is there a configuration or switch that could be used > to automatically have it Imported into the OpenVPN-GUI's local user > config directories via a simple double click. > > > I know Tunneblick on Mac does this where a user can simply double click > a ovpn extension file and it will prompt to load the configuration. Just for the record, the best way to install configurations in Tunnelblick is to drag the configuration(s) and drop them on the Tunnelblick icon in the menu bar. The user can install "incomplete" .ovpn files, too, as long as the cert/key/etc. files the .ovpn files reference are readable by the user. Drag/drop forces macOS to use the currently-running copy ofTunnelblick to install the configuration. macOS's Launch Services, which handles double-clicks, can get confused when more than one copy of Tunnelblick exists on a system, or when other programs claim to be able to open configuration files, or when its database gets messed up. All three happen with enough frequency that we recommend drag/drop to install. Cheers, Jon Bullard PS: Because of the way macOS works, we can't disable double-clicks but still allow drag/drop, so for most users a double-click will work. But we don't advertise that. ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] [Openvpn-devel] Removing --disable-server option from OpenVPN
Oops. On Wed, Sep 18, 2019 at 6:54 AM Jonathan K. Bullard wrote: > > Hi, > > On Wed, Sep 18, 2019 at 6:38 AM Samuli Seppänen wrote: > > > > Hi, > > > > We are considering removing the --disable-server option from OpenVPN in 2.5. > > > > Do you use (and need) it, or know of somebody using (and needing) it? > > As far as I know, it is not used by any Tunnelblick users. > > Also, note that it doesn't appear on the 2.4 man page [1]. (Even > substituting "–" for "--".) > > Best regards, > > Jon Bullard > > [1] https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/ I misunderstood -- it's a compile-time option, not an OpenVPN option. Tunnelblick doesn't use it for our builds. Sorry for the noise. Jon Bullard ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] [Openvpn-devel] Removing --disable-server option from OpenVPN
Hi, On Wed, Sep 18, 2019 at 6:38 AM Samuli Seppänen wrote: > > Hi, > > We are considering removing the --disable-server option from OpenVPN in 2.5. > > Do you use (and need) it, or know of somebody using (and needing) it? As far as I know, it is not used by any Tunnelblick users. Also, note that it doesn't appear on the 2.4 man page [1]. (Even substituting "–" for "--".) Best regards, Jon Bullard [1] https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/ ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] iOS client, redirection of all VPN traffic not working (OpenVPN 2.4.6 on FreeBSD)
Hi, On Mon, Mar 4, 2019 at 5:38 PM Sebastian Wolfgarten wrote: > > Hi, > > I am trying to redirect all VPN traffic such that it goes through OpenVPN. > Authentications works fine, client can connect to the VPN. > > However my client IP remains unchanged (e.g. when checking it with > www.ipinfo.info), i.e. the web traffic is not routed through my OpenVPN > tunnel. Here is my server config (on FreeBSD, OpenVPN 2.4.6): Perhaps your web traffic is IPv6 instead of IPv4. By default, --redirect-gateway only redirects IPv4 traffic through the VPN. There is an "ipv6" option for --redirect-gateway but it may not be available in the version(s) of OpenVPN that you're using. Best regards, Jon Bullard Tunnelblick ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Expired GnuPG key?
Hi, David. On Mon, Oct 1, 2018 at 8:59 AM David Sommerseth wrote: > > On 30/09/18 23:14, Jonathan K. Bullard wrote: > > I downloaded openvpn-2.4.6.tar.gz and the associated GnuPG signature, > > but the signing key seems to have expired before it was signed: > > > > $gpg2 -v --verify openvpn-2.4.6.tar.gz.asc > > gpg: assuming signed data in '/***/openvpn-2.4.6.tar.gz' > > gpg: Signature made Tue Apr 24 03:14:52 2018 EDT > > gpg:using RSA key D518B9BD643CF94DA5ED9970F132B1CBAF131CAE > > gpg: Note: signature key D72AF3448CC2B034 expired Tue Mar 6 07:17:50 2018 > > EST > The important line is this one: > > > gpg: Good signature from "OpenVPN - Security Mailing List" > > Yes, the signing key we used has expired, as we only have 1 year life time on > them. But we would need to re-sign all packages to get rid of this. Which > would not give anything but removing the warnings that the key used has > expired. Thanks for your confirmation that the signature is good. But I was not saying that the key has expired *today*. I was saying that the key had already expired at the time it was used to create the signature: the key was used to create the signature several weeks *after* it had expired. Or was the expired key not actually used to create the signature and the note was irrelevant noise from GnuPG? > Also realise that this is just a "Note", not an error. That's one reason why I only got around to asking about this now -- it didn't seem urgent. The other reason was that the key had only expired a few weeks before the signature was created. If it had expired years before I might suspect that the key had been compromised. Best regards, Jon Bullard On Mon, Oct 1, 2018 at 8:59 AM David Sommerseth wrote: > > On 30/09/18 23:14, Jonathan K. Bullard wrote: > > I downloaded openvpn-2.4.6.tar.gz and the associated GnuPG signature, > > but the signing key seems to have expired before it was signed: > > > > $gpg2 -v --verify openvpn-2.4.6.tar.gz.asc > > gpg: assuming signed data in '/***/openvpn-2.4.6.tar.gz' > > gpg: Signature made Tue Apr 24 03:14:52 2018 EDT > > gpg:using RSA key D518B9BD643CF94DA5ED9970F132B1CBAF131CAE > > gpg: Note: signature key D72AF3448CC2B034 expired Tue Mar 6 07:17:50 2018 > > EST > > gpg: using subkey F132B1CBAF131CAE instead of primary key 12F5F7B42F2B01E7 > > gpg: Note: signature key D72AF3448CC2B034 expired Tue Mar 6 07:17:50 2018 > > EST > > gpg: using pgp trust model > > gpg: Good signature from "OpenVPN - Security Mailing List > > " [unknown] > > gpg: Note: signature key D72AF3448CC2B034 expired Tue Mar 6 07:17:50 2018 > > EST > > gpg: WARNING: This key is not certified with a trusted signature! > > gpg: There is no indication that the signature belongs to the > > owner. > > Primary key fingerprint: F554 A368 7412 CFFE BDEF E0A3 12F5 F7B4 2F2B 01E7 > > Subkey fingerprint: D518 B9BD 643C F94D A5ED 9970 F132 B1CB AF13 1CAE > > gpg: binary signature, digest algorithm SHA256, key algorithm rsa4096 > > > > Any ideas? > > The important line is this one: > > > gpg: Good signature from "OpenVPN - Security Mailing List" > > Yes, the signing key we used has expired, as we only have 1 year life time on > them. But we would need to re-sign all packages to get rid of this. Which > would not give anything but removing the warnings that the key used has > expired. > > Also realise that this is just a "Note", not an error. > > > -- > kind regards, > > David Sommerseth > OpenVPN Inc > > ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] Expired GnuPG key?
I downloaded openvpn-2.4.6.tar.gz and the associated GnuPG signature, but the signing key seems to have expired before it was signed: $gpg2 -v --verify openvpn-2.4.6.tar.gz.asc gpg: assuming signed data in '/***/openvpn-2.4.6.tar.gz' gpg: Signature made Tue Apr 24 03:14:52 2018 EDT gpg:using RSA key D518B9BD643CF94DA5ED9970F132B1CBAF131CAE gpg: Note: signature key D72AF3448CC2B034 expired Tue Mar 6 07:17:50 2018 EST gpg: using subkey F132B1CBAF131CAE instead of primary key 12F5F7B42F2B01E7 gpg: Note: signature key D72AF3448CC2B034 expired Tue Mar 6 07:17:50 2018 EST gpg: using pgp trust model gpg: Good signature from "OpenVPN - Security Mailing List " [unknown] gpg: Note: signature key D72AF3448CC2B034 expired Tue Mar 6 07:17:50 2018 EST gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: F554 A368 7412 CFFE BDEF E0A3 12F5 F7B4 2F2B 01E7 Subkey fingerprint: D518 B9BD 643C F94D A5ED 9970 F132 B1CB AF13 1CAE gpg: binary signature, digest algorithm SHA256, key algorithm rsa4096 Any ideas? Thanks in advance, Jon Bullard ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Challenge/response questions
Hi, David. Thanks for all the info. Very helpful. On Thu, Jun 28, 2018 at 5:21 AM, David Sommerseth wrote: > On 27/06/18 23:56, Jonathan K. Bullard wrote: >> Hi. >> >> I'm hoping to implement challenge/response ("CR") in Tunnelblick (GUI >> for OpenVPN on macOS) and have some questions after reading the >> documentation [1]; -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] Challenge/response questions
Hi. I'm hoping to implement challenge/response ("CR") in Tunnelblick (GUI for OpenVPN on macOS) and have some questions after reading the documentation [1]; 1. In Dynamic CR, does requiring a response mean that a non-empty response is required? 2. In Dynamic CR, what is the purpose of _not_ requiring a response? Is it to display a message without a text input box and have the user only able to click "OK" or "Cancel" (and disconnect if the user clicks "Cancel")? Or should I display a text input box but allow the user to leave it empty (and send an empty "response" to the server?) 3. In Dynamic CR, what is the purpose of passing the username from the server to the client and then back to the server? For example, am I supposed to display the username along with the challenge? 4. Are there any conventions about the "challenge" string? For example, should "\n" be interpreted as a newline? 5. Other than not being a great workflow, is there any problem with displaying the static CR in a separate dialog after the username/password have been entered? Comments and advice will be greatly appreciated! Thanks in advance, Jon Bullard [1] https://github.com/OpenVPN/openvpn/blob/master/doc/management-notes.txt#L983 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] what is best practice of location detection ?
HI, On Thu, Feb 15, 2018 at 10:46 PM, Selva Nairwrote: > Hi, > > On Tue, Feb 13, 2018 at 4:04 PM, David Sommerseth > wrote: >> On 13/02/18 17:21, Илья Шипицин wrote: >>> personally, I would like something like "preconnect script" which will check >>> something and decide "we are in a place, where vpn is not needed" >> >> This feature has been requested numerous times. And it is not needed. >> Really. You have the management interface which can be done to resolve >> exactly that problem. >> >> - OpenVPN is configured with --management and --management-hold >> >> - Start the management client script >> - polls for the OpenVPN management port to become available if it is not >> getting a connection instantly >> - once connected, it can do whatever queries/preparations needed >> - sends the 'hold release' command on the management inteface >> >> - OpenVPN starts connecting to the remote server >> >> And if OpenVPN looses its connection, the management interface can capture >> that and do whatever it needs to do. And if OpenVPN stops running/dies, this >> management client script can even detect that and do whatever is needed in >> this scenario as well - like restarting OpenVPN. >> >> In fact - you can even *modify* the remote and proxy settings on-the-fly if >> your management script figures that's even better. >> > > On Windows that's how the GUI starts and controls openvpn. So if any > preconnect activity is required it should be done through the GUI. Tunnelblick also uses the management interface to control the VPN, so it isn't available for uses such as the ones David proposes. Best regards, Jon -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] what is best practice of location detection ?
Hi, On Thu, Feb 15, 2018 at 10:43 PM, Selva Nairwrote: > The Windows GUI already supports a preconnect script. It waits on the > script for a user defined timeout seconds and abort the connection if > the script fails. Tunnelblick (GUI for macOS) also has "pre-connect" scripts; the connection attempt is aborted if the script fails (no timeout, though). Tunnelblick also has "connected" and "post-disconnect" scripts, too, along with a couple others. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Management interface "echo" command standardization
Hi, On Mon, Nov 27, 2017 at 2:23 AM, Steven Haigh <net...@crc.id.au> wrote: > On 2017-11-27 05:06, Selva Nair wrote: >> >> On Sun, Nov 26, 2017 at 10:49 AM, Jonathan K. Bullard >> <jkbull...@gmail.com> wrote: >>> >>> >>> This: >>> >>> echo "msg This message" >>> echo "msg will be shown" >>> echo "msg" >>> echo "msg on four lines (the third line is empty)." >>> echo "msg-window the title" >> >> >> That nicely solves the problem of when to display the message. > > > This seems to me to be a horrible solution that has been fixed in other > solutions for decades. > > We're doing string processing at this point - so why can't we use standard > string formatters: > \n = new line > \r = new line > \t = tab > > These have been standard for as long as I can remember - and I'm getting on. I think you're misunderstanding what program is doing what string processing (as I did until Selma clarified it for me). The escapes you describe ("\n", "\r", etc.) are processed by OpenVPN itself, not by GUIs such as Tunnelblick, and thus would already have been processed in the text of messages that the GUI receives from OpenVPN over the management interface. The only way to pass them through intact for the GUI to interpret them would be to double-backslash them (e.g. \\n), which might in some circumstances require yet another level (n). You can use multiple-backslash escaping for most characters if you want to include them in a message. However, commas cannot be included in strings "pushed" by the server, so we need a way to escape them that is _not_ processed by OpenVPN, so the escape sequence itself is passed intact to the GUI. Selma's proposal to use URL encoding (such as %2C for a comma) does just that. > This would allow you to combine everything into a single command. > > I feel it is a creep in the wrong direction to get the openvpn client to > piece together your message. If you want to display something, it should be > pieced together in your script, then sent to openvpn in a single, well > specified format. That won't work for "long" messages. (It's what I proposed until I understood the problems that need to be addressed.) And by "long" I mean "pretty short" : ) OpenVPN options (including echo and push) are limited to about 255 bytes. Those bytes would have to include the message itself, the message title, "push", "echo", whatever name we give the message command, and all separators, quoting and escaping. And some characters (all in some languages) require multiple bytes. So 255 is a very, very severe limitation. So we need a convention for expressing and then combining relatively short pieces of a message. The "msg" and "msg-n" proposal does that: it allows long lines to be created (using "msg-n"), and allows multi-line messages without escapes ("msg", with it's implied newline). Best regards, Jon -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] Fwd: Management interface "echo" command standardization
Hi, On Sun, Nov 26, 2017 at 1:06 PM, Selva Nair <selva.n...@gmail.com> wrote: > Hi, > > On Sun, Nov 26, 2017 at 10:49 AM, Jonathan K. Bullard <jkbull...@gmail.com> > wrote: >> >> Hi. (Top posting without quoting because I'm not reacting to specific >> comments.) >> >> I think Selva's approach of separate commands instead of separate >> fields in a single command is better for several reasons and withdraw >> my earlier proposal. > > > Me too :) > >> >> >> How about (1) the ability to append messages to each other, (2) a >> "msg" command which concatenates a newline to the text of a message, >> and (3) a "msg-n " command, which doesn't, and putting the title in >> the command that causes display? > > > This is a very good idea. > >> >> >> I think that would mean there is no need to escape anything or make >> any OpenVPN changes, and it's easy to generate, read, parse, and >> process. >> >> This: >> >> echo "msg This message" >> echo "msg will be shown" >> echo "msg" >> echo "msg on four lines (the third line is empty)." >> echo "msg-window the title" > > > That nicely solves the problem of when to display the message. > > One concern about quoting, though: As the most common use of > this will be to push from the server, those quotes will need to be > escaped. So I suggest an improvement: > > (i) If/when number of spaces between words is not significant, > quotes are not necessary as the option parser concatenates all > words after echo into one string with a single space between words. > > (ii) When space is significant as in your msg-n proposal below, quote > the message excluding the keyword "msg" or "msg-n" > > Then the echo command could be specified as > > echo msg This message > > and its pushed version becomes > > push "echo msg This message" > > When quoting is required to embed spaces or otherwise > > echo msg "This messageisstretched " > > and > > push "echo msg \"This message isstretched \" " > > or using single quotes > > push "echo msg 'This messageis stretched ' " > > etc. Quoting the message by itself makes it easier > on the eye, I guess. > > Users may still come up with creative ways of quoting as > what eventually gets displayed will be what comes through > the management interface after quote processing by the > parser at the server side for the push, and the client side > for the echo. We need only to carefully specify how the GUI > will interpret the received echo message. > >> >> would display the following in a non-modal popup window with title >> "the title". There is no need for an "OK" button if the window has a >> close button, but that could be implementation-defined behavior. >> >> = >> This message >> will be shown >> >> on four lines (the third line is empty). >> = >> >> >> And >> >> echo "msg-n this other message" >> echo "msg-n " > > > That could be > > echo msg-n '' > and > push "echo msg-n '' " > > (or use escaped double quotes). Arguably easier to read and write. > >> echo "msg-n will all be" >> echo "msg-n" > > > Such lines will have no effect, right? Yes, a line of echo "msg-n" will have no effect, since it would append an empty string to the pending message. >> echo "msg-n displ" >> echo "msg-n ayed on one line." >> echo "msg-window the title" >> >> which would display: >> >> == >> this other message will all be displayed on one line. >> == > > > Sounds good, otherwise. I agree with all of your above comments. As I understand it, all of that quoting is "outside" of the GUI. (That is, any quote marks that the GUI gets from the management interface are to be displayed to the user.) >> (All spaces after the first one that follows "msg" or "msg-n" are >> considered part of the text, I meant this to be the critical part that GUIs need to implement, and your quoting discussion above works for that. >> so there are lots of spaces between >
Re: [Openvpn-users] Management interface "echo" command standardization
Hi. (Top posting without quoting because I'm not reacting to specific comments.) I think Selva's approach of separate commands instead of separate fields in a single command is better for several reasons and withdraw my earlier proposal. How about (1) the ability to append messages to each other, (2) a "msg" command which concatenates a newline to the text of a message, and (3) a "msg-n " command, which doesn't, and putting the title in the command that causes display? I think that would mean there is no need to escape anything or make any OpenVPN changes, and it's easy to generate, read, parse, and process. This: echo "msg This message" echo "msg will be shown" echo "msg" echo "msg on four lines (the third line is empty)." echo "msg-window the title" would display the following in a non-modal popup window with title "the title". There is no need for an "OK" button if the window has a close button, but that could be implementation-defined behavior. = This message will be shown on four lines (the third line is empty). = And echo "msg-n this other message" echo "msg-n " echo "msg-n will all be" echo "msg-n" echo "msg-n displ" echo "msg-n ayed on one line." echo "msg-window the title" which would display: == this other message will all be displayed on one line. == (All spaces after the first one that follows "msg" or "msg-n" are considered part of the text, so there are lots of spaces between "message" and "will", "be" and "displayed" are separated by the second space after "msg-n" in "echo "msg-n displayed on one line", and "displ" and "ayed" are joined together because there is no such space in "msg-n ayed on one line".) What to do about wrapping lines that are too long (whatever that means : ) after concatenation would be implementation-defined. To display as a notification instead of a window, the last command would be replaced by: echo "msg-notify the title" To display a URL in a non-modal popup window with contents of URL "the_url" and title "this is the title", the sequence could be: echo "msg the_url" echo "msg-url this is the title" (One use of that would be to show a user _how_ to do something, like changing a setting in the GUI, instead of just telling them to do it.) Regarding length limits, I don't think we need to impose any limits beyond the limits imposed by OpenVPN. The OpenVPN limitation on the length of individual parameters and the limitation(s) of the buffers in the management interface are the two limits I know of. A note about those would be appropriate wherever these echo commands are documented (in the management interface doc, I assume). Keeping track of "pending" information (such as the text to be displayed to the user) must be considered: A. If a GUI disconnects from the management interface while the VPN is still connected and then later reconnects to the management interface. (Tunnelblick can do that -- we even let the user quit Tunnelblick or log out.) I'll probably have Tunnelblick save and restore any pending data in that situation. B. If the VPN disconnects or OpenVPN crashes while there is pending information, I think I'd just discard it on the assumption that it is incomplete and probably no longer relevant. Best regards, Jon -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Management interface "echo" command standardization
Thanks! Comments below. On Sat, Nov 25, 2017 at 12:27 PM, Selva Nair <selva.n...@gmail.com> wrote: > Hi, > > Thanks for summarising the status and proposals for echo commands. > > Comments below are based on what I have implemented in the > OpenVPN Windows GUI (Windows GUI in the following) and some > changes I've been working on. I refer to the client openvpn process > as the daemon or client daemon and the UI as Windows GUI or GUI. > > On Sat, Nov 25, 2017 at 10:24 AM, Jonathan K. Bullard <jkbull...@gmail.com> > wrote: >> QUESTIONS ABOUT THE OPENVPN WINDOWS GUI: >> >> 1. In the OpenVPN Windows GUI, do "forget-passwords", >> "save-passwords", and "disable-save-passwords" only affect >> auth-user-pass passwords, or do they also affect auth-user-pass >> usernames and private-key passwords? > > > Both auth-user-pass and private key passwords are affected by each > of those commands. Currently the Windows GUI unconditionally saves > the username but that can and may change. So let's say those commands > affect all passwords and possibly username. I'll have Tunnelblick forget both passwords and the username. That's more like the "forget-passwords" command from the GUI to OpenVPN, which, as I understands it, forgets everything. > Should we support a more fine-grained set of commands as well? Say: > > echo save-auth-username > echo save-auth-password > echo save-private-key-password > > etc., in addition to the blanket 'echo save-passwords' ? I do not think so. Agreed. >> 2. Does OpenVPN Windows GUI send OpenVPN a "forget-passwords" >> command via the management interface when it receives an "echo >> forget-passwords" command? (Note: there are two different > > > No it does not. > >> >> "forget-passwords" commands, each in a different direction: a >> "forget-passwords" command from the GUI to the OpenVPN client, and an >> "echo forget-passwords" command from the OpenVPN client to the GUI.) > > > The Windows GUI considers the password saving in openvpn client daemon > to be completely decoupled from that in the GUI itself. Just as auth-nocache > in > the config has no effect on the password saving feature of the GUI, > 'echo forget-passwords' does not trigger a 'forget-passwords' directive from > the GUI to the client daemon. > > The 'forget-passwords' command can still be sent from the GUI to the > client daemon based on some preferences setting of the GUI or explicit > user action. AFAIK, the Windows GUI does not have an option to do that. That makes sense to me, so Tunnelblick won't send "forget-passwords" to the client daemon when it gets an "echo forget-passwords" command. >> 3. How would the "setenv" command work? Would it be done by >> modifying OpenVPN itself to add a management interface command for the >> GUI to tell OpenVPN to set an environment variable for scripts, >> similar to the way the OpenVPN --setenv option works? OpenVPN itself >> seems to be designed to protect the client computer from the server as >> well as the other way around. (For example,"--pull-filter ignore".) An >> "echo setenv" command would break that protection if it modifies >> variables which have been set by "setenv" in the configuration file or >> --setenv in the command line. > > > What is proposed is 'echo "setenv x y"' to set env variables in the GUI > (actually in the scripts run by the GUI -- see below). Ah, I misunderstood and thought it was setting them for client daemon's scripts. It makes much more sense to set them for scripts run by the GUI. (I didn't know the OpenVPN GUI had such scripts.) I'll have Tunnelblick do it for the scripts that Tunnelblick runs, mangling the names as you describe later. > I view all echo directives as aimed at the GUI and thus do not require any > support from the daemon. I suppose you have a different usage in mind. > Note that it is already possible for the server to set env variables in the > client daemon by pushing 'setenv-opt'. > > In other words, no change in openvpn daemon is needed as the effect is to > have > env variables set in script processes directly run by the GUI, not those run > by openvpn daemon. Thus, these variables are totally independent of those > set > in the daemon itself by 'setenv' and 'setenv-opt' directives, but some of > the safety > features used there could be borrowed (see below): > > The GUI will receive the echo command as > > ECHO,1101519562,setenv name value > > which the GUI will use to define an env variable "mangled(x)
[Openvpn-users] Management interface "echo" command standardization
Inspired by a thread [1] about sending a message from the server to the client's GUI (and then displaying it to the user), I would like to discuss standardizing the management interface's "echo" commands. It would be nice if the OpenVPN Windows GUI, Tunnelblick, and other GUIs implemented the commands in a compatible way. Although this may be of interest to the OpenVPN developers, I think it is mostly of interest to OpenVPN users. (There isn't a list for "OpenVPN administrators", which would be the best target.) CURRENT STATUS OF THE ECHO COMMANDS Tunnelblick (I'm the developer) does not do anything with "echo" commands; it doesn't ask the management interface for them. According to an email in the above-referenced thread from Selva Nair, the OpenVPN Windows GUI currently implements the following: - "echo forget-passwords": delete passwords internally saved by the GUI but do not disable the password save feature. Useful when pushed from the server so that it gets processed after authentication. Also see management-notes.txt in openvpn docs. - "echo save-passwords": enables private-key and auth-user-pass passwords to be saved. Will be effective at startup only if present in the config file. If pushed from the server, will get used for subsequent password prompts. Essentially this has the effect of presenting the password dialogs to the user with save-password checkbox selected. The user may still uncheck it during the dialog. And the following are being considered: - "echo disable-save-passwords": stops the user from being able to save passwords. - "echo setenv": sets an environment variable for use by scripts. QUESTIONS ABOUT THE OPENVPN WINDOWS GUI: 1. In the OpenVPN Windows GUI, do "forget-passwords", "save-passwords", and "disable-save-passwords" only affect auth-user-pass passwords, or do they also affect auth-user-pass usernames and private-key passwords? 2. Does OpenVPN Windows GUI send OpenVPN a "forget-passwords" command via the management interface when it receives an "echo forget-passwords" command? (Note: there are two different "forget-passwords" commands, each in a different direction: a "forget-passwords" command from the GUI to the OpenVPN client, and an "echo forget-passwords" command from the OpenVPN client to the GUI.) 3. How would the "setenv" command work? Would it be done by modifying OpenVPN itself to add a management interface command for the GUI to tell OpenVPN to set an environment variable for scripts, similar to the way the OpenVPN --setenv option works? OpenVPN itself seems to be designed to protect the client computer from the server as well as the other way around. (For example,"--pull-filter ignore".) An "echo setenv" command would break that protection if it modifies variables which have been set by "setenv" in the configuration file or --setenv in the command line. 4. Does "echo save-passwords" override a (presumed) global setting that disables it? 5. Will "echo disable-save-passwords" override a (presumed) global setting that enables it? COMMENTS ABOUT TUNNELBLICK: A. Tunnelblick can/will implement "echo disable-save-passwords" (in addition to Tunnelblick's existing mechanism for doing so). The user will not have a way to override this (even a user who is a computer administrator, but I want to think more about that and may change my mind). It would also forget saved passwords as if the "echo forget-passwords" had been received, because that is what the OpenVPN Windows GUI will do (according to Selva). B. Tunnelblick can/will implement "echo forget passwords" but I need clarification of exactly which "passwords" it affects (see question 1, above) and whether Tunnelblick should instruct OpenVPN to forget passwords, too. I'm leaning toward doing that because I don't think there is any other way for the server to tell the OpenVPN client to forget its passwords, so it could be useful. C. Tunnelblick can/will implement "echo save-passwords" only for configurations that are not set up to to *disallow* it. D. Tunnelblick can/will implement "echo setenv" assuming the management interface is modified to implement a command to do it or there is some other acceptable way to do it securely. E. Tunnelblick's settings can affect all configurations or individual configurations, and each setting can be "protected" so that only a computer administrator can change it. That protection is set up when Tunnelblick or the configuration is installed. Best regards, Jon Bullard [1] https://sourceforge.net/p/openvpn/mailman/openvpn-users/thread/20171120151612.nbipfbmui74pdadn%40charite.de/#msg36130244 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users
Re: [Openvpn-users] Displaying messages to users by means of the GUI?
This thread has gotten away from its original subject: having the GUI display messages to the user. To summarize: 1. Static messages could be displayed by a "pre" script as Selva suggested, but that wouldn't be very portable. (Off the top of my head, on macOS I would have such a script use AppleScript to pop up a window to the user with the content. I assume there is a way to do the that on Windows.) 2. Dynamic messages (created by the server, for example) cannot currently be displayed to the user. (Except that the OpenVPN Windows GUI might include "echo" messages in the log -- I'm not sure about that -- but that's not highly visible to the user and Tunnelblick doesn't do even that.) 3. Neither the Windows GUI nor Tunnelblick currently implement anything to help with dynamic messages. They could be displayed if the OpenVPN server pushed a new "echo message" command. It would require agreement on the syntax and semantics of the new command, and for the GUIs to deal with it, but would not require any change to OpenVPN itself. I agree with Selva that it would be a good idea to standardize "echo" commands, so I will start a new thread about that. Best regards, Jon Bullard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Displaying messages to users by means of the GUI?
HI, Selva, and thanks for your input. On Mon, Nov 20, 2017 at 7:17 PM, Selvawrote: > Hi Jon, > >> >> Does the Windows GUI do anything with these "echo" parameters? > > > Very recently we added support for two echo "directives": > 'echo forget-passwords' and 'echo save-passwords': we use these as cue > to erase (or enable saving of) any saved passwords. Does "echo save-passwords" **force** the saving (without letting the user not save them?) Or does the Windows GUI give the user a choice? (Or does it always only give the users a choice if "echo save-passwords" was received?.) Does it save usernames, passwords, and passphrases (for keys), or just passwords? > Echo "commands" > are meant to be directives from openvpn (pushed from server or as present > in client config) to the GUI so no need to send it back to openvpn. OK, but It isn't clear to me what the OpenVPN client software does when it gets "forget-password": does it erase the password(s) **it** has saved in memory and then pass "forget-passwords" through the management interface? Or just pass it on without doing anything? > I plan to support "echo setenv .." as a way of asking the GUI to set > some vars in the env exported to scripts and may be directives like > 'echo disable-save passwords'. Thanks. I will probably do the same for Tunnelblick. (Sometime : ) Would "echo disable-save-passwords" (two hyphens, right?) make it so the user **can't** save passwords through the Windows GUI, and otherwise they would be able to? (I am not familiar enough with the Windows GUI to know if it usually offers that to the user; Tunnelblick offers separate checkboxes to save the username and password unless they are explicitly disabled via the configuration's Tunnelblick options.) > Interpreting something like 'echo msg "blah blah"' as a message to the user > could be a useful way of passing messages. Before we do that it would > be nice to have some standardization of echo directives. Absolutely! +1 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Displaying messages to users by means of the GUI?
Hi, On Mon, Nov 20, 2017 at 10:16 AM, Ralf Hildebrandtwrote: > My users primarily user Windows (OpenVPN-GUI), Tunnelblick. We do have > some Linux users (mainyly using NetworkManager) and even 4 ChromeOS > users. > > Is there any way for me to display informational messages on the > users's computer when they're loggin in via VPN? Depending on what you mean by "loggin in via VPN". Do you mean "connecting to the VPN server", or "logging into some service that is available on the network that they are communicating with via a VPN", or something else? Documentation [1] for the management interface's "echo" command says "Essentially the echo command allowed us to pass parameters from the OpenVPN server to the OpenVPN client, and then to the management client (such as a GUI)." Of course it requires the GUI (such as Tunnelblick) to do something with the "parameters". As far as I know, Tunnelblick doesn't currently do anything with these "parameters", but I'm open to extending Tunnelblick to do "something" with them. The documentation uses as an example a message of "forget-passwords" and Tunnelblick doesn't do anything with that (it could forget any passwords it has saved for the configuration, I suppose). It isn't clear to me exactly what the client does when it receives the "forget-passwords" command pushed from the server: does the client itself forget saved (in memory) passwords? Does it also send that through the management interface? I can imagine a "display-to-user" command with a UTF-8 string parameter which Tunnelblick could interpret by displaying a non-modal window with the message, but there are lots of other options (Tunnelblick could use the macOS "Notifications" instead of popping up a window, or it could allow for a title for the window, or it could allow HTML (with JavaScript?!!!) or, I suppose, anything. Does the Windows GUI do anything with these "echo" parameters? Best regards, Jon Bullard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] migrating from lzo to lz4
Hi, On Thu, Nov 16, 2017 at 5:45 AM, Ralf Hildebrandtwrote: > * Jan Just Keijser : > >> yes, pretty much: all clients that have 'comp-lzo' in the client config and >> that support LZ4 can be told to use LZ4 compression by adding >> push "compress lz4" >> in the server config. > > I have a mix of Windows (openvpn 2.3 and 2.4) > and Mac (openvpn 2.3 only, I wonder why TunnelBlick shuns 2.4?) clients > out in the field. Can you expand on that? Tunnelblick has included various versions of OpenVPN 2.4 (along with 2.3) for a long time, starting with a Tunnelblick release a year ago tomorrow that included OpenVPN 2.4.0_beta1. The current version (Tunnelblick 3.7.4a) includes OpenVPN 2.4.4 and OpenVPN 2.3.18. Tunnelblick beta versions often also include a version of OpenVPN built from the master branch when there are significant commits since the last OpenVPN release. (The current beta doesn't include one because I haven't seen much in the way of commits since 2.4.4 was released.) Best regards, Jon Bullard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] openvpn 2.4.3 and libressl 2.5 *only*?
On Tue, Jul 4, 2017 at 3:11 AM, Harald Dunkelwrote: > Hi folks, > > Maybe I was too blind to see, but I'd love to get a tunnel- > blick with the most recent openvpn 2.4.3 and libressl 2.5 > included *only*. > > Having several choices here (and using the out-of-date > versions by default) appears to be highly confusing to > the road warriors and the least stable configuration in > daily use. Hi, Note: The openvpn-users mailing list is not a good place for comments or questions about Tunnelblick, which is not part of OpenVPN. Please use the Tunnelblick Discussion Group [1] or file an Issue on GitHub [2] instead. That said, here is my answer to your comment (I'm the Tunnelblick developer): An official build of Tunnelblick with only the latest version of OpenVPN and LibreSSL (that is, not including OpenVPN 2.3.x and OpenSSL 1.0.1x) is not likely to happen for several reasons. You can build your own copy of Tunnelblick with whichever versions you want [3], or you can set up configurations to always use the latest Tunnelblick/LibreSSL versions, overriding the default [4]. Or you can remove undesired versions from official Tunnelblick builds and sign the resulting build yourself, or you can leave it unsigned (which might have some undesirable side effects). Please use the Tunnelblick Discussion Group or a GitHub issue for further discussion; I won't respond further in this mailing list. Best regards, Jon Bullard [1] https://groups.google.com/forum/#!forum/tunnelblick-discuss [2] https://github.com/Tunnelblick/Tunnelblick/issues [3] https://tunnelblick.net/source.html [4] https://tunnelblick.net/cPkgs.html -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Question about tls-crypt and port 443 firewall ducking
Hi. On Mon, Dec 19, 2016 at 7:10 PM, Kevin Longwrote: > I was just browsing the Mastering OpenVPN book and a paragraph jumped out at > me which basically said that using OpenVPN on port 443 is a common way people > try to duck firewalls. Indeed, this is what I do. My clients are all over > the place, airports, hotels, different countries etc, and we do seem to have > better luck on port 443 tcp than 1194 tcp or udp. > > But the book states, as I have just learned just recently coincidentally, > that OpenVPN traffic (even running on TCP) does not really look like normal > browser TLS traffic. > > > I saw in the release notes I believe, that the new tls-crypt feature helps > prevent metadata about auth certificates from being exposed, as well as > blocking deep-packet inspections of the traffic. One approach that could help would be to use obfsproxy. However that requires a separate program to be running on OpenVPN clients, which can be difficult for VPN service providers. Another approach would be to use the openvpn_xorpatch [1], which can be built into the OpenVPN client that VPN service providers supply to their clients and thus doesn't require a separate program. It adds a "scramble" option which obfuscates the traffic between an OpenVPN server and client, based on a shared secret. Although the patch is __disapproved__of__by__the__OpenVPN__developers__ (details on the Tunnelblick page), at least one VPN provider that I know of has found it helps their clients. I developed a version of the patch which fixes several bugs in the original. A somewhat out-of-date writeup is available at [2]. For the last 18 months my version has been included in copies of OpenVPN that are included in Tunnelblick [3] (a GUI for OpenVPN on macOS). There was recently a short discussion about it at GitHub Issue #347 [4]. In recent versions of Tunnelblick the patch is broken into five separate patches, with each patch modifying a single file. The patches can be found in the Tunnelblick source code [5] at third_party/sources/openvpn/openvpn-/patches, where is the OpenVPN version. The "master" branch of Tunnelblick includes patches for OpenVPN 2.3.14 and 2.4_rc1 (patches for 2.4_rc2 will be replace that within the next day or two). Older branches include the patch for older versions of OpenVPN. Best regards, Jon Bullard [1] https://forums.openvpn.net/viewtopic.php?f=15=12605=openvpn_xorpatch [2] https://tunnelblick.net/cOpenvpn_xorpatch.html [3] https://tunnelblick.net [4] https://github.com/Tunnelblick/Tunnelblick/issues/347 [5] https://tunnelblick.net/source.html -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Launching OpenVPN-GUI automatically on user login?
On Wed, Nov 30, 2016 at 10:14 AM, Selva Nairwrote: > Yes, no auto-connect, just the launch the GUI on login and stay as a tray > application. > > To toggle this click the checkbox at: GUI settings->General->Launch on > Windows startup (or its translated string) -- though it says "Windows > startup" its actually launched on user login... "Windows startup" is misleading, though, and should be changed to "Log into Windows" or similar. "Windows startup" says that it is started when Windows starts and could be misinterpreted as also starting a VPN connection when Windows starts up, especially if (now or in the future), the GUI can connect to a VPN when launched. FYI: A) Tunnelblick is launched automatically after it is installed. B) Tunnelblick launches on login if it was running when the user last logged out. C) Tunnelblick has a separate setting for each configuration to "Connect when system starts", "Connect when Tunnelblick launches", or "Connect manually". -- ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] options error: option 'setenv' cannot be used in this context ([PUSH-OPTIONS])
Hi. On Tue, Oct 25, 2016 at 11:53 AM, Selva Nairwrote: > Agreed, a way of having some unrecognized push options not tagged as an > error could be useful. If editing the client config is an option you can add > > pull-filter ignore block-outside-dns > pull-filter ignore register-dns > > That will cause those options pulled from the server to be silently ignored > (at --verb 3 level). > > --pull-filter is available in 2.4_alpha2 release. Tunnelblick 3.6.9beta01, released 2016-10-09, includes a "git-master" version of OpenVPN that I believe includes --pull-filter. It includes OpenVPN 2.3 git-master bae1ad7 dated 2016-10-07. The next Tunnelblick beta will include OpenVPN 2.4_alpha2. It is scheduled for release after OpenVPN 2.3.13, which as I understand it is due "soon". Best regards, Jon Bullard (Tunnelblick developer) -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] Fwd: openvpnstart returned with status #226
Sorry, forgot to cc: the mailing list. -- Forwarded message -- From: Jonathan K. Bullard <jkbull...@gmail.com> Date: Wed, Jul 20, 2016 at 10:09 AM Subject: Re: [Openvpn-users] openvpnstart returned with status #226 To: Chengyu Fan <chengyu@hotmail.com> See Tunnelblick's An OpenVPN log entry says "Tunnelblick: openvpnstart status #247: Error: Unable to load net.tunnelblick.tun and/or net.tunnelblick.tap kexts in 5 tries. Status = 71" <https://tunnelblick.net/cCommonProblems.html#an-openvpn-log-entry-says-tunnelblick-openvpnstart-status-247-error-unable-to-load-net.tunnelblick.tun-andor-net.tunnelblick.tap-kexts-in-5-tries.-status-71>. (The status number changed, but it is the same problem.) Note: The Tunnelblick Discussion Group <https://groups.google.com/forum/#!forum/tunnelblick-discuss> is the best place for questions specifically about Tunnelblick. On Wed, Jul 20, 2016 at 9:58 AM, Chengyu Fan <chengyu@hotmail.com> wrote: > Hi, > > > Does anyone have the issue below when using Tunnelblick? If yes, could > someone help me? > > > *Tunnelblick: OS X 10.11.5; Tunnelblick 3.6.5 (build 4566) > > 2016-07-20 21:39:16 *Tunnelblick: Attempting connection with client using > shadow copy; Set nameserver = 769; monitoring connection > > 2016-07-20 21:39:16 *Tunnelblick: openvpnstart start client.tblk 1337 769 > 0 1 0 1065330 -ptADGNWradsgnw 2.3.11 > > 2016-07-20 21:39:16 *Tunnelblick: openvpnstart starting OpenVPN > > 2016-07-20 21:39:26 *Tunnelblick: > > > Could not start OpenVPN (openvpnstart returned with status #226) > > > Contents of the openvpnstart log: > > *Tunnelblick: openvpnstart log: > > Loading tap-signed.kext > > stderr from kextload: > /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext failed to > load - (libkern/kext) kext (kmod) start/stop routine failed; check the > system/kernel logs for errors or try kextutil(8). > > stderr from kextload: > /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext failed to > load - (libkern/kext) kext (kmod) start/stop routine failed; check the > system/kernel logs for errors or try kextutil(8). > > stderr from kextload: > /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext failed to > load - (libkern/kext) kext (kmod) start/stop routine failed; check the > system/kernel logs for errors or try kextutil(8). > > stderr from kextload: > /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext failed to > load - (libkern/kext) kext (kmod) start/stop routine failed; check the > system/kernel logs for errors or try kextutil(8). > > stderr from kextload: > /Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext failed to > load - (libkern/kext) kext (kmod) start/stop routine failed; check the > system/kernel logs for errors or try kextutil(8). > > Unable to load net.tunnelblick.tun and/or net.tunnelblick.tap kexts > in 5 tries. Status = 71 > > > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports.http://sdm.link/zohodev2dev > ___ > Openvpn-users mailing list > Openvpn-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-users > > -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Fwd: "Safe" configurations for installation without admin privileges?
Thanks, Gert and JJK, and thanks again, Selva. Gert's original wish was to have the user replace expiring certificates without admin authorization (I expanded it enormously), so perhaps it should be limited it to do only that: allow users to change certain files that are referred to in an existing config file without an admin authorizing it. For example, only files in --askpass, --auth-user-pass, --cert, --key, and --pkcs12 options (maybe plus --ca, --dh, --extra-certs, and tls-auth). (Of course, this would be done by whitelisting.) This doesn't help those who distribute configs with inline keys/certificates, but it's much easier and safer to replace files than to modify a configuration file. -- ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Fwd: "Safe" configurations for installation without admin privileges?
(Gert replied to me privately because I (in error) sent privately to him. I have his permission to share his reply with the group, and am including my response.) On Thu, Dec 10, 2015 at 9:24 AM, Gert Doeringwrote: > Mmmh. Seems I will have to figure out how .tblk works, and how to generate > these on a unix box... in which case I can just give the users exactly > this. Right now I generate .ovpn which inline key/ca/cert, which can be > used across all platforms - but I'm willing to adapt :-) In the simplest case, a .tblk is just a folder containing a config file and all files associated with the config. When a folder has a name that ends in ".tblk" on a Mac, it is a "package" and to the user it looks like a single file (but to programs it is still just a folder). When a user double-clicks on a .tblk, Tunnelblick installs the configuration. (The install process involves copying the config and files to a "safe" place and securing them.) So you'd just create a folder, put the files in it, name it ending in .tblk, make a .zip of it, and send it to your users. A .tblk can have other .tblks inside it, so you can have your user double-click a single .tblk that installs several different configurations. A .tblk can also have an Info.plist (a standard kind of XML file on OS X) that has lots of powerful options, including options that make the .tblk "updatable". (Updates are checked for periodically, using the same mechanism that Tunnelblick uses to update itself.) The full documentation for .tblks is at https://tunnelblick.net/cPkgs.html > May I ask, for the sake of simplicity on the generating side, to accept > new "foo.tblk" files that contain the *same* openvpn.conf config, as > "update ca/key/cert material" instead of "new config"? > > (This way, on the generating side, we'd always just generate "the bundle > for the user". Initial install or "we change something in our servers > and need to change the config" would need admin intervention, "upgrade > user key and cert" would not...) Great idea, thanks! -- ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] Fwd: Fwd: "Safe" configurations for installation without admin privileges?
Sorry, forgot cc: again. Arrgghh. -- Forwarded message -- From: Jonathan K. Bullard <jkbull...@gmail.com> Date: Thu, Dec 10, 2015 at 9:01 AM Subject: Re: [Openvpn-users] Fwd: "Safe" configurations for installation without admin privileges? To: Gert Doering <g...@greenie.muc.de> On Thu, Dec 10, 2015 at 8:29 AM, Gert Doering <g...@greenie.muc.de> wrote: > This I can do today - by having a config file that just references > /Users/myuser/secret.p12 (outside tunnelblick's protection). Yes, but that doesn't work securely for configs that are shared among users on a computer without a lot of work that Tunnelblick does automatically for the files under its protection. > But this is not what I'm hoping for, which is "click on a file, make it > upgrade the config by magic" - assume users that have NO IT knowledge > whatsoever, but can be guided to "log in to that web site, click on > , then confirm installation into tunnelblick" > - this is the level of users we're dealing with. They wouldn't know > about "files" and "move to correct directory, replacing the file that > is already there"... This is getting off of the OpenVPN topic and into Tunnelblick, but: Sorry, I wasn't clear about how I would implement it: as a ".tblk without a configuration file" (which currently is treated as an error). For example, "foo.tblk" containing only a "user123.key" would replace the file "user123.key" in the "foo" configuration. Somebody -- in your case, whoever makes the download-- makes the download be a foo.tblk (a folder named "foo.tblk" containing a single file "user123.key"). The user just downloads it and double-clicks it. (Of course, the user will download it as a .zip, so he/she would also need to expand it if their browser doesn't do that for them.) The files would only be replaced if they existed in the configuration already, and only if they were referred to in the config file on an option on a whitelist. > So... what about the other angle of attacking this, running OpenVPN > with user privs? That's a much bigger change. It's on my long-term list. -- ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] "Safe" configurations for installation without admin privileges?
Inspired by Gert Doering (but don't blame him for any of my bad ideas : ), I'm considering adding a feature to Tunnelblick (a FOSS GUI for OpenVPN on OS X) that would allow a standard user on a Mac to install "safe" OpenVPN client configurations without requiring administrator credentials. This would simplify administration of small VPN networks: an user could download a new configuration and install it without being an administrator of his/her computer. My question is: what would a "safe" configuration file look like? Background: Tunnelblick launches OpenVPN as root and it usually stays running as root. To make sure that a standard user cannot use OpenVPN to obtain root access, Tunnelblick requires an administrator to authorize the "installation" of configurations. That installation involves creating a protected (writable only by root) copy of the configuration file and other files it references. At that point, the user cannot modify the configuration, so they can't get root access by, for example, adding or changing an --up script. The idea is to allow installation of a configuration file as long as it doesn't contain certain options that could give the user access they should not have. Here is my initial list: --up --tls-verify --ipchange --client-connect --client-disconnect --route-up --route-pre-down --client-disconnect --down --learn-address --auth-user-pass-verify --config --write-pid --status --log --log-append --tmp-dir (I created the above list from the 2.3 man page; I'll have to double-check it with the git-master code that processes options for the final list.) Typical client configuration files do not contain any of those options. (Tunnelblick includes some scripts that are "safe" and are executed at the user's option. These --up and --down scripts do such things as process DNS changes and make it unnecessary to have --up and --down scripts in the client configuration file.) I briefly considered using a "white list" of allowed options, and I may return to that, but there are so many options that would be a lot more typing : ) Using a blacklist is trickier, though, because I'd have to keep up with new options and add them to the blacklist as needed and failing to do so would result in a security vulnerability. I'm not sure if I should also prohibit networking options such as: --ifconfig* --route --iroute but am inclined to consider them "unsafe", too. They are usually "pushed" to the client, so that shouldn't affect many users. Tunnelblick already enforces restrictions on the use of options such as --key and --ca to ensure that they do not access anything the user shouldn't; that would of course be done for these "safe" configurations, too. Thoughts? -- ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] Fwd: "Safe" configurations for installation without admin privileges?
Sorry, forgot to cc: the list. -- Forwarded message -- From: Jonathan K. Bullard <jkbull...@gmail.com> Date: Wed, Dec 9, 2015 at 9:00 PM Subject: Re: [Openvpn-users] "Safe" configurations for installation without admin privileges? To: Selva Nair <selva.n...@gmail.com> Thanks. Comments below, but tldr; I don't think my original approach will work. On Wed, Dec 9, 2015 at 6:35 PM, Selva Nair <selva.n...@gmail.com> wrote: > Also I presume that some remote ends could be potentially controllable by (or > friendly to) the user and the user not to be given any privileges they > already do not have. Ah. Hadn't thought of the user specifying --remote (facepalm). Not allowing that is very restrictive, but allowing it opens a huge number of other problems. > When implemented in the UI (as in the Tunnelblick case), a blacklist of > options may become a maintanence nightmare. Whitelist may be a safer way. > With a possibility for an admin to completely disable this feature during > initial installation or later. Yes, that's a prerequisite as far as I'm concerned. > Though a whitelist is better, it looks more useful to hammer-out a blacklist > first, as you have done, so the rest follows that line of thought.. > Are status, log and log-append unsafe? Yes. When OpenVPN is running as root they can write over any file, including system files (but not, on OS X 10.11, the "Security Integrity Protection" files, which is most of the important system files. > I would add > --down-pre, --up-restart, --chroot, --cd, --nice, --plugin Yes, thanks. > There will be too many banned options that will eventually cripple the > config. So building the config from two pieces -- one specified by the admin > and one user specified piece --- or let the user override certain options may > be the way to implement this? Not my original idea, but an interesting approach. Whitelisting the user's safe override list might be possible but the more I think about it, I think it will be too restrictive to be useful. I describe a different approach below. > Below I assume that is the approach considered. > > With that in view, more options to freeze in the config: > > --script-security, > --remote and --server unless --secret or --ca (in tls mode) cannot be > changed (more on that below) Yes. Some are already disallowed by Tunnelblick. > But how is pushed options safe? By installing a config with just --remote and > a shared secret, a user could connect to some special end point and get any > route pushed. So if user defined configs and pushed routes are allowed, then > it essentially allows any route to be set up. Unless --server, --remote, > --mode etc cannot be over-ridden by the user, or --secret and/or --ca are > fixed. Yes : ( > --redirect-gateway and friends also may have to be frozen unless remote is > trusted and cannot be changed. Yes. > Does that mean --ca can be changed only by the admin? Yes. Tunnelblick makes the config file and all files referenced by it (including --ca files) read-only except by root. > There may be more concerns if the interface is bridged. Good point. Thank you for all of these comments. Lots to consider, but I think overall the "safe configurations" idea becomes either unsafe or not very useful. My original idea was that allowing the user to install "safe" configurations might be easier than one alternative I am considering, which is to allow Tunnelblick's "updatable configurations" to be replaced without admin approval. (They are controlled by the admin who set them up on Tunnelblick and are securely updated from servers specified in the (readable-by-root-only) configurations themselves that were set up by an admin. That's starting to look like a better, less complicated, more powerful alternative. Thanks again. Jon -- ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] DNS over VPN except vpnserver domain
On Mon, Aug 31, 2015 at 9:10 AM, Martin Lundwrote: > Hello All, > > I was thinking on how to solve this problem because starts to get > annoying. I have my linux machine connecting through openvpn with a script. > > After connecting my script replaces the dns servers in /etc/resolv.conf > with OpenDNS so all the DNS requests will be forwarded through the VPN > tunnel. > > The only problem is that if the VPN tunnel dies and it tries to re-resolve > the address it can't because those DNS requests will be sent through the > tunnel as well. > > Is there a solution for this? > Consider using a "down" script which restores the original DNS entries. Note that if the *--persist-tun* option is active, OpenVPN does not invoke the down script during (at least some types of) restarts, so you might need to avoid that option, too. And/or consider using the *--persist-remote-ip* option. -- ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] New OpenSSL release later today
New Tunnelblick releases with the updated OpenSSL versions will be available later today or tomorrow. On Thu, Jul 9, 2015 at 11:19 AM, Simon Deziel simon.dez...@gmail.com wrote: On 07/09/2015 11:15 AM, Jan Just Keijser wrote: Hi, Simon Deziel wrote: Hi *, So it seems that will require new Windows builds in the end. OpenSSL 1.0.1n and 1.0.1o are affected according to: https://www.openssl.org/news/secadv_20150709.txt AFAIU new builds will be made over the next few days. Excellent, thank you! And yes, theoretically speaking OpenVPN is vulnerable to this, but only if you are using openssl 1.0.1n or 1.0.1o or 1.0.2c . Those versions of OpenSSL were released less than 3 weeks ago, Indeed, on the server side this was a good surprise because most distro don't use such bleeding edge versions are were thus not affected so not too many people will be affected by it. The problem is with client versions where OpenVPN ships the latest 1.0.1 version available so Windows clients are affected. Also, not related to OpenVPN upstream but OSX Tunnelblick users are also affected by this. Regards, Simon -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] openvpn 2.3.6 on Mac OS
On Fri, Dec 19, 2014 at 6:28 AM, Jan Just Keijser janj...@nikhef.nl wrote: hi all, one of my colleagues is running into a strange problem with openvpn 2.3.6 on Mac OS: the routes pushed by the server all are rejected with the message option 'route' cannot be used in this context ([PUSH-OPTIONS]) the same config works on Linux, Windows and other Mac OS (Tunnelblick) clients. Hi, Assuming your colleague is running his or her own build of OpenVPN from the command line, it might be worth trying to runTunnelblick's build of OpenVPN from the command line instead. That would eliminate anything Tunnelblick is doing outside of OpenVPN. If it works OK, that would point to a problem with your colleague's build of OpenVPN. If it doesn't work, perhaps your colleague is not using sudo to launch OpenVPN, or something like that. Tunnelblick's copy of OpenVPN 2.3.6 is at /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.6/openvpn (after installing Tunnelblick 3.4.2 or 3.5beta02 by double-clicking Tunnelblick in a downloaded disk image). It might also be interesting to know what version of OS X your colleague is using. - Jon -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] openvpn 2.3.6 on Mac OS
On Fri, Dec 19, 2014 at 7:34 AM, Jan Just Keijser janj...@nikhef.nl wrote: Actually, he's running the Tunnelblick version of OpenVPN; the actual command line used was /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.6/openvpn config.ovpn (I'm not sure whether the --config was missing from the output he sent me) Tunnelblick launches OpenVPN and includes the --config option (I always assumed that was required), and the only other option that could have an effect that it uses is --script-security 2 (because Tunnelblick uses scripts for DNS processing). Perhaps without --script-security 2 the routing can't be done? It might also be interesting to know what version of OS X your colleague is using. 10.9.5 That shouldn't be a problem. (A full list of the options that Tunnelblick typically launches OpenVPN with to connect a private configuration (one not shared with other users of the computer) is: --daemon --log /Library/Application Support/Tunnelblick/Logs/NAME-OF-LOG-FILE.log --cd /Library/Application Support/Tunnelblick/Users/USER-NAME/NAME-OF-CONFIGURATION.tblk/Contents/Resources --config /Library/Application Support/Tunnelblick/Users/USER-NAME/NAME-OF-CONFIGURATION.tblk/Contents/Resources/config.ovpn --management 127.0.0.1 1337 --management-query-passwords --management-hold --script-security 2 --up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw ) Best regards, Jon -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] --redirect-gateway and IPv6
On my client, --redirect-gateway def1 adds a pair of IPv4 routes that direct all IPv4 addresses to the VPN. If a program sends packets to an IPv6 address in that situation, will the IPv6 traffic sent to the VPN? If not, is there a way to force that? Thanks. -- ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] --redirect-gateway and IPv6
Hi. On Sat, Oct 25, 2014 at 3:24 PM, Gert Doering g...@greenie.muc.de wrote: Hi, On Sat, Oct 25, 2014 at 03:12:18PM -0400, Jonathan K. Bullard wrote: On my client, --redirect-gateway def1 adds a pair of IPv4 routes that direct all IPv4 addresses to the VPN. If a program sends packets to an IPv6 address in that situation, will the IPv6 traffic sent to the VPN? If not, is there a way to force that? No. To get IPv6 into the VPN, you need a few things On the server: --server-ipv6 $address/bits- turn on IPv6, define transit network push ifconfig-ipv6 to client On the client: --tun-ipv6 --route-ipv6 $prefix/bits --route-ipv6 ::/0 - default route equivalent of course, all those can be pushed. IPv6 is really independent from IPv4 here - you can redirect one or the other, or both. Functionality that is lacking in 2.3 but need to be in 2.4: if you connect via IPv6 transport to a server, and that server redirects the IPv6 default route (like, redirect-gateway def1 for IPv6), it will fail, because the code doesn't understand how to setup a static host route for the VPN server yet - so it ends up routing recursively. So, as of today, if you want to redirect the IPv6 default route, you need to connect over IPv4. Thanks for your answer. Sorry to be so dense, but if I understand you correctly, the description of --redirect-gateway on the 2.3 man page: Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN. This is a client-side option. is incorrect when the VPN configurations (server and client) don't specifically enable IPv6? That is, IPv4 traffic is redirected over the VPN but IPv6 traffic is **not** redirected? So a more accurate description of --redirect-gateway would be: Automatically execute routing commands to cause all outgoing IPv4 traffic to be redirected over the VPN. This is a client-side option. -- ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] macox dns help for a novice?
On Wed, Sep 3, 2014 at 8:37 AM, Gert Doering wrote: On Wed, Sep 03, 2014 at 06:41:17PM +1200, Jason Haar wrote: Anyway, has anyone out there found out how to do this and is willing to share? :-) I have no direct answer, but maybe using Tunnelblick instead of raw openvpn would just solve this for you? (It's a very nice MacOS gui that bundles openvpn - just like the windows gui bundle) As the current Tunnelblick developer/maintainer, I appreciate Gert's kind words, but Tunnelblick does not do split DNS either. I've never been able to get it working -- in fact, I am hoping someone will respond to Jason's post with information or code so I could add this ability to Tunnelblick! -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Where are the 2.3.3 sources?
I have the same problem -- that the 2.3.3 .tar.gz gives a 404 not found. I can get the .zip and both of the GPG signatures, and everything else on the page. It is only the 2.3.3 .tar.gz that gets a 404. I am located in Connecticut, USA; my ISP is Cablevision. On Thu, Apr 10, 2014 at 5:13 AM, Robo Burned r...@list.ru wrote: Please ensure you are connecting to valid server. DNS substitution, MITM Name: swupdate.openvpn.org Addresses: 108.162.198.149 108.162.199.149 Trying http://108.162.198.149/community/releases/openvpn-2.3.3.tar.gz gets me a page with: Error 1003 Ray ID: 118e7843268601ee Direct IP access not allowed What happened? You've requested an IP address that is part of the CloudFlare network. as does the other IP address. So this does look like a CloudFlare problem. It probably should be looked into, but I successfully downloaded the .zip and built from it. I am assuming that they result in identical folders -- please let me know if that's not the case! -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Bug in easy-rsa vars script?
On Wed, Nov 13, 2013 at 3:24 AM, Sebastian Arcus s...@open-t.co.uk wrote: According to internet posts, this bug seems to have been lurking around for a while. Strangely, last time I used the easy-rsa scripts (maybe about a year ago), everything seemed fine. The vars script contains the following line: # This variable should point to # the openssl.cnf file included # with easy-rsa. export KEY_CONFIG=`$EASY_RSA/whichopenssl $EASY_RSA` I don't know when the change was introduced, but the copy of easy-rsa in Tunnelblick, version 2.0, taken from the OpenVPN source in March 2012 (before easy-rsa was separated from OpenVPN) has a different line: export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA` Because whichopensslcnf is a shell script residing in the easy-rsa folder, that makes more sense. So the line should read: export KEY_CONFIG=$EASY_RSA/whichopenssl Probably not -- I think it should read: export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA` The double-quotes are so spaces in the path contained in $EASY_RSA do not cause problems. (Tunnelblick contains a version of easy-rsa patched extensively to deal with such spaces; the problem occurs throughout easy-rsa 2.0.) -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users