Re: [Openvpn-users] openvpn dns resolution on osx

2021-06-07 Thread Jonathan K. Bullard
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

2020-08-03 Thread Jonathan K. Bullard
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

2020-04-29 Thread Jonathan K. Bullard
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

2020-04-16 Thread Jonathan K. Bullard
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

2020-04-16 Thread Jonathan K. Bullard
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

2019-09-18 Thread Jonathan K. Bullard
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

2019-09-18 Thread Jonathan K. Bullard
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)

2019-03-04 Thread Jonathan K. Bullard
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?

2018-10-01 Thread Jonathan K. Bullard
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?

2018-09-30 Thread Jonathan K. Bullard
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

2018-06-28 Thread Jonathan K. Bullard
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

2018-06-27 Thread Jonathan K. Bullard
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 ?

2018-02-15 Thread Jonathan K. Bullard
HI,

On Thu, Feb 15, 2018 at 10:46 PM, Selva Nair  wrote:
> 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 ?

2018-02-15 Thread Jonathan K. Bullard
Hi,

On Thu, Feb 15, 2018 at 10:43 PM, Selva Nair  wrote:
> 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

2017-11-27 Thread Jonathan K. Bullard
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

2017-11-27 Thread Jonathan K. Bullard
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

2017-11-26 Thread Jonathan K. Bullard
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

2017-11-25 Thread Jonathan K. Bullard
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

2017-11-25 Thread Jonathan K. Bullard
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?

2017-11-25 Thread Jonathan K. Bullard
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?

2017-11-20 Thread Jonathan K. Bullard
HI, Selva, and thanks for your input.

On Mon, Nov 20, 2017 at 7:17 PM, Selva  wrote:
> 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?

2017-11-20 Thread Jonathan K. Bullard
Hi,

On Mon, Nov 20, 2017 at 10:16 AM, Ralf Hildebrandt
 wrote:
> 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

2017-11-16 Thread Jonathan K. Bullard
Hi,

On Thu, Nov 16, 2017 at 5:45 AM, Ralf Hildebrandt
 wrote:
> * 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*?

2017-07-04 Thread Jonathan K. Bullard
On Tue, Jul 4, 2017 at 3:11 AM, Harald Dunkel  wrote:
> 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

2016-12-20 Thread Jonathan K. Bullard
Hi.

On Mon, Dec 19, 2016 at 7:10 PM, Kevin Long  wrote:
> 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?

2016-11-30 Thread Jonathan K. Bullard
On Wed, Nov 30, 2016 at 10:14 AM, Selva Nair  wrote:
> 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])

2016-10-25 Thread Jonathan K. Bullard
Hi.

On Tue, Oct 25, 2016 at 11:53 AM, Selva Nair  wrote:
> 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

2016-07-20 Thread Jonathan K. Bullard
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?

2015-12-10 Thread Jonathan K. Bullard
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?

2015-12-10 Thread Jonathan K. Bullard
(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 Doering  wrote:
> 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?

2015-12-10 Thread Jonathan K. Bullard
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?

2015-12-09 Thread Jonathan K. Bullard
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?

2015-12-09 Thread Jonathan K. Bullard
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

2015-08-31 Thread Jonathan K. Bullard
On Mon, Aug 31, 2015 at 9:10 AM, Martin Lund  wrote:

> 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

2015-07-09 Thread Jonathan K. Bullard
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

2014-12-19 Thread Jonathan K. Bullard
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

2014-12-19 Thread Jonathan K. Bullard
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

2014-10-25 Thread Jonathan K. Bullard
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

2014-10-25 Thread Jonathan K. Bullard
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?

2014-09-03 Thread Jonathan K. Bullard
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?

2014-04-10 Thread Jonathan K. Bullard
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?

2013-11-13 Thread Jonathan K. Bullard
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