Re: [Openvpn-devel] client-server customized session-id

[James Yonan]

On Wed, 6 Oct 2004 satind...@in.safenet-inc.com wrote:

> Hi,
>   I am implementing client-server openvpn with following additional
> requirement:
> Client-server should share a secret session-id provided by me while starting
> client and server. I dont want to keep this session-id in a file on client
> machine. Preferrable client will be started from an applet. This applet will
> give the session-id to openvpn instance. This session-id will be sent in
> each request from client to server. This session-id will be used to find out
> whether this is legitimate client instance or not. It will also be used to
> check the client'access policy for particular service. Its a kind of
> firewall with specific permissions for each client for accessing servers.

OpenVPN already has a session ID.  See session_id.c.

As far as checking access policies, there are already several ways of 
doing this.  In particular, see --client-connect and --learn-address.

James

Re: [Openvpn-devel] Pass log and passphrase between OpenVPN and OpenVPN GUI

[James Yonan]

On Tue, 5 Oct 2004, Mathias Sundman wrote:

> So to summarize:
> 
> SW=Service Wrapper
> 
> 1. The SW should redirect stdin/stdout/stderr through a pipe.
> 
> 2. The SW will write everything arriving on stdout/stderr to a logfile.
> 
> 3. The SW will monitor stdout/stderr for password prompts, and when it 
> sees one it will send a query over the already established TCP session to 
> the GUI, which will respond with the password. The SW then passes this 
> back to openvpn over the pipe.

I agree that only one TCP connection between GUI and SW is appropriate, 
even when the SW is controlling multiple openvpn processes.

> Is there any security issues with this we need to consider?

I think there should be some sort of admin password which the SW will 
expect before it grants access to a GUI process connecting as a TCP client 
on the SW's local socket.

> 4. The GUI will have to monitor the accual log file on disk in order to be 
> able to show the log in real-time. For this to work, it's important that 
> the SW flushes its write buffer to disk after every write.
> 
> Which is the best way of writing to a file, and making sure it's really 
> written to disk, on Windows?
>
> WriteFile(), fprintf(), fputs(), write()?

If you're using a FILE *, fflush() is usually sufficient.

I believe if you use native Win32 I/O such as WriteFile, the flush is 
immediate (not to say it physically goes to disk but rather that it is 
immediately available to another process which reads it.)

Another point:  Portability.  It would be nice to make a portable SW that 
would work on all the platforms that OpenVPN runs on.

James

> 
> On Tue, 5 Oct 2004, Didier Conchaudron wrote:
> 
> > Hi all,
> >
> > I agree with James for including several things such as monitoring 
> > stdin/out/err into the wrapper.
> >
> > But I'm not very ok for the idea of creating a socket for each connection 
> > because our users will probably only use one GUI so this GUI may have to 
> > discuss throught a unique socket to make things simpler. Now I agree that 
> > they're problems when we run several tunnels. I think of a system where 
> > each 
> > starting tunnel can ask, throught the same socket, a password or user/pass 
> > data just by adding a header like:
> >
> > foo.ovpn: asking private key password
> > foo2.ovpn: asking extended auth. username
> >
> > This way the GUI will have to handle just one socket, it could be then 
> > simpler to add features to GUI, ITOA it's harder for wrapper to add those.
> >
> > An other point is security. Actually the service wrapper need to run as 
> > SYSTEM/Admin rights, we have to limit the features and commands which will 
> > run as SYSTEM.
> >
> > Didier
> >
> > James Yonan wrote:
> >> On Fri, 1 Oct 2004, Mathias Sundman wrote:
> >> 
> >> 
> >>> Didier announced a first release of an improved version of the OpenVPN 
> >>> Service Wrapper earlier this week. The goal with this is to allow a non 
> >>> admin user on Windows to start/stop openvpn processes.
> >>> 
> >>> It does this by listening on a local TCP socket for commands like "START 
> >>> config.ovpn" or "STOP config.ovpn".
> >>> 
> >>> I've started working on OpenVPN GUI 2.0 that will use this service 
> >>> wrapper to control openvpn.
> >>> 
> >>> There is two things that remain unsolved though that I'd like to bring 
> >>> up for some discussion.
> >>> 
> >>> 1. How do we pass the private key passphrase from the GUI to the openvpn 
> >>> process?
> >>> 
> >>> 2. How do we get the openvpn log to the GUI so we can show it in real 
> >>> time in the status window?
> >>> 
> >>> 
> >>> I can see a couple of solutions:
> >>> 
> >>> A) We create a pipe between the openvpn process and the service wrapper. 
> >>> The service can then watch the openvpn output for the passphrase prompt, 
> >>> and pass on the request to the GUI over the TCP socket.
> >>> 
> >>> The log is then written to the log file by the service. The GUI will 
> >>> have to monitor this file for changes to be able to show the log in 
> >>> real-time.
> >>> 
> >>> 
> >>> B) We create another TCP socket for every launched process, and creates 
> >>> a pipe between this socket and the openvpn process. The GUI can then 
> >>> connect to this socket to recieve the log in real-time

Re: [Openvpn-devel] Again: Feature implementation: Connection refusal based upon CN

[James Yonan]

Vlada,

I think the idea for the patch is good, i.e. using the client-config-dir
as a kind of authenticator of common names.

I do have a concern though on your implementation.  You are conducting the
allow/deny test in multi_connection_established(). The problem is that
this function runs too late in the client instance initialization sequence
to be able to securely deny authentication.

There is a window of time between when the SSL/TLS state goes to S_ACTIVE
and when multi_connection_established is executed that you essentially
have a trusted session, and a malicious client could potentially exploit
that fact.  I think it would be better to put the test somewhere in ssl.c,
so that on failure, you can prevent the SSL/TLS state from advancing to
S_ACTIVE.  That is the idea behind verify_callback() and --tls-auth.

James


> Hello,
> 
> I'm writing again on the topic of my post sent several hours ago to the
> openvpn-users list. The post proposed the --ccd-exclusive option.
> 
> Since then I tried to setup chrooted openvpn server with the ccd
> directory in the jail as well as the tls-verify script which was
> checking the content of the ccd directory (see my previous post for the
> reason). Even when I hosted shell, tun device, some so's from /lib in
> the jail, openvpn was still unable to run my tls-verify script.
> 
> Nevertheless I didn't like the size of the jail directory after all. I
> decided to write the proposed feature on my own. So the 2.0-beta11
> source files, manual page was modified and an option helptexts was
> added. (I have to state, the work on such source text is a delight.)
> There was not clear to me, whether I kill the current instance
> gracefully, it needs some other eye to check it.
> 
> The implementation is tested. IMO it properly reacts on the removal and
> appearance of the CN-file in the client-config-directory.
> 
> I'm attaching the patch, because I hope someone else could find my
> contribution useful. Now I'm able to push the fixed IP addresses by the
> certificate CN as well as refuse non approved CN's from the single data
> source (ccd). My chroot jail now contains just a couple of non binary
> bytes. I'm happy for now. :-)
> 
> May I ask James to consider adding some form of this piece to the source
> of his wonderful program?
> 
> Vlada
> 
> 

Re: [Openvpn-devel] Pass log and passphrase between OpenVPN and OpenVPN GUI

[James Yonan]

On Fri, 1 Oct 2004, Mathias Sundman wrote:

> Didier announced a first release of an improved version of the OpenVPN 
> Service Wrapper earlier this week. The goal with this is to allow a non 
> admin user on Windows to start/stop openvpn processes.
> 
> It does this by listening on a local TCP socket for commands like "START 
> config.ovpn" or "STOP config.ovpn".
> 
> I've started working on OpenVPN GUI 2.0 that will use this service 
> wrapper to control openvpn.
> 
> There is two things that remain unsolved though that I'd like to bring up 
> for some discussion.
> 
> 1. How do we pass the private key passphrase from the GUI to the openvpn 
> process?
> 
> 2. How do we get the openvpn log to the GUI so we can show it in real time 
> in the status window?
> 
> 
> I can see a couple of solutions:
> 
> A) We create a pipe between the openvpn process and the service wrapper. 
> The service can then watch the openvpn output for the passphrase prompt, 
> and pass on the request to the GUI over the TCP socket.
> 
> The log is then written to the log file by the service. The GUI will have 
> to monitor this file for changes to be able to show the log in real-time.
> 
> 
> B) We create another TCP socket for every launched process, and creates a 
> pipe between this socket and the openvpn process. The GUI can then connect 
> to this socket to recieve the log in real-time, and can monitor this for 
> the passphrase prompt itself.

I like the idea of having the service wrapper control the 
stdin/stdout/stderr which is passed to the openvpn process, then have it 
send password(s) over stdin.

So the communication between the service wrapper and the openvpn processes 
would be via standard i/o handles and the communication between the 
service wrapper and the GUI would be over the management socket.

That means the service wrapper would need to be a proxy of sorts, passing 
passwords and possibly log file output as well between the GUI and openvpn 
processes.

James

Re: [Openvpn-devel] Win 32 Install script bug openvpn.nsi

[James Yonan]

On Wed, 29 Sep 2004, Remco Boom wrote:

> Hello all
> 
> In the file openvpn.nsi.in version 1.2.2.9, This is the most recent file 
> in CVS
> http://cvs.sourceforge.net/viewcvs.py/openvpn/openvpn/install-win32/openvpn.nsi.in?rev=1.2.2.9=markup
> I found a bug,  When you reinstall the same version openvpn the old tap 
> driver isn't removed and you endup with 2 tap drivers installed and 
> openvpn doesn't work.
> To fix it, just change the following in the nsi file:
> 
> At line 348 it says:
> nsExec::ExecToLog '"$INSTDIR\bin\tapinstall.exe" remove TAP'
> But is must be
> nsExec::ExecToLog '"$INSTDIR\bin\tapinstall.exe" remove ${TAP}'
> 
> At line 351 it says:
> nsExec::ExecToLog '"$INSTDIR\bin\tapinstall.exe" remove TAPDEV'
> This must be
> nsExec::ExecToLog '"$INSTDIR\bin\tapinstall.exe" remove ${TAPDRV}'
>  
> at line 353 
> TAPDEV must also be replaced bij ${TAPDRV}

Are you sure?

The TAP and TAPDEV strings are the actual names of previous TAP-Win32 
hardware IDs which we want to delete before installing the new TAP-Win32 
driver.

For example in OpenVPN 1.x, the hwid is "TAP".  If we change the NSIS code
to ${TAP}, now it will expand to "tap0801" which is the hwid for 2.0.  So 
we won't be deleting the old instance any longer, which is what this code 
is supposed to be doing.

James

Re: [Openvpn-devel] [PATCH] UDPv6 support (UDP/IPv6)

[James Yonan]

On Fri, 24 Sep 2004, JuanJo Ciarlante wrote:

> On Fri, Sep 24, 2004 at 10:39:59AM +0200, Matthias Andree wrote:
> > On Fri, 24 Sep 2004, JuanJo Ciarlante wrote:
> > 
> > > This README covers UDP/IPv6 ( --udp6 ) support for openvpn-2.0_beta11
> > > Also, with address family "generalization" changes came local AF_UNIX 
> > > socket
> > > support.
> > 
> > Is there a use for AF_UNIX in a VPN driver?
> 
> It stated in README file.. it allows the creation of local specialized
> proxys that can  take full advantage of POSIX fileystem perm. semantics.
> 
> Currently I;'m working on a Jabber one 8))
> regards...

I must say that the thought of running a VPN over Jabber is deliciously 
subversive :)

But I cringe when I think of the potential complexification in the sockets 
code.

We are already moving in the direction of having lots of transport layer
options (i.e. TCP, UDP, IPv4, IPv6, HTTP, Socks).  Now we're talking about
local unix sockets and Jabber!  Maybe it's time to formally codify a
transport layer driver model, i.e. a pluggable architecture.  Then people
can add new drivers to their heart's content, while OpenVPN itself will
conveniently interact with a generalized abstraction of the model.

James

Re: [Openvpn-devel] logging remote ip disconnection

[James Yonan]

On Mon, 20 Sep 2004, Kisero wrote:

> Hi, ive send two mails already and no answere..if imasking something
> wrong just tell me :)
> 
> i need to know when a remote ip address disconnect..i could not find
> anything on the man, or raising the verb level , or nothing. so i
> start looking at the source code to get a patch for myselfe..im not
> goot at al in #c , so maybe someone can help me out with this...
> :)
> 
> i saw that in socket.c at line 1128 you got a msg to the log
> 
> msg (D_CLOSE, "TCP/UDP: Closing socket");
> 
> when the peer goes down...
> 
> the function wich calls that,  gets "link_socket_close (struct
> link_socket *sock)" as a paramter, in the link_socket structure ,
> there is a memeber wich is another struct called "struct sockaddr_in"
> wich i think has the src ip address of the end point vpn wich is
> closing the socket.
> 
> but i couldnt make it work...
> does anyone have any idea? i dont knwo what else to do really.
> thanks a lot

When a remote address disconnects, the behavior is somewhat different 
depending on whether OpenVPN is running in TCP or UDP mode.  In TCP mode 
there is an explicit connection reset.  In UDP mode, because UDP is 
connectionless, the disconnection occurs due to a ping timeout, which can 
be controlled by inactive or ping and ping-restart/ping-exit.

If you want to run custom code when a client disconnects, you might take a 
look at the "client-disconnect" script directive.

James

Re: [Openvpn-devel] proxy ntlm support

[James Yonan]

William,

Thanks for the patch.

Have you tried it against the 2.0 beta series yet?

That's really the place where I will want to merge it.

Best Regards,
James

On Wed, 15 Sep 2004, William Preston wrote:

> 
> hello list,
> 
> here's a patch to add basic ntlm support to openvpn 1.6.0
> i've tested it with i386 linux & win32 against MS ISA proxy.
> 
> it includes base64 code from heimdal...
> 
> - hope it's useful to somebody.
> 
> William

Re: [Openvpn-devel] OpenVPN Licensing Issues

[James Yonan]

On Thu, 16 Sep 2004, Matthias Andree wrote:

> On Tue, 14 Sep 2004, James Yonan wrote:
> 
> > Therefore, in order for a dual licensing scheme to work, anyone who has ever
> > submitted code to the OpenVPN source code would need to agree to the dual
> > licensing scheme, since their code might now be potentially licensed under a
> > commercial license (in addition to the GPL).
> > 
> > There are different forms in which this agreement can be legally stated:
> > 
> > Here is Hans Reiser's version:
> > 
> > http://namesys.com/legalese.html
> > 
> > I'd like to invite some discussion on this idea, and I'd especially like
> > feedback from past OpenVPN contributors as to whether this is something they
> > could agree to.
> 
> IANAL, but the copyright system in considerable parts of Europe, among
> them Germany, my home country, is fundamentally different from the
> Anglo-American system, and I wonder if the Hans's legal agreement,
> particularly not having a salvatory clause, is a. valid and b.
> enforcable in Germany - and that the rights transfer to Hans is water
> tight is of interest to Hans's customer.
> 
> German copyright law is centered around the idea of an originator, and
> if I'm writing code, I am the originator, and will be, until the end of
> time. I cannot reassign my authorship.
> (OK, if I'm hired, the employer is officially the originator, but this
> involves payments of minimum salaries and, depending on work volume,
> social insurance.)

Another dual-license model that appears to be working (and not without a
little controversy) is the MySQL model, though I'm finding that there
seems to be a paucity of authoritative knowledge on how to set up a dual
licensing model in a way that works for everyone (given the nascent stage 
of the legal concept, it doesn't surprise me that it might not have been 
internationalized yet).

Even Lawrence Rosen's new book ("Open Source Licensing : Software Freedom 
and Intellectual Property") barely mentions dual-licensing.

> The idea that I am prohibited to sublicence my own contribution for
> money is daunting, and I'd think twice before submitting code for use
> under such an agreement.

Ideally, if it is legally feasible, I would ask OpenVPN contributors to 
grant me non-exclusive rights to sublicense under a commercial agreement.

As a matter of principle, I would not want to ask for more rights than is 
necessary to make the dual-licensing concept workable.

> I can see what Hans is aiming at, preventing licenses for proprietary
> work that is based on ReiserFS to float around, but Hans's agreement is
> unacceptable: suppose I'm writing two modules, all on my own. Module A is a
> standalone piece of code with a certain function but which can be sold
> to a project outside ReiserFS; Module B interfaces Module A to ReiserFS.
> 
> The agreement would mean I can either
> 
> - contribute _my_ Module A to ReiserFS, agree not to make money out of
>   it unless I'm willing to not sublicense under different licenses than
>   GPL and whatever other perpetual license or copyleft license Hans uses,
> 
> or
> 
> - sell it on my own, without adding to ReiserFS.
> 
> How the heck is that going to work?
> 
> What this means for OpenVPN:
> 
> 1. I retain authorship in my code no matter how often I write (C) James
>Yonan in the code
> 
> 2. I can certainly license the code with a perpetual right to
>sublicense, but for an _exclusive_ transfer of right to duplicate and
>relicense conditions would have to be different than Hans Reiser's.

I agree in principle, though I'm wondering if the motivation for requiring 
an exclusive transfer of rights is to avoid the complexities of trying to 
commercially license code that is a jigsaw puzzle of different copyrights.

James

Re: [Openvpn-devel] Microsoft digital signature warning pop up windows

[James Yonan]

On Tue, 14 Sep 2004, Russell Sutherland wrote:

> When one installs the current OpenVPN .exe NSIS install
> bundle on a WindowsXP or 2000 machine, a window pops
> up during the installation process saying something
> to the effect:
> 
> "Warning: this driver has not been signed/approved
>  by Microsoft quality control blah blah blah"
> 
> I believe that a similar pop up messages occurs when
> one trys to "run" the NSIS .exe file from a URL directly
> rather than downloading it first.
> 
> Is there any intention from the OpenVPN developers to
> "do the right thing" in order to remove these pops from
> the installation procedure?

I think this warning dialog is new.  I've only seen it once, after 
installing XP SP2.  Does this mean that the warning dialog will always 
accompany software installs unless the code has been signed by MS?

James

Re: [Openvpn-devel] Assertion failed at crypto.c:147

[James Yonan]

I've sent a message to the poster to get more info.  This assertion would 
happen if OpenVPN underestimated the maximum amount of cipher/HMAC 
overhead bytes which might be added to a packet.  I've never seen it 
before.

James

On Fri, 10 Sep 2004, Alberto Gonzalez Iniesta wrote:

> Hi all,
> 
> After returning from my holidays, I found the following two [1][2] bug
> reports in the Debian Bug Tracking System. I haven't had this problem
> and the source code says it should never happen :) so any hints would
> be appreciated.
> 
> Thanks,
> 
> Alberto
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265632
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=270005
> 
> -- 
> Alberto Gonzalez Iniesta   | BOFH excuse #178:
> agi@(agi.as|debian.org)| short leg on process table
> Encrypted mail preferred   | 
> 
> Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3
> 
> 
> ---
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM. 
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 

Re: [Openvpn-devel] Connect several subnets with OpenVPN2.0

[James Yonan]

On Wed, 8 Sep 2004, Robin G. Wenninger wrote:

> Hi list,
> 
> I have a kind of "problem" here.
> 
> I thought about connecting several subnets with 2.0 and for this purpose
> use the PUSH/PULL-Options.
> 
> So I used options like
>   push "route 10.0.0.0 255.255.255.0"
>   push "route 192.168.1.0 255.255.255.0"
> 
> To push all known subnets to the Clients. But the problem is, if I push
> route 10.0.0.0 255.255.255.0 to the Client which "owns" this subnet it
> overwrites the old routing entry and kicks its Subnet.
> 
> My recommendation would be a kind of exception list.
> Something like
>   push "route 10.0.0.0 255.255.255.0" except common-name
> 
> What do you think about this, is there any other (good to administrate)
> solution?

Interestingly enough, I think that this exception mechanism is already 
built into the way that IP routing works.

For example, suppose I push my all-inclusive /16 subnet:

  push "route 10.11.0.0 255.255.0.0"

Now suppose a client has taken a /24 subset of this range such as 
10.11.45.0/255.255.255.0.

The all-inclusive /16 route will match at a lower priority in the client's 
routing table than the client's private /24 subnet, so both subnets can 
coexist on the client.  The 10.11.45.0/255.255.255.0 subnet will match on 
any of the client's local traffic, while packets directed to 10.11.x.y 
will get routed back to the server when x is not equal to 45.

James

Re: [Openvpn-devel] openvpn using matrixssl ?

[James Yonan]

On Tue, 7 Sep 2004, gary wrote:

> Hi,
> 
> Anyone knows how feasible it is to use matrixssl instead of openssl ?
> The main advantage is memory footprint for embedded system like the
> linksys wrt54g.

It's possible, but development would be required.

To the extent that the matrixssl API differs from the OpenSSL API, OpenVPN
would need to be "ported" to matrixssl.

James

Re: [Openvpn-devel] Sending signals to a process in Windows

[James Yonan]

Mathias Sundman  said:

> I'd like my Windows OpenVPN GUI to be able to send signals to the openvpn 
> processes.
> 
> Is it possible to send signals (like SIGHUP, SIGUSR1) to processses in 
> Windows? How?

Windows doesn't really have signals like *nix.

When I want something signal-like I usually use a named Windows event object
(see CreateEvent).

Then if you have an event loop which you want to be signalable, just add the
handle returned by CreateEvent to the list of handles you are waiting for.

> If not, how do I pass a scancode (like a function key) to a Pipe? I've 
> used WriteFile() to pass the passphrase string, but that can only contain 
> ASCII chars, right?

Not sure about scancodes <-> pipes.  As far as getting scancodes, see the
win32_keyboard_get function in win32.c.

James

Re: [Openvpn-devel] psw in pem_passphrase_callback() static or not?

[James Yonan]

Mathias Sundman  said:

> When i first looked at the pem_passphrase_callback() function in ssl.c, I 
> though that the intention was to save the passphrase so the key could be 
> reloaded after a ping-restart, because you use:
> 
> static char passbuf[256];
> 
> So, I was surprised when my GUI now asked me for the passphrase a second 
> time (after a ping-restart).
> 
> A closer look at the function revealed that you do a CLEAR(passbuf) 
> before returning.

Yes, the intention is to only hold the password long enough to give it to
OpenSSL, when it calls pem_password_callback.

But the function is written in such a way that by not doing the
CLEAR(passbuf), the password will be cached across restarts.  Also
--persist-key might prevent OpenSSL from calling pem_password_callback again
on restart.

It might be useful to change this behavior to cache by default, and then have
an option to disable the caching.  In general, OpenVPN tries not to cache
sensitive data in virtual memory for longer than necessary.

> So, I just wonder, was the intention to save the passphrase or not? If 
> not, why do declare passbuf as static?

It's static because pem_password_callback is called twice.  Once to get the
password from stdin (called from options.c), and then once to return it to
OpenSSL (called from inside OpenSSL).

> Also, is it safe todo
> if (!strlen (passbuf)) 
> when passbuf has not get been assigned any string?

Yes, statics are guaranteed to be zeroed on program startup (unlike automatics).

James

Re: [Openvpn-devel] Patch: Output log message after routes is added

[James Yonan]

Mathias Sundman  said:

> --- forward-orig.c  Fri Jul 30 22:08:22 2004
> +++ forward.c   Sun Aug  8 09:48:21 2004
> @@ -243,6 +243,7 @@
> update_time ();
> event_timeout_clear (>c2.route_wakeup);
> event_timeout_clear (>c2.route_wakeup_expire);
> +  msg (M_INFO, "Finished adding routes to system.");
>   }
> else
>   {
> 
> 
> James, could you include this in next beta?

Yes, this is fine.  Regarding the details:

* I take it that you are using the M_INFO message level so you can be sure the
message will be in the log.  Normally I would want to use something like
D_ROUTE for this.  And even if M_INFO is used, it can still be silenced with
--verb 0.

* As is, the patch will cause the message to go to the log, even if there are
no routes to add.  In such a case, the message will be output showing the
point in time at which routes would have been added, had they been present in
the config.  So maybe the message should read differently, such as "TUN/TAP
interface up".

* The message will only be output if c->options.route_delay_defined is true. 
On Windows, this is always the case, so that's probably what you want.

James

Re: [Openvpn-devel] compiling statically - how?

[James Yonan]

Matthias Andree  said:

> On Wed, 04 Aug 2004, Tomasz Chmielewski wrote:
> 
> > I was thinking of an option like ./configure --compile-statically - and 
> > with such compiled binary, I wouldn't have to install compilers, compile 
> > OpenVPN, deinstall compilers on every machine I want it to run.
> 
> My first attempt would probably be ./configure CC="gcc -static" - it's
> untested and may require the installation of static libraries on some
> systems.

I've had success with 'gcc -static' when static libraries are present, as they
are by default on Gentoo Linux.

James

[Openvpn-devel] OpenVPN 2.0-beta8 released

[James Yonan]

This release has some cool new stuff, most notably TCP support in server mode.  
While all OSes which OpenVPN supports should be able to run as a multi-client 
TCP server, I've added an optimization for Linux 2.6 which takes advantage of 
the new linearly scalable sys_epoll API.  If you plan on running an OpenVPN 
TCP server with a larger number of concurrent clients (>50), you will see a 
noticeable performance benefit by using Linux 2.6.

Also included in this release is PKCS #12 support thanks to Mathias Sundman.  
PKCS #12 is a certificate/key file format which allows you to encapsulate the 
TLS certificate, key, and root certificate all in a single file.

There are a bunch of smaller changes as well on the Windows client -- routes 
are now added without requiring a call to route.exe and the --route-delay 
feature has become smarter, only waiting as long as necessary for the 
TAP-Win32 adapter to come up before adding routes.

2004.07.27 -- Version 2.0-beta8

* Added TCP support in server mode.
* Added PKCS #12 support (Mathias Sundman).
* Added patch to make revoke-crt and make-crl work
  seamlessly within the easy-rsa environment (Jan Kiszka).
* Modified --mode server ethernet bridge code to forward
  special IEEE 802.1d MAC Groups, i.e. 01:80:C2:XX:XX:XX.
* Added --dhcp-renew and --dhcp-release flags to Windows
  version.  Normally DHCP renewal and release on the TAP
  adapter occurs automatically under Windows, however
  if you set the TAP-Win32 adapter Media Status property
  to "Always Connected", you may need these flags.
* Added --show-net standalone flag to Windows version to
  show OpenVPN's view of the system adapter and routing
  tables.
* Added --show-net-up flag to Windows version to output
  the system routing table and network adapter list to
  the log file after the TAP-Win32 adapter has been brought
  up and any routes have been added.
* Modified Windows version to add routes using the IP Helper
  API rather than by calling route.exe.
* Fixed bug where --route-up script was not being called
  if no --route options were specified.
* Added --mute-replay-warnings to suppress packet replay
  warnings.  This is a common false alarm on WiFi nets.
* Added "def1" flag to --redirect-gateway option to override
  the default gateway by using 0.0.0.0/1 and 128.0.0.0/1
  rather than 0.0.0.0/0.  This has the benefit of overriding
  but not wiping out the original default gateway.
  (Thanks to Jim Carter for pointing out this idea).
* You can now run OpenVPN with a single config file argument.
  For example, you can now say "openvpn config.conf"
  rather than "openvpn --config config.conf".
* On Windows, made --route and --route-delay more adaptive
  with respect to waiting for interfaces referenced by the
  route destination to come up.  Routes added by --route
  should now be added as soon as the interface comes up,
  rather than after an obligatory 10 second delay.  The
  way this works internally is that --route-delay now
  defaults to 0 on Windows.  Previous versions would
  wait for --route-delay seconds then add the routes.
  This version will wait --route-delay seconds and then
  test the routing table at one second intervals for the
  next 30 seconds and will not add the routes until they
  can be added without errors.
* On Windows, don't setsockopt SO_SNDBUF or SO_RCVBUF by
  default on TCP/UDP socket in light of reports that this
  action can have undesirable global side effects on the
  MTU settings of other adapters.  These parameters can
  still be set, but you need to explicitly specify
  --sndbuf and/or --rcvbuf.
* Added --max-clients option to limit the maximum number
  of simultaneously connected clients in server mode.
* Added error message to illuminate shell escape gotcha when
  single backslashes are used in Windows path names.
* Added optional netmask parm to --ifconfig-pool.
* Fixed bug where http-proxy connect retry attempts were
  incorrectly going to the remote OpenVPN server,
  not to the HTTP proxy server.

James

Re: [Openvpn-devel] Re: Interface with GUI agent

[James Yonan]

On Tuesday 06 July 2004 16:58, Mathias Sundman wrote:
> Some more things to consider...
>
> 1. On Windows, if the the service wrapper has started some openvpn
> processes before our gui agent is started, how should find out about
> those processes?
>
> I can think of the following ways:
>
> 1a. Ask the service wrapper via the socket interface that I'm working on
> right now. This will require the service wrapper not only start the
> processes, but keep a table over running processes.

I think it's an important point worth some discussion on whether to (a) put 
all the "intelligence" in the GUI applet and have the service wrapper just be 
a basic proxy to an admin-privileged CreateProcess, or (b) write a portable 
service wrapper that's designed to run on all the OSes which OpenVPN 
currently supports, and which would do all the "under-the-hood" work in 
starting/stopping/managing of different OpenVPN processes, and the GUI applet 
would do nothing more than export the control interface of the portable 
service wrapper to a platform-specific, lightweight GUI.

(a) is probably simpler to develop, but (b) may be a better solution long-term 
because it handles the management interface in a portable way, and makes the 
GUI itself (which probably needs a separate admin module for Win32, YaST, X, 
http, etc.) as lightweight and stateless as possible.

Now the way I would implement (b) is to design as much of the "portable 
service wrapper" code as is possible without actually coding any function 
calls to create windows or dispatch window messages or do any GUI stuff 
directly.  The service wrapper would take care of instantiating OpenVPN 
processes, managing the 127.0.0.1 port pool to communicate with the 
processes.

Now the GUI applet itself becomes very simple and stateless, it only needs to 
connect to the service wrapper, and any window message corresponding to a 
user mouse action gets encoded into a simple command that gets sent to the 
service wrapper.

I agree that this is a more complicated problem to solve because now we have 
the service wrapper which is talking to the individual OpenVPN processes, and 
we have the GUI applet talking to the service manager.

But long term (IMHO) this gives us great flexibility to easily port the GUI 
applet to other interfaces, such as even http.  It would be very cool, for 
example, if with a little bit of php programming, you could control your 
OpenVPN instances via a web interface for example.  You wouldn't need to 
rewrite a huge program which deals with all the details of 
starting/stopping/managing the pool of OpenVPN processes, because that 
program would already exist as the cross-platform service wrapper daemon.

> 1b. Scan a defined directory for config files, and require the config
> files to have a management option. Then we can try connecting to the
> specified tcp port to find if there is a running ovpn process.

No, I don't think people should explicitly put the management option in their 
config files.

> 1c. Query the system for processes with the name "openvpn", and which
> sockets this process has opened. Then we could try connecting to those
> ports to find the management socket.

I don't like the idea of querying the system for "openvpn" processes (for one 
there's no portable API for querying the system for processes).  I would 
rather see the manager deal with managing a pool of local ports.

> I dislike 1b because it would complicate for the user, that he has to have
> the management option in his config-file. If using 1a that is handled
> automaticly by the gui or service wrapper.

I agree, the management option is something that should be programmatically 
placed on the command line by the program which does the CreateProcess to 
start the OpenVPN instantiation on a given config file.

> The drawback with 1a is, how do we handle the same thing on unix? There
> could be situations where we would like start the vpn before a gui agent
> here to. Are we back to what Jan K said, we need a "service wrapper" for
> unix to, that can run at al ltime as a deamon and keep track of our
> openvpn processes? It would require some extra work writing this deamon
> to, but it would give us a consistent way of starting openvpn processes
> from a gui agent regardless of the platform.

I'm not sure that we need to add the complexity of a service wrapper on unix, 
because most unix users take it as a matter of course that touching the 
network configuration requires root privileges.

I think it's fair to say that root is required, and if someone _really_ wants 
to control tunnels from non-root, then they must SUID the binary, or change 
the permissions on the tun/tap device node.

>
>
>
> 2. How should the service wrapper know which configs to launch at
> start-up? To maintain backwords-compatibility it should launch all config
> files in the config folder. However the gui agent should be able to
> handle both processes started at boot-time and other that is 

[Openvpn-devel] Re: Interface with GUI agent

[James Yonan]

On Tuesday 06 July 2004 04:25, Mathias Sundman wrote:
> On Tue, 6 Jul 2004, Jan Kiszka wrote:
> > If it's not a windows specific problem, then I suppost it's best to
> > add the functionallity in the openvpn binary so we get the
> > portability.
> 
>  I don't think the openvpn binary needs to know about this.  But the
>  service wrapper probably needs a second mode of operation, where
>  instead of getting its config files by scanning a directory, it
>  listens on a local socket for a command from the GUI to start an
>  openvpn.exe instance.
> >>>
> >>> Then don't forget that we will need a similar wrapper for unix as
> >>> well...

I'm not sure that we really need a wrapper for unix, because most unix users 
will control OpenVPN by:

(1) editing config files and starting from /etc/init.d, or
(2) using some sort of GUI-based admin tool such as YaST

and both of these methods are traditionally done as root.

> >> Why do we need a wrapper in unix? Can't the openvpn binary be run as a
> >> normal user in unix?
> >>
> >> If we need root-privs, what's wrong with installing openvpn as suid
> >> root and have it drop its privs after start-up?

Not a big problem, though some might prejudice a package which requires SUID.

> > Yes, this will work. But I'm afraid - maybe I'm wrong - that the GUI will
> > then have to be implemented quite differently on Windows and Unix. On
> > Windows, we would open a socket and both send the commands over it and
> > receive the status. On Unix, we would first start the process and then
> > connect to a socket for status information (BTW, which socket would then
> > be used when multiple instances of openvpn are running?).

Should the unix GUI be written for generic X, or should we develop admin 
modules for specific distros such as YaST?

I would go for the latter, because it will make the interface fit more 
seamlessly into a distribution's existing admin infrastructure.

> Yes and No. The way the GUI starts an openvpn process will have to
> implemented in diffrent ways for unix and windows. On Windows it will open
> a socket to the service wrapper and tell it to start an openvpn process
> with a specific config. On unix it will launch the openvpn process itself.
> This is not many lines of code so I think it can be handled with ifdefs
> quite cleanly.
>
> Then when the openvpn process has been started the gui connects to a
> socket that openvpn is listening on to receive status or send other
> commands that we can think of.
>
> The socket each openvpn process is listening on should be specified in the
> config-file with an option like "management 127.0.0.1 6001", where 6001 is
> the TCP port number. So each process should be listening on a unique port.
>
> A perhaps cleaner way is that the gui adds the manangement option when it
> starts the openvpn process, so the user don't have to bother setting the
> correct management option in his config-files.

I agree.  This is sort of like the way the current service wrapper passes 
--service to each OpenVPN process.

So the system-tray GUI manages a pool of 127.0.0.1 ports and allocates them to 
OpenVPN processes.

James

Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken

[James Yonan]

> >>Thinking ahead, the challenge/response sequence for passing
> >> authentication info should be open-ended to provide for future
> >> implementation of alternative authentication methods such as Radius,
> >> LDAP, NT Auth, etc.
> >
> > Please don't do too much of that. I've seen this auth featuritis creeping
> > in ntp and ups tools(!). Results ain't pretty...

I don't think that supplying a generalized authentication mechanism (that's 
method agnostic) will add very much complexity.

The way I see this working is that the SSL/TLS authentication still provides 
the real security.  But after SSL/TLS authentication has occurred, one still 
might want to submit some sort of credentials string to the server (obtained 
via GUI from the user) to determine the common name which will be assigned to 
the client.  In any case, OpenVPN on the server is probably going to 
interface with an authentication library which will handle all the details.

> > Reconfiguration of openvpn can always be done by editing config file
> > and restarting openvpn daemon. Simple. Elegant. No additional coding
> > - no risk of introducing bugs.
> >
> > This can be done via systray app, too.
>
> I can understand your concerns, and mostly you are right. However, there
> is one quite important scenario - at least as I see it - where you need
> the core daemon and the GUI running in different accounts: whenever the
> key or secret has to be looked away from the user while it shall still
> be possible for her/him to start/stop VPN connections. One reason for
> this may be that the key is bound to the device and not the user. The
> other one is security. Through this separation, malicious programs
> running in the context of the user can not so easily access the secret.
>
> And for those who don't trust this new interface (which will surely need
> a careful implementation): what about adding a configure switch and
> putting the respective code in some #ifdefs?

I agree -- the management interface should not be implicitly enabled by 
default.  You will need to specify the "management" config option to turn it 
on.

James

Re: [Openvpn-devel] [Patch] revoke scripts were broken

[James Yonan]

On Tuesday 29 June 2004 11:06, Jan Kiszka wrote:
> Hi all,
>
> here is a tiny patch to make revoke-crt and make-crl work seamlessly
> within the easy-rsa environment. Seems that no one used it before ;)

Thanks, I've merged for inclusion in beta8.

James

Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken

[James Yonan]

> I would furthermore suggest to discuss the required interface between
> the GUI and the OpenVPN daemon on this list. Starting and stopping would
> be possibly by just running the main binary, but I think a more
> sophisticated status and diagnosis interface requires some other
> mechanism (e.g. a local socket). Such an interface could furthermore
> prevent that the actual user who switches some configuration or just
> checks the status must own superuser privileges to start/stop a OpenVPN
> service and - even worse - read the secret key files.

Yes, I would like to see some kind of interface for control of OpenVPN from 
external programs.

The mechanism of the interface would be a socket on *nix or a named pipe on 
Windows.

The interface would primarily be for interaction with a GUI agent and would 
allow for:

* Stop/Restart control
* Get status (like SIGUSR2)
* Provide authentication info

James

Re: [Openvpn-devel] Enabling multicast on OpenBSD tun interface

[James Yonan]

Pavlin,

Thanks for the patch.  Is there any reason why someone might not want to have
multicast turned on by default, i.e. is there any chance this could break
something?  Should it be controllable by an option?

James

Pavlin Radoslavov  said:

> Hi!
> 
> [OS: OpenBSD-3.5]
> [openvpn: 2.0_beta5, 1.5]
> 
> It appears that openvpn doesn't enable the multicast flag for the
> tun interface on OpenBSD (on FreeBSD for example, the flag is always
> set). E.g., if I use:
> 
> openvpn --local <...> --remote <...> --ifconfig <...> <...> --dev tun0
> 
> Then the interface doesn't have the MULTICAST flag set:
> 
> tun0: flags=51 mtu 1500
> inet ...
> 
> I believe the following simple patch (against 2.0_beta5) fixes the
> problem.
> 
> Thanks,
> Pavlin
> 
> --- tun.c.org Sun Jun 13 00:34:28 2004
> +++ tun.c Tue Jun 15 23:24:58 2004
> @@ -1274,6 +1274,24 @@
>  open_tun (const char *dev, const char *dev_type, const char *dev_node, bool
ipv6, struct tuntap *tt)
>  {
>open_tun_generic (dev, dev_type, dev_node, ipv6, true, true, tt);
> +
> +  /* Enable multicast on the interface */
> +  if (tt->fd >= 0)
> +{
> +  struct tuninfo info;
> +
> +  if (ioctl (tt->fd, TUNGIFINFO, ) < 0) {
> + msg (M_WARN | M_ERRNO, "Can't get interface info: %s",
> +   strerror(errno));
> +  }
> +
> +  info.flags |= IFF_MULTICAST;
> +
> +  if (ioctl (tt->fd, TUNSIFINFO, ) < 0) {
> + msg (M_WARN | M_ERRNO, "Can't set interface info: %s",
> +   strerror(errno));
> +  }
> +}
>  }
>  
>  void
> 
> 
> ---
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

Re: [Openvpn-devel] IP adress assignment to tun devices using server mode

[James Yonan]

Torge Szczepanek  said:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi!
> 
> I am currently trying out OpenVPN 2.0 beta 4 using server mode.
> 
> My config on the server looks like this:
> 
> dev tun
> mode server
> ifconfig 192.168.100.1 192.168.100.2
> ifconfig-pool 192.168.100.4 192.168.100.254
> push "route 192.168.100.1 255.255.255.255"
> route 192.168.100.0 255.255.255.0
> [...]
> 
> Everything works fine as expected. (Which is really great. I appreciate the 
> good work done here)
> 
> I am wondering why there is a subnet of size /30 assigned to the client. I 
> would expect a Point-to-Point device to receive only one ip adress and not 
> a /30 subnet.

This is done for the benefit of OSes (such as Windows) which don't support
true point-to-point tun interfaces.

The Windows TAP-Win32 driver supports tun interface emulation only.  What that
means is that the driver can talk to tun interfaces on other OSes, but from
the perspective of Windows, it sees the tun interface as a virtual ethernet
interface having a subnet mask of 255.255.255.254, containing the two
point-to-point interfaces, a network address, and a broadcast address.

One of the goals of --mode server in OpenVPN 2.0 is that clients running any
OS can transparently connect to an OpenVPN server which is also running on any
OS, and the /30 subnet standardization was necessary to accomplish that.

> tun0  Protokoll:Punkt-zu-Punkt Verbindung
>   inet Adresse:192.168.100.6  P-z-P:192.168.100.5  
> Maske:255.255.255.255
>
> The netmask is also not which one would expect for a /30 network.

The server side tun netmask will be 255.255.255.255 except on Windows where it
will be 255.255.255.252

> I have some servers running with lots of ppp devices. I am assigning also 
> adresses out of a pool. The two addresses do not lie within the same subnet.
> 
> ppp138Link encap:Point-to-Point Protocol
>   inet addr:192.168.1.31  P-t-P:10.3.14.223  Mask:255.255.255.255
> 
> Is there any good reason for this /30 assignment?

> Is there a config option to change this behaviour (I didn't find one)?

For one, you don't need to use --ifconfig-pool, you could use DHCP for
example.  Or you could use --dev tap.

You could also change the code by passing IFCONFIG_POOL_INDIV instead of
IFCONFIG_POOL_30NET to ifconfig_pool_init in multi.c -- but at that point
you'll be on your own.  Windows compatibility will certainly break as well as
possibly other things.

> How many IPs can be assigned within a pool? 
> 
> I found:
> 
> #define IFCONFIG_POOL_MAX 65536
> 
> in pool.h
> 
> Has anyone tested this beyond a class-C network?

This maximum can be trivially increased, though I don't think most users will
be connecting 65536 clients to a single OpenVPN server instance :)

Some people might claim that using /30 subnets wastes IPv4 addresses, though I
don't think this argument holds much water because these addresses are mostly
(but not always) taken from private address blocks such as 10.x.x.x where
millions of free addresses are always available.

James

Re: [Openvpn-devel] how to implement the multi client in openvpn?

[James Yonan]

> > PS: could I use windows version as OpenVPN Server?
> 
> As a last resort only ;)

Actually, the OpenVPN server will run fine on Windows, though it may be
slightly less efficient than Linux on equivalent hardware.

James

[Openvpn-devel] Re: [Openvpn-users] OpenVPN 2.0-beta3 released

[James Yonan]

Rainer Sokoll <r.sok...@intershop.de> said:

> On Sun, Jun 06, 2004 at 01:35:27AM -0000, James Yonan wrote:
> 
> > * New feature: --status.  Outputs a SIGUSR2-like
> >   status summary to a given file, updated once
> >   per n seconds.  The status file is comma delimited
> >   for easy machine parsing.
> 
> With me, the file has setuid, setgid and sticky bits set. Is that
> intended?

No, that looks like a bug -- I will fix in beta4.

James

[Openvpn-devel] Re: Still Assertion failed at event.c:399 (was Re: [Openvpn-users] OpenVPN 2.0-beta3 released

[James Yonan]

Jon,

Have you considered the possibility that there might be breakage in your
compilation environment, such as a mismatch between header files and shared
libraries?

I am saying this because I haven't seen any other reports of similar assertion
failures.  If you are the only one seeing the problem, there must be something
that is unique about your particular configuration.

Do you get assertion failures from pre-built executables, such as from the
Windows install?

James

Jon Bendtsen  said:

> I still have my assertion error with openvpn beta3, just much sooner, 
> and it is a different place.
> The server is still linux, and the client is still macosx. I will go 
> and test windows in a few seconds.
> 
> 
> [Jon-Bendtsens-computer:~/openvpn-2.0_beta3] jonbendt% ./openvpn 
> --config ../etc/openvpn/client.conf
> ...
> Mon Jun  7 11:21:31 2004 OpenVPN 2.0_beta3 powerpc-apple-darwin7.4.0 
> [SSL] [LZO] built on Jun  7 2004
> Mon Jun  7 11:21:31 2004 WARNING: file 'sample-keys/client.key' is 
> group or others accessible
> Mon Jun  7 11:21:31 2004 Control Channel MTU parms [ L:1541 D:138 EF:38 
> EB:0 ET:0 EL:0 ]
> Mon Jun  7 11:21:31 2004 Data Channel MTU parms [ L:1541 D:1450 EF:41 
> EB:0 ET:0 EL:0 ]
> Mon Jun  7 11:21:31 2004 Local Options String: 'V3,dev-type 
> tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth 
> SHA1,keysize 128,key-method 2,tls-client'
> Mon Jun  7 11:21:31 2004 Expected Remote Options String: 'V3,dev-type 
> tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth 
> SHA1,keysize 128,key-method 2,tls-server'
> Mon Jun  7 11:21:31 2004 Local Options hash (VER=V3): 'a0f1c7ed'
> Mon Jun  7 11:21:31 2004 Expected Remote Options hash (VER=V3): 
> 'b319fa3e'
> Mon Jun  7 11:21:31 2004 Socket Buffers: R=[42080->65536] 
> S=[9216->65536]
> Mon Jun  7 11:21:31 2004 UDPv4 link local (bound): [undef]:5000
> Mon Jun  7 11:21:31 2004 UDPv4 link remote: 192.168.119.135:5000
> Mon Jun  7 11:21:31 2004 TLS: Initial packet from 192.168.119.135:5000, 
> sid=1ce6aa53 b7120113
> Mon Jun  7 11:21:31 2004 Assertion failed at event.c:399
> Mon Jun  7 11:21:31 2004 Exiting
> 
> It makes no difference if i specify the local address, the client.conf 
> file looks like this:
> 
> 
> [Jon-Bendtsens-computer:~/openvpn-2.0_beta3] jonbendt% less 
> ../etc/openvpn/client.conf
> #
> # Sample client-side OpenVPN config file
> # for connecting to multi-client server.
> #
> # The server can be pinged at 10.8.0.1.
> #
> # This configuration can be used by multiple
> # clients, however each client should have
> # its own cert and key files.
> #
> # tun-style tunnel
> 
> port 5000
> dev tun0
> remote aragorn
> 
> # TLS parms
> 
> tls-client
> ca sample-keys/tmp-ca.crt
> cert sample-keys/client.crt
> key sample-keys/client.key
> 
> # This parm is required for connecting
> # to a multi-client server.  It tells
> # the client to accept options which
> # the server pushes to us.
> pull
> 
> verb 4
> 
> 
> and the server:
> 
> # Sample OpenVPN config file for
> # multi-client udp server
> #
> # tun-style tunnel
> 
> port 5000
> dev tun
> 
> # TLS parms
> 
> tls-server
> ca sample-keys/tmp-ca.crt
> cert sample-keys/server.crt
> key sample-keys/server.key
> dh sample-keys/dh1024.pem
> 
> # Tell OpenVPN to be a multi-client udp server
> mode server
> 
> # openvpn data are not swapped to disk
> #mlock
> # allow clients to connect to each other faster
> #client-to-client
> 
> # The server's virtual endpoints
> ifconfig 10.8.0.1 10.8.0.2
> 
> # Pool of /30 subnets to be allocated to clients.
> # When a client connects, an --ifconfig command
> # will be automatically generated and pushed back to
> # the client.
> ifconfig-pool 10.8.0.4 10.8.0.255
> 
> # Push route to client to bind it to our local
> # virtual endpoint.
> push "route 10.8.0.1 255.255.255.255"
> 
> # Delete client instances after some period
> # of inactivity.
> inactive 600
> # ping once every minute when there is no trafic
> ping 60
> 
> # Route the --ifconfig pool range into the
> # OpenVPN server.
> route 10.8.0.0 255.255.255.0
> 
> # The server doesn't need privileges
> user nobody
> group nogroup
> 
> 
> 
> JonB
> 



-- 

Re: [Openvpn-devel] OpenVPN 2.0 Yo-Yo effect...

[James Yonan]

Denis Vlasenko  said:

> On Saturday 05 June 2004 21:46, Mike Auty wrote:
> > Thanks for the super fast reply,
> > Sadly I don't have the facilities to build a new windows version.
> > Would you mind exaplaining briefly what it does?  It only seems to
> > change the order of two checks, but I'm not sure what they do.  Thank
> > again, Mike  5:)
> 
> If there happens to be a packet to send when openvpn checks whether
> it needs to send a ping, openvps erroneously decide to set ping
> interval timeout to 365 days.

This is a known bug in 2.0-beta2 and will be fixed in beta3 which I expect to
release within a day or two.

James

Re: [Openvpn-devel] Radius support, was: Re: [Openvpn-users] Is it possible to assign a specific ip address to a certificate?

[James Yonan]

Denis Vlasenko <v...@port.imtp.ilyichevsk.odessa.ua> said:

> On Saturday 29 May 2004 01:34, James Yonan wrote:
> > Jaye Mathisen <mr...@internetcds.com> said:
> > > It would be nice if openvpn could be configure to work with radius for
> >
> > routing and
> >
> > > IP assignment after the certificate was done.  Would allow openvpn to be
> >
> > integrated easily
> >
> > > with existing infrastructure, instead of having to have a whole new
> > > system
> >
> > to maintain
> >
> > > information about it.
> >
> > There have been several requests for radius support, and while it's
> > something I'd like to see done, I'm not going to have time to do it for
> > 2.0.
> >
> > This is the sort of thing where it would be ideal if someone else takes the
> > lead -- I would certainly be happy to technically support anyone who wants
> > to take the project on.
> 
> 802.11x can be trivially attacked. Read the RFC. I don't see why
> shall I use broken protocol.

True, however the suggestion was to use radius only for IP address assignment
and routing, not for authentication.

James

[Openvpn-devel] Radius support, was: Re: [Openvpn-users] Is it possible to assign a specific ip address to a certificate?

[James Yonan]

Jaye Mathisen  said:

> It would be nice if openvpn could be configure to work with radius for
routing and
> IP assignment after the certificate was done.  Would allow openvpn to be
integrated easily
> with existing infrastructure, instead of having to have a whole new system
to maintain
> information about it.

There have been several requests for radius support, and while it's something
I'd like to see done, I'm not going to have time to do it for 2.0.

This is the sort of thing where it would be ideal if someone else takes the
lead -- I would certainly be happy to technically support anyone who wants to
take the project on.

James

Re: [Openvpn-devel] [BUG] sometimes --ping 30 stops: select() timeout=31536000 seconds (exactly one year)!

[James Yonan]

Denis,

That looks like a possible bug in the coarse timer update logic.  The coarse
timer deals with events scheduled at a resolution denoted by an integer number
of seconds, such as pings.  A timeout of one year is used as kind of
"effectively infinite" time interval.  If you see this large timeout, it means
that the ping event is losing its place in the coarse timer event queue --
probably a bug.

James

Denis Vlasenko  said:

> I was puzzled why sometimes openvpn ceases to generate
> '--ping 30' packets. I instrumented it a bit,
> here is a pseudo-patch:
> 
> errlevel.h:
> +#define D_PING   LOGLEV(4, 0, 0) /* show --ping packets 
> */
> 
> -#define D_INTERVAL   LOGLEV(8, 70, M_DEBUG)  /* show interval.h
debugging info */
> +#define D_INTERVAL   LOGLEV(4, 70, M_DEBUG)  /* show interval.h
debugging info */
> 
> ping-inline.h: (check_ping_send now will explain why it do not send pings)
> static inline void
> check_ping_send (struct context *c)
> {
>   void check_ping_send_dowork (struct context *c);
>   if (!c->options.ping_send_timeout) { msg (D_PING, "PING:
!c->options.ping_send_timeout"); return; }
>   if (c->c2.to_link.len) { msg (D_PING, "PING: c->c2.to_link.len <> 0");
return; }
>   if (!event_timeout_trigger (>c2.ping_send_interval, >c2.timeval))
> { msg (D_PING, "PING:
!event_timeout_trigger(%ld,%ld)",(long)(c->c2.ping_send_interval.last),
(long)c->c2.timeval.tv_sec); return; }
> check_ping_send_dowork (c);
> }
> 
> ping.c:check_ping_send_dowork (struct context *c): (log pings)
> ...
>encrypt_sign (c, true);
> +  msg (D_PING, "PING: SENT");
> }
> 
> forward.c:void single_select (struct context *c): (log large select timeouts)
> ...
>   /*
>* Wait for something to happen.
>*/
>   c->c2.select_status = 1;  /* this will be our return "status" if
select doesn't get called */
>   if (!c->sig->signal_received && !SOCKET_READ_RESIDUAL (c->c2.link_socket))
> {
>   if (check_debug_level (D_SELECT))
> show_select_status (c);
> 
> + if(((unsigned long)c->c2.timeval.tv_sec) >= 28) { //vda
> +   msg(D_PING, "PING: select timeout=%ld", (long)c->c2.timeval.tv_sec);
> + }
>   c->c2.select_status = SELECT (>c2.event_wait, >c2.timeval);
>   check_status (c->c2.select_status, "select", NULL, NULL);
> }
> 
> 
> With --ping 30, select shall _never_ have timeout>30 secs, right?
> 
> I was lucky. Bug struck me soon after I restarted openvpn.
> Here is the full log:
> 
> Fri May 28 22:59:11 2004 Current Parameter Settings:
> Fri May 28 22:59:11 2004   config = '[UNDEF]'
> Fri May 28 22:59:11 2004   mode = 0
> Fri May 28 22:59:11 2004   persist_config = DISABLED
> Fri May 28 22:59:11 2004   persist_mode = 1
> Fri May 28 22:59:11 2004   show_ciphers = DISABLED
> Fri May 28 22:59:11 2004   show_digests = DISABLED
> Fri May 28 22:59:11 2004   genkey = DISABLED
> Fri May 28 22:59:11 2004   askpass = DISABLED
> Fri May 28 22:59:11 2004   show_tls_ciphers = DISABLED
> Fri May 28 22:59:11 2004   proto = 0
> Fri May 28 22:59:11 2004   local = '1.1.4.1'
> Fri May 28 22:59:11 2004   remote_list[0] = {'1.1.4.2', 8002}
> Fri May 28 22:59:11 2004   remote_random = DISABLED
> Fri May 28 22:59:11 2004   local_port = 8002
> Fri May 28 22:59:11 2004   remote_port = 8002
> Fri May 28 22:59:11 2004   remote_float = DISABLED
> Fri May 28 22:59:11 2004   ipchange = '[UNDEF]'
> Fri May 28 22:59:11 2004   bind_local = ENABLED
> Fri May 28 22:59:11 2004   dev = 'tun'
> Fri May 28 22:59:11 2004   dev_type = '[UNDEF]'
> Fri May 28 22:59:11 2004   dev_node = '[UNDEF]'
> Fri May 28 22:59:11 2004   tun_ipv6 = DISABLED
> Fri May 28 22:59:11 2004   ifconfig_local = '1.1.5.1'
> Fri May 28 22:59:11 2004   ifconfig_remote_netmask = '1.1.5.2'
> Fri May 28 22:59:11 2004   ifconfig_noexec = DISABLED
> Fri May 28 22:59:11 2004   ifconfig_nowarn = DISABLED
> Fri May 28 22:59:11 2004   shaper = 0
> Fri May 28 22:59:11 2004   tun_mtu = 1434
> Fri May 28 22:59:11 2004   tun_mtu_defined = ENABLED
> Fri May 28 22:59:11 2004   link_mtu = 1500
> Fri May 28 22:59:11 2004   link_mtu_defined = DISABLED
> Fri May 28 22:59:11 2004   tun_mtu_extra = 0
> Fri May 28 22:59:11 2004   tun_mtu_extra_defined = DISABLED
> Fri May 28 22:59:11 2004   fragment = 0
> Fri May 28 22:59:11 2004   mtu_discover_type = -1
> Fri May 28 22:59:11 2004   mtu_test = 0
> Fri May 28 22:59:11 2004   mlock = DISABLED
> Fri May 28 22:59:11 2004   inactivity_timeout = 0
> Fri May 28 22:59:11 2004   ping_send_timeout = 30
> Fri May 28 22:59:11 2004   ping_rec_timeout = 0
> Fri May 28 22:59:11 2004   ping_rec_timeout_action = 0
> Fri May 28 22:59:11 2004   ping_timer_remote = DISABLED
> Fri May 28 22:59:11 2004   persist_tun = DISABLED
> Fri May 28 22:59:11 2004   persist_local_ip = DISABLED
> Fri May 28 22:59:11 2004   persist_remote_ip = DISABLED
> Fri May 28 22:59:11 2004   persist_key = DISABLED
> Fri May 28 22:59:11 2004   mssfix = 1450
> Fri May 28 22:59:11 

Re: [Openvpn-devel] Trying to use zlib with openvpn

[James Yonan]

Ming-Ching Tiew  said:

> 
> Last night after posting to openvpn-user maillist about
> wanting to use zlib with OpenVPN, I had a look at the 
> code. It seems the compression code is well-contained 
> in lzo.c, I could even do a one-to-one swap of 
> 'LZO_COMPRESS' with zlib's 'compress' and similarly
> for decompress. It get compiled and linked. I was quite
> glad about that !!!
> 
> But of course, it is not so simple, it ran and crashed with
> segmentation fault. I now suspect the decompression 
> memory allocation is not big enough. Any clues
> where else I should look at ?

Make sure that you define

#define LZO_EXTRA_BUFFER(len) ((len)/64 + 16 + 3)   /* LZO worst case size
expansion. */

for zlib.

James

Re: [Openvpn-devel] openvpn-2.0_beta1: tunnel MTU a bit too large

[James Yonan]

Denis Vlasenko <v...@port.imtp.ilyichevsk.odessa.ua> said:

> On Sunday 16 May 2004 23:49, James Yonan wrote:
> > Denis,
> >
> > There are two ways of setting the MTU in OpenVPN, one is to use --tun-mtu
> > which doesn't include any encapsulation overhead, the other is to use
> > --link-mtu which sets the maximum encrypted UDP datagram size sent between
> > OpenVPN daemons after encapsulation.
> 
> A bit misleading name. Both ifconfig and ip tools report MTU
> as maximum size of whole IP packet, not UDP packet encapsulated
> in IP packet. Do you say that --link-mtu means UDP packet size,
> not IP?

--link-mtu doesn't include the IP header size or ethernet header size of the
carrier protocol.

> Can it be the case that openvpn code itself use different
> meanings of --link-mtu in different parts of code?

No, link MTU should always mean --tun-mtu + encapsulation overhead.

> > 2.0 takes a different approach to earlier version of OpenVPN on this.  1.x
> > tries to use a lower MTU to get around fragmentation problems.  But since
> > MTU=1500 is a kind of industry standard for ethernet networks, lowering it
> > can cause problems.  So the 2.0 approach is to set the MTU to 1500 and then
> > use --mssfix 1450 by default.
> 
> It's not a proper fix. IP traffic shall work through path of any valid MTU.
> Artificially keeping tunnel MTU=1500 is a hack.

> Think about multi-gigabit nets of the future: do you still want MTU=1500
> everywhere?

No, the MTU can be set to whatever you want.  There is no limitation.  The
MTU=1500, MSSFIX=1450 is just a default that works well across a large range
of OSes and routers.

> Think about lossy links with small 'real' MTU: with tunnel MTU=1500
> UDP/ICMP/other being packets fragmented and some fragments lost, you
> get horrible performance of e.g. NFS over UDP.

There are a lot of ways you can deal with fragmentation.  OpenVPN gives you
--fragment, --mssfix, --tun-mtu, and --link-mtu.  For UDP application
protocols, like NFS, you can also tell the app directly what kind of packet
size to use to avoid fragmentation.  This is the best approach when using NFS.
 I don't have any trouble running NFS over OpenVPN.

> > This will keep TCP connections over the
> > tunnel from using the full size 1500 MTU by advertising lower MSS values to
> > TCP senders. Instead TCP senders will use a segment size that will result
> > in total encrypted, encapsulated OpenVPN packet sizes of 1450 or less.  And
> > then when you add on the IP header and UDP header, you are still under
> > 1500.
> 
> Yes. There is similar thing in iptables (--TCP-MSS).
> Also, PMTU discovery will do this in properly configured network.

No, PMTU discovery doesn't work very well on the real internet, because of the
way that firewalls tend to be configured.  If you don't believe me, google for
"PMTU black holes".

> > So if you're getting fragmentation on an HTTP download, I would try
> > reducing --mssfix to something below 1450 and see if that that fixes the
> > problem.
> 
> I don't get fragmentation on HTTP. I get fragmentation of carrier packets
> whan I send large UDP over tunnel link.

Right, the purpose of --mssfix is to avoid the fragmentation that occurs at
the carrier level.

> Anyway, regarding --mssfix: I dont want to work around the problem.
> I want to set correct tunnel MTU. An MTU such that:
> 1) large UDP packets (say, 7000 bytes) sent over tunnel link are cut into
> fragments of such size that, when encapsulated and sent over
> carrier link, do not exceed MTU of carrier path (in my case, 1500).
> Ideally, they should be equal to it.
> 2) TCP streams should use MSS which, again, results in sending full-sized
> packets over carrier link.

This is possible with correct settings of --tun-mtu/--link-mtu, --fragment,
and --mssfix.

James

> Currently, openvpn, when configured with --link-mtu 1500, sets --tun-mtu
> which is too large and (1) does not hold. "UDP doublefrag" bug.
> TCP works according to (2).
> 
> If I force smaller --tun-mtu 1434, UDP doublefrag does not happen.
> But now TCP does not use full-sized packets.
> 
> Look at the sizes of IP packets carrying UDP carrier packets
> (sniffed over carrier link). UDP is almost 1500, TCP is _not_:
> 
> > > --tun-mtu 1434:
> > >
> > > UDP flood (dd if=/dev/zero bs=1M | nc -nuvvv -w1 1.1.5.6 34564):
> > > ...
> > > 20:44:23.376801 IP (tos 0x0, ttl  64, id 5657, offset 0, flags [DF],
length: 1496)
>
 
> > > TCP flood (e.g. HTTP download):
> > > ...
> > > 20:41:55.514646 IP (tos 0x0, ttl  64, id 5293, offset 0, flags [DF],
length: 1472)
>
 
> 
> Hope this clarifies.
> --
> vda
> 



-- 

Re: [Openvpn-devel] OpenVPN 2.0-test26 released

[James Yonan]

Matthias,

You didn't bracket it with #ifdef TARGET_LINUX -- does that mean it's
appropriate on all platforms?

What about this (from the glibc manual): "If your program defines _BSD_SOURCE,
you must give the option `-lbsd-compat' to the compiler or linker when linking
the program, to tell it to find functions in this special compatibility
library before looking for them in the normal C library."

James

Matthias Andree <ma+ov...@dt.e-technik.uni-dortmund.de> said:

> On Thu, 29 Apr 2004, James Yonan wrote:
> 
> > Ooops... let's try that again with the correct subject line.
> > 
> > A new release of the 2.0 beta is available.
> 
> This prompted me to pull from CVS, I figured I need this patch on Linux
> when compiling with GCC 3.4 with strict error checking enabled:
> 
> Index: syshead.h
> ===
> RCS file: /cvsroot/openvpn/openvpn/syshead.h,v
> retrieving revision 1.25.2.6
> diff -u -r1.25.2.6 syshead.h
> --- syshead.h 29 Apr 2004 06:19:46 -  1.25.2.6
> +++ syshead.h 1 May 2004 10:09:05 -
> @@ -26,6 +26,8 @@
>  #ifndef SYSHEAD_H
>  #define SYSHEAD_H
>  
> +#define _BSD_SOURCE
> +
>  #ifdef HAVE_SYS_TYPES_H
>  #include 
>  #endif
> 
> 
> 
> 
> ---
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149_id=8166=click
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] (no subject)

[James Yonan]

A new release of the 2.0 beta is available.

* One of the goals of OpenVPN 2.0 is extreme scalability, i.e. robustly
handling connections from potentially thousands of clients.  To do this, some
kind of load balancing and failover capability is needed, because a single
OpenVPN daemon running on a single processor may not be able to handle this
kind of load.  One solution is to set up a cluster of near-identically
configured OpenVPN daemons on separate machines, or multiple daemons on a
multiprocessor machine, or both.  Each daemon is running with --mode server
and can handle multiple clients.

The feature that makes this now possible is that --remote has been extended to
allow a list of remote servers and port numbers to be specified on the client
such as:

  remote server1 5000
  remote server1 5001
  remote server2 5000
  remote server2 5001

By default the OpenVPN client will try each host/port in the order specified.
 If the connection fails (such as triggered by --ping/--ping-restart) the
client will move to the next host in the list.  The client can also initially
randomize the list using the new --remote-random flag, to provide a basic
load-balancing capability.

The servers are configured almost identically, though each has its own port
number and --ifconfig-pool IP address range.

* Harald Roelle has observed some limitations in the current Linux 2.4 and 2.6
tun/tap driver.  Specifically, the TX queue size is set to 10 by default,
which is too small.  There is also a problem with "kicking" where a packet in
the driver may get stuck there and need another packet to come through to
"kick" it out.  This may account for the "no buffer space available" message
that some Linux users report.  To work around this problem, OpenVPN has added
a --txqueuelen option to raise the queue length to a more sane size, and now
defaults to 100.  Right now, this is a Linux-only option.  I've also added
--rcvbuf and --sndbuf to control the TCP/UDP socket buffer sizes.  Harald
Roelle and Max Krasnyansky have put together some patches which fix the Linux
tun/tap driver issues, and should (hopefully) be in the pipeline shortly for
inclusion in the mainline 2.4 and 2.6 branches.  For now, --txqueuelen will
provide a workaround.

At this point I would say that nearly all of the key features which have been
envisaged for 2.0 are in place with a few exceptions:

* TCP Support in the multi-client server -- The only way that I can see of
scalably adding TCP support (without using multiple threads or processes) is
to use an efficient multi-socket API such as epoll() which is available on
Linux 2.6 and also apparently on 2.4 via a kernel patch.

* Forking server support -- The 2.0 multi-client server model is designed for
people who want a potentially large number of clients to tunnel through a
single tun or tap interface using a single daemon process.  Some people
however might prefer the forking server model, where the server automatically
forks off a new process for each incoming client, dynamically allocating a
private tun/tap interface for that client.

* Multithreading support -- multithreading offers two key advantages: (1) it
reduces the worst-case latency of packets flowing through the tunnel and (2)
it offers the opportunity for a single daemon to utilize all the processors on
an multiprocessor machine.  Unfortunately, multithreading causes a lot of
problems including complexifying the source code and introducing
race-condition bugs which can be extremely difficult to reproduce or track
down.  My thinking at this point is that implementing multithreading may not
be worth the trouble, especially given the fact that the new load balancing
feature can allow multiple OpenVPN daemons running on multiple machines to
serve the same client pool.

* Compatibility with 1.x -- OpenVPN 2.0 tries as much as possible to be
upwardly compatible with 1.x.  The main difference is that 2.0 changes some
parameter defaults.  The tun/tap MTU has been raised to 1500, --mssfix 1450 is
now the default, and --key-method now defaults to 2.  The only feature which
has been removed is the special-purpose SSL/TLS thread feature which is
enabled on 1.x if you build OpenVPN with the --enable-pthread flag.  I might
put it back if people complain, but overall I'm not sure that it's worth the
trouble.

Change Log:

2004.04.28 -- Version 2.0-test26

* Optimized broadcast path in multi-client mode.
* Added socket buffer size options --rcvbuf & --sndbuf.
* Configure Linux tun/tap driver to use a more sensible
  txqueuelen default.  Also allow explicit setting
  via --txqueuelen option (Harald Roelle).
* The --remote option now allows the port number
  to be specified as the second parameter.  If
  unspecified, the port number defaults to the
  --rport value.
* Multiple --remote options on the client can now be
  specified for load balancing and failover.  The
  --remote-random flag can be used to initially randomize
  the --remote list for basic load 

Re: [Openvpn-devel] Windows and Shaper

[James Yonan]

Derek,

Thanks for the function, I like it better than the previous function which was
using timeGetTime (and therefore has wraparound problems).

I've merged it in test26 which should be released soon.

James

Derek Burdick <de...@burdick.cc> said:

> Here is the function.  Don't forget to #DEFINE HAVE_GETTIMEOFDAY in
> config-win32.h.  Let me know what you think.

> Derek Burdick
> - Original Message ----- 
> From: "James Yonan" <j...@yonan.net>
> To: "Derek Burdick" <de...@burdick.cc>;
> <openvpn-devel@lists.sourceforge.net>
> Sent: Tuesday, April 27, 2004 12:48 PM
> Subject: Re: [Openvpn-devel] Windows and Shaper
> 
> 
> > Derek Burdick <de...@burdick.cc> said:
> >
> > > I was browsing the online CVS repository and noticed the
> > > config-win32.h.in says that HAVE_GETTIMEOFDAY is specified in misc.c.
> When
> > > I look in misc.c, I don't see the file.  Is the latest version just not
> > > checked in?  I also implemented a gettimeofday for windows.  It is based
> on
> > > QueryPerformanceCounter. If you are interested in this version let me
> know.
> > > If somebody knows the correct status of gettimeofday for the cvs code, I
> > > would appreciate an update.
> >
> > Derek,
> >
> > Yes, I'd like to see your gettimeofday for Windows that uses
> > QueryPerformanceCounter.  OpenVPN 2.0 will have a gettimeofday function
> for
> > Windows so that --shaper and --mode server can be supported.
> >
> > James
> >
> >
> 



-- 

Re: [Openvpn-devel] Many to one TCP question

[James Yonan]

Lonnie Cumberland  said:

> Hello All,
> 
> Well, I've been away from the list for a little while and was wondering 
> if someone could please bring me up to speed on the development of the 
> "Many-to-One" TCP progress?
> 
> It is my understanding that in the OpenVPN 2.0 (early) Beta, that UDP 
> connections can be established in a many to one TAP/TUN interface, but 
> how about the TCP side?

TCP support for multiple-clients going through a single tun/tap interface is
probably not going to be here for a while unless someone sponsors the work. 
The problem is that it's difficult to scale, because TCP connections require
one socket per client, while UDP connections can use a single socket to talk
to any number of clients.  Most OSes lack an efficient API for waiting on the
status of a large number of sockets.  The one notable exception is Linux 2.6
which has the epoll API.  Most application developers get around this
limitation by using multiple threads or processes, where each thread/process
waits on a single socket.  But then you have the inefficiency of a large
number of threads/processes and the interprocess communication overhead
entailed by that.

James

Re: [Openvpn-devel] Windows and Shaper

[James Yonan]

Derek Burdick  said:

> I was browsing the online CVS repository and noticed the
> config-win32.h.in says that HAVE_GETTIMEOFDAY is specified in misc.c.  When
> I look in misc.c, I don't see the file.  Is the latest version just not
> checked in?  I also implemented a gettimeofday for windows.  It is based on
> QueryPerformanceCounter. If you are interested in this version let me know.
> If somebody knows the correct status of gettimeofday for the cvs code, I
> would appreciate an update.

Derek,

Yes, I'd like to see your gettimeofday for Windows that uses
QueryPerformanceCounter.  OpenVPN 2.0 will have a gettimeofday function for
Windows so that --shaper and --mode server can be supported.

James

Re: [Openvpn-devel] OpenVPN 2.0 (test23) and logging

[James Yonan]

Mike Auty  said:

> Hi James,
>  First off, great program, it's really amazing what you and the 
> other developers have achieved.
>  Secondly the new 2.0 seems to be working out quite well, but I ran 
> into a little difficulty.  The problem I was having turned out to be a 
> firewall misconfiguration (read something I should have checked at the 
> beginning, hehe), but whilst I was trying to debug a connection that 
> just wouldn't work I found it very difficult in the server logs to 
> differentiate messages from one connected client and another.
>  I'm guessing this is just a hangover from openvpn 1 having been 
> single connection only, but it would be really helpful to have some kind 
> of identifier that ties all the log messages relating to a particular 
> connection (and I guess one for messages that haven't been associated 
> with a particular connection yet).

Yes, that's a good point.  I did add the client common name to the connection
initiated and connection restarted/exited messages, but ideally one would want
all messages to have some kind of client prefix, that would probably consist
of the SSL/TLS common name + IP address.

>  Anyway, thanks again for a fantastic piece of software, I look 
> forward to trying out the future versions as soon as they get released!
>  Mike  5:)

Excellent... take care.

James

[Openvpn-devel] OpenVPN 2.0-test20 released

[James Yonan]

This latest 2.0 beta has some cool new features including tap interface
support and customization of configuration based on the client certificate
common name.

The man page on the web site now shows all new 2.0 options, and the release
notes on the web site shows sample config files for tap-style tunnels.

2004.04.10 -- Version 2.0-test20

* --mode server capability now works with either tun
  or tap interfaces.  When used with tap interfaces,
  OpenVPN will internally bridge all client tap
  interfaces with the server tap interface.
* Connecting clients can now have a client-specific
  configuration on the server, based on the client
  common name embedded in the client certificate.
  See --client-config-dir and --client-connect.
  These options can be used to configure client-specific
  routes.
* Added an option --client-to-client that enables
  internal client-to-client routing or bridging.
  Otherwise, clients will only "see" the server,
  not other connected clients.
* Fixed bug in route scheduling which would have caused
  --mode server to not work on Windows in test18
  and test19 with the sample config file.
* Man page is up to date with all new options.
* OpenVPN 2.0 release notes on web site updated
  with tap-style tunnel examples.

James

Re: [Openvpn-devel] multiple connections on one tap

[James Yonan]

Miika Keskinen  said:

> Hi.
> 
> How much functionality there needs to be implemented in order to get 
> multiple connections with one tap-adapter working? And then, should that 
> be implemented either by implementing ethernet-switch or maybe even with 
> bridging-code? Normally when talking about bridges there is limit of 256 
> interfaces per bridge and I can see that as an issue.

OpenVPN would need to be a switch.  That means scanning ARPs, learning MAC
addresses, propagating broadcasts, etc.

> Then again, another issue with windows version of openvpn and mostly 
> it's way of resolving whether it's run as service. It would be more than 
> nice to be able to call like os.popen("openvpn ") on windows too but 
> called that way it cannot get those consolethingies and doesn't like it. 
> So anyone got this same problem? I think that identifying could be done 
> by other means.

OpenVPN doesn't need to be run from a console window (otherwise running as a
service wouldn't work).  OpenVPN tries to open the console, but if it doesn't
exist, it is nonfatal -- OpenVPN will continue to run.  It does, however, want
the standard file handles (especially stdout) to point to something so it can
generate logging output.

James

> And sorry for my bad engrish ;)
> 
> yours.
> Miika Keskinen
> 
> 
> ---
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470_id=3638=click
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

Re: [Openvpn-devel] OpenVPN 2.0 feature request - fixed-address

[James Yonan]

Arkadiusz Patyk  said:

> Hi
> 
> ifconfig-pool is fine, but I would need an option for IP
> reservation for users.
> The reservation could be realized on thebase of x509name
> 
> for example:
> 
> fixed-address 10.8.0.46
/C=PL/ST=NA/O=Dot.net/CN=Maciej.Nowak/emailAddress=m.no...@firma.com
> fixed-address 10.8.0.50
/C=PL/ST=NA/O=Dot.net/CN=Zenon.Ptak/emailAddress=z.p...@firma.com
> 
> which would guarantee that user X always gets address Y
> as option fixed-address in dhcpd
> 
> The possibility of IP reservation will simplify firewall configuration -
> espesially if it is installed on other machine than openvpn server.

Yes, I agree that this feature is necessary.  But I'm concerned that making
options that take an x509 name as a parameter (as you propose with
'fixed-address' above) might not be general enough.  I think that people are
going to want the ability to arbitrarily customize the options which are
pushed back to the client based on the client's x509 name.

What if it were done by scripting?

A script would be called with the x509 name, and the script could then
generate options which would either be executed locally or pushed to the client.

This would offer more general, programmatic control over customizing the
tunnel based on the x509 name.

James

Re: [Openvpn-devel] OpenVPN 2.0 -- Project Update and Release Notes

[James Yonan]

Matthias Andree <ma+ov...@dt.e-technik.uni-dortmund.de> said:

> On Tue, 30 Mar 2004, James Yonan wrote:
> 
> > OpenVPN 2.0 -- Project Update and Release Notes
> > 
> > I'm happy to announce that the first OpenVPN 2.0 beta is here, and well 
> > ahead
> > of schedule.  This is in large part thanks to a generous contribution by
> > Meetrix Inc. which has allowed me to work full-time on the project during 
> > the
> > last month.
> 
> In how far does the new OpenVPN 2.0 server require client upgrades?

If you run 2.0 in point-to-point mode (i.e. 1.x behaviour) no client upgrades
are required, with the caveat that some default options have changed.

If you want to use --mode server, then both the client and server need to be
2.0 because the client needs to support the --pull option in order to get
dynamic configuration info from the server.

James

[Openvpn-devel] Re: [Openvpn-users] OpenVPN 2.0 and firewall

[James Yonan]

Arkadiusz Patyk  said:

> Hi
> 
> Two very significant things for me are:
> 1. In my configurations, VPN users have different rights to resources
> (access list on firewall - iptables).   I have to know client IP to
> correctly setup firewall, how can i do this in 2.x ?   How can i
> achieve this, in case of dynamic IP assignment

You can use the --ipchange script which is passed the common name and source
IP address every time a client connects.  I probably need to add a new
environmental variable that contains the dynamically allocated --ifconfig-pool
subnet.

> 2. Is it possible to run few servers (each of them on their own tap)
> on the same machine?

Yes, it is possible to run many '--mode server' servers on the same machine,
each having their own tun interface (tap interfaces are not supported yet in
--mode server mode).

This would be a good way to differentiate access rights for different client
classes.

James

> -- 
> Arkadiusz Patyk [areq(at)pld-linux.org] [http://rescuecd.pld-linux.org/]
> [IRC:areq ICQ:16231667  GG:1383]  [AP3-6BONE] [AP14126-RIPE]
> 
> 
> ---
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470_id=3638=click
> ___
> Openvpn-users mailing list
> openvpn-us...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 



-- 

Re: [Openvpn-devel] route from server?

[James Yonan]

Marc Hassman  said:

> A question and a suggestion:
>  
> Q: This is probably an XP problem rather than a OpenVPN one. With Windows XP
> as a client, I can 
> add an arbitrary route using the 'route' statement and I observe it being
> added in the 'route print' listing.
> However, a few seconds later the route disappears from XP's routing table.
> Has anybody else 
> experienced this?

Make sure that the TAP-Win32 adapter is getting an IP address.  From a command
prompt window, "ipconfig /all" will show the currently assigned adapter
addresses.  If the TAP adapter loses its IP address, all routes connected with
the adapter will be dropped.

> S: It would be helpful when running in a 1 config file/tcp/tap/inetd setup
> if the server end of the connection
> could push static routes to the client thereby making a change a single
> server file change and not a 
> per client file change. I think this might be beneficial to other setups as
> well.

This is planned for 2.0.

James

Re: [Openvpn-devel] OpenVPN multi instancing

[James Yonan]

Matthias Andree  said:

> On Sun, 29 Feb 2004, Christian Daniel wrote:
> 
> > Hello everybody!
> > 
> > For a student research project I'm trying to add multi instance capability 
> > to 
> > OpenVPN. The basic idea is to rip the main openvpn()-function apart, put 
> > all 
> > variables in a struct and then have only one select()-call for all open 
> > tunnels at once.
> 
> Oh. You're in for plentiful fun with the various select()
> "features"^Wbugs across the various operating system kernels.
> 
> Better check out poll() and epoll() where available. These happen to
> (usually) be more scalable as the number of fds increases.

Luckily, UDP scales up fairly well without hitting up against the limitations
of select() since a single UDP socket can be used to communicate with an
unlimited number of clients.  TCP will be harder to scale with select()
because every incoming client will need its own socket.

I don't see how poll() is that much of an improvement over select() because it
still requires that you scan all the FDs to see which ones require service.

epoll() looks like a real improvement, and has obviously been designed with
scalability in mind.

It's too bad that poll and epoll move the timeout from microsecond to
millisecond resolution, as that makes things like traffic shaping harder to
implement.

James

Re: [Openvpn-devel] --redirect-gateway on FreeBSD

[James Yonan]

Juan Rodriguez Hervella  said:

> Hello,
> 
> I've just subscribed to this list, but I've read on the
> archives that the --redirect-gateway function is not
> working yet on FreeBSD because of the problem of
> retreiving the address of the default gateway.
> 
> I've just written a small program which makes that,
> looking at /usr/src/sbin/route.c
> 
> Hope this helps, I've tested it on both FreeBSD-4.9
> and FreeBSD-5.2
> 
> It uses PF_ROUTE sockets.
> 
> hope this helps!
> -- 
> **
> JFRH
> **
> 
> Go climb a gravity well!

Juan,

It would be ideal if you could code this into OpenVPN's route.c, following the
form of the other platforms, i.e.:

..

#elif defined(TARGET_FREEBSD)

static bool
get_default_gateway (in_addr_t *ret)
{
  /* code me -- put gateway address into *ret */
}

#else

..

James

Re: [Openvpn-devel] Question about TCP forking server

[James Yonan]

Juan Rodriguez Hervella  said:

> Hello,
> 
> I've just realized that openVPN-1.6rc1 only supports 
> "inetd nowait" for the TLS case.
> 
> I understand that it is not possible to have "nowait" behaviour
> for multiple clients with different secrets, but it would be still possible
> to have "nowait" functionality + a single secret. Every client should
> have the same secret key which is not a good way of having security,
> but anyway...this could be a warning instead of the current message:
> "nowait functionality is only allowed for TLS". 

That's a good point, though I would argue that (a) static key sharing across
different tunnels isn't such a good idea and (b) it's easy to patch if you
don't care about the security implications.

> Even if you don't want cryptography at all, the forking server is
> an interesting feature that should be let available, imho.

2.0 will have a better arsenal of multi-client server capabilities, and for
now I'm not too keen on supporting --inetd nowait aside from the special case
that it was designed for which is TLS security over a tap interface.

James

[Openvpn-devel] OpenVPN 1.6-rc1 released

[James Yonan]

This is a release candidate for 1.6.0.

The main change from 1.6-beta7 is that the Windows version now uses --ip-win32
dynamic by default.

Change Log:

2004.03.02 -- Version 1.6-rc1

* For Windows, make "--ip-win32 dynamic" the default.
* For Windows, make "--route-delay 10" the default
  unless --ip-win32 dynamic is not used or --route-delay
  is explicitly specified.
* L_TLS mutex could have been left in a locked state
  for certain kinds of TLS errors.


James

Re: [Openvpn-devel] Files missing from BETA20 CVS

[James Yonan]

Matthias Andree  said:

> Hi,
> 
> the files list.c, mroute.c and multi.c appear to be missing from the
> BETA20 branch in CVS:
> 
> ma@merlin:~/cvs-3rdparty/openvpn> LANG=C make -ks 2>&1 | grep ^make
> make[1]: *** No rule to make target `list.c', needed by `list.o'.
> make[1]: *** No rule to make target `mroute.c', needed by `mroute.o'.
> make[1]: *** No rule to make target `multi.c', needed by `multi.o'.
> make[1]: *** [openvpn.o] Error 1
> make[1]: Target `all-am' not remade because of errors.
> make: *** [all] Error 2

Ooops, it looks like I forgot to do a cvs add on some new files.

It's fixed now, and the BETA20 branch has been updated to reflect my current
development sources (I also updated the ChangeLog).

The current source should build and run a point-to-point tunnel correctly
using all the refactored code.  Grep for JYFIXME to see a bunch of gotchas in
the source -- mostly stuff that's there for debugging purposes.

The point-to-multipoint code is taking shape in multi.[ch] but is not finished
yet.

James

Re: [Openvpn-devel] OpenVPN multi instancing

[James Yonan]

Christian Lademann  said:

> Hello, James hello, Christian,
> 
> is it also going to be supported in 2.0 to have multiple tup/tap interfaces
> but only a single TCP-port on the server side waiting for incoming 
> connections?

The ultimate goal is to have all connection options open in either
point-to-point or point-to-multipoint mode.  The initial 2.0 beta will
specialize in serving multiple clients on a single UDP port, single tun/tap
interface, and single config file.

Actually if you want single TCP-port, one tun/tap interface per client, that
sounds like the inetd-based forking server model which is already functional
(in a limited sense) in the 1.6 beta series.  The limitation is that you use
SSL/TLS + bridging.  See the FAQ for more info.

James

Re: [Openvpn-devel] OpenVPN multi instancing

[James Yonan]

Matthias Andree <ma+ov...@dt.e-technik.uni-dortmund.de> said:

> On Mon, 01 Mar 2004, James Yonan wrote:
> 
> > Christian Daniel <c...@cdaniel.de> said:
> > 
> > > Hello everybody!
> > > 
> > > For a student research project I'm trying to add multi instance
capability to 
> > > OpenVPN. The basic idea is to rip the main openvpn()-function apart, put
all 
> > > variables in a struct and then have only one select()-call for all open 
> > > tunnels at once.
> > 
> > It's already been done :)
> > 
> > See the BETA20 branch in the CVS.
> 
> Is there a document that mentions the development tags so the daring
> know what to check out? Or a mailing list I should subscribe to?

It's not too complicated.  The HEAD branch is stable, or a beta series which
is leading to a stable release, i.e. 1.6-betaX.  The BETA20 branch at this
point mostly contains a lot of refactorization.  All the stuff that used to be
on the stack in the openvpn() function is now kept in a struct context. 
openvpn.c and the main() function is clean and minimalistic once again.

Every major or beta release gets a tag that is constructed from the version
number.  When I do a cvs commit I use this simple script:

cvs commit -m "version $OPENVPN_VER" && cvs tag `echo openvpn-$OPENVPN_VER |
tr . -`

where $OPENVPN_VER is something like "1.6-beta7" or "1.5.0".

> May I suggest to post the pointer to the document or add one to
> openvpn.sourceforge.net?

There's not a lot of people actually working on the code right now, so it's
easier to just ask questions on the list or search the archives.

James

[Openvpn-devel] Re: [Openvpn-users] Problem while compiling openvpn

[James Yonan]

PremKumar Jayaram  said:

> Hello Everybody,
> 
> I need to compile the opnevpn code on windows 2000. Using Win DDK I was able 
> to compile the driver code, but I am not able to compile the openvpn.c and 
> other files. I tired to compile using VC++ 6.0 but there where few header 
> files under openvpn's "sys" folder which was not defined in VC++.
> 
> In build.w32 file header I saw some instructions of compiling the code using 
> MingW compiler. Is the code supposed to be compiled only with MingW or can I 
> do with VC++ compiler also ?

OpenVPN needs the MinGW compiler to build openvpn.exe on Windows.  There would
probably be some porting work involved to get it to build under VC++.  I've
heard reports that VC++ doesn't like GNU or ISO C99 vararg-style macros, which
OpenVPN depends on heavily.

James

Re: [Openvpn-devel] patch for iproute

[James Yonan]

Martin,

Thanks for the patch -- it looks good and I expect to merge it.  I see that
you hardwire the choice for iproute2 vs. vanilla ip route + ifconfig at build
time.  Do you think that makes sense, or would it be better to have an
--iproute2 run time flag?

James

Martin Hejl  said:

> Hi everybody,
> 
> I am part of the LEAF project - a small distro for embedded environments 
> - at http://leaf.sourceforge.net (I'm actually only part of the "Bering 
> uClibc" branch, to be precise).
> 
> Since LEAF does not provide ifconfig and route by default (just 
> iproute2) I created a patch that allows using OpenVPN on LEAF boxes 
> without the need for ifconfig and route.
> 
> I would be very happy to see this integrated into OpenVPN at some point 
> (there's no hurry - we have a mostly automated build environment, so 
> applying the patch is no big deal).
> 
> I've tested the patch using a LEAF box plus a regular Fedora box (both 
> tun and tap devices) and everything seems to be working nicely.
> 
> If the patch doesn't make it onto the list (the LEAF lists trim all 
> attachments), it can also be found at:
>
http://cvs.sourceforge.net/viewcvs.py/leaf/src/bering-uclibc/apps/openvpn/iproute.patch
> 
> Let me know if you have any questions.
> 
> Martin
> 



-- 

Re: [Openvpn-devel] option suggestion (was Re: routing on windows)

[James Yonan]

Farkas Levente <lfar...@bnap.hu> said:

> James Yonan wrote:
> > Farkas Levente <lfar...@bnap.hu> said:
> > 
> > 
> >>Mathias Sundman wrote:
> >>
> >>>Hi!
> >>>
> >>> > we use our linux vpn gateway and some win2000 road warrior clients with
> >>> > openvpn. I would like to route all internet traffic trough our firewall
> >>> > from the windows clients.
> >>>
> >>> I´ve been thinking about doing this too, but never accually tried it.
> >>>
> >>> What you basicly need to do is:
> >>>
> >>> 1. Don´t set a default gateway on your ethernet adapter.
> >>
> >>you have to set otherwise the vpn connection can't estabilished.
> >>
> >>
> >>> 2. Add a route to your openvpn server with a /32 mask pointing to the
> >>>gateway on your ethernet.
> >>>
> >>>In your exampel this would be done with the following command on
> >>>Win2K where w.x.y.z is the IP of your remote openvpn server,
> >>>and a.b.c.254 is your local gateway.
> >>>
> >>>ROUTE ADD w.x.y.z MASK 255.255.255.255 a.b.c.254
> >>>
> >>> 3. Setup OpenVPN as usual but also add a default gateway route to
> >>>the TAP interface.
> >>>
> >>>
> >>> The reason why I havn´t tried this is because I don´t know how to solve
> >>> the problem that the ROUTE command will be diffrent for each network you
> >>> hook your laptop into. So if you don´t want to manually do this every
> >>> time, you would need to write a little app that looks at the IP and
> >>> default gateway that has been assigned by DHCP, switch to static IP and
> >>> add the correct route.
> >>>
> >>> Anyone that has a better solution to this?
> >>
> >>you see exactly the problem!
> >>on linux I can do (eg. in the up script):
> >>--
> >>route add -host  dev ppp0
> >>route del default dev ppp0
> >>route add default dev tun0
> >>--
> >>and we got it, but unfotunately on windows you can't route by interface 
> >>(or to be more precise on windos the interface is defined by it's ip 
> >>address even if you can specify the interface).
> >>so I'd like to suggest a new option for openvpn to be portable (like in 
> >>the case of --route):
> >>--route-internal
> >>   which do exactly as the above on all platform.
> >>since openvpn know whcih ip address has the under the tun/tap interface.
> >>or may it would be more better if the up script has one more (6th) 
> >>paramter and the underlying interface's ip address:
> >>---
> >>cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip 
> >>underlying_ip [ init | restart ]
> >>cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask 
> >>underlying_ip [ init | restart ]
> >>---
> >>and in this case on linux we cn write an up script as:
> >>--
> >>route add -host $5 dev ppp0
> >>route del default dev ppp0
> >>route add default dev tun0
> >>--
> >>while on windows
> >>--
> >>route add $5 gw $6
> >>route delete 0.0.0.0 mask 0.0.0.0 $5
> >>route add 0.0.0.0 mask 0.0.0.0 $4
> >>--
> >>does it possible? or any better solution?
> > 
> > 
> > When you say "underlying_ip" I assume you mean the original default gateway
> > (before the up script (might have) changed it)?
> > 
> > I agree that it would be useful to provide an "original default gateway"
> > parameter to up scripts.
> 
> yes.
> 
> > This would provide the support necessary to conveniently route all IP 
> > traffic
> > through the VPN tunnel.
> > 
> > Unfortunately, as is often the case with network configuration, there is no
> > standard API for doing this.
> > 
> > To make this work in OpenVPN, you would need to follow the model of tun.c 
> > and
> > route.c where there is a function such as get_default_gateway that has a 
> > bunch
> > of #ifdefs for each platform.
> > 
> > If you want this to work on Windows right now, I would suggest you run 
> > "route
> > 

Re: [Openvpn-devel] option suggestion (was Re: routing on windows)

[James Yonan]

Farkas Levente  said:

> Mathias Sundman wrote:
> > Hi!
> > 
> >  > we use our linux vpn gateway and some win2000 road warrior clients with
> >  > openvpn. I would like to route all internet traffic trough our firewall
> >  > from the windows clients.
> > 
> >  I´ve been thinking about doing this too, but never accually tried it.
> > 
> >  What you basicly need to do is:
> > 
> >  1. Don´t set a default gateway on your ethernet adapter.
> 
> you have to set otherwise the vpn connection can't estabilished.
> 
> >  2. Add a route to your openvpn server with a /32 mask pointing to the
> > gateway on your ethernet.
> > 
> > In your exampel this would be done with the following command on
> > Win2K where w.x.y.z is the IP of your remote openvpn server,
> > and a.b.c.254 is your local gateway.
> > 
> > ROUTE ADD w.x.y.z MASK 255.255.255.255 a.b.c.254
> > 
> >  3. Setup OpenVPN as usual but also add a default gateway route to
> > the TAP interface.
> > 
> > 
> >  The reason why I havn´t tried this is because I don´t know how to solve
> >  the problem that the ROUTE command will be diffrent for each network you
> >  hook your laptop into. So if you don´t want to manually do this every
> >  time, you would need to write a little app that looks at the IP and
> >  default gateway that has been assigned by DHCP, switch to static IP and
> >  add the correct route.
> > 
> >  Anyone that has a better solution to this?
> 
> you see exactly the problem!
> on linux I can do (eg. in the up script):
> --
> route add -host  dev ppp0
> route del default dev ppp0
> route add default dev tun0
> --
> and we got it, but unfotunately on windows you can't route by interface 
> (or to be more precise on windos the interface is defined by it's ip 
> address even if you can specify the interface).
> so I'd like to suggest a new option for openvpn to be portable (like in 
> the case of --route):
> --route-internal
>which do exactly as the above on all platform.
> since openvpn know whcih ip address has the under the tun/tap interface.
> or may it would be more better if the up script has one more (6th) 
> paramter and the underlying interface's ip address:
> ---
> cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip 
> underlying_ip [ init | restart ]
> cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask 
> underlying_ip [ init | restart ]
> ---
> and in this case on linux we cn write an up script as:
> --
> route add -host $5 dev ppp0
> route del default dev ppp0
> route add default dev tun0
> --
> while on windows
> --
> route add $5 gw $6
> route delete 0.0.0.0 mask 0.0.0.0 $5
> route add 0.0.0.0 mask 0.0.0.0 $4
> --
> does it possible? or any better solution?

When you say "underlying_ip" I assume you mean the original default gateway
(before the up script (might have) changed it)?

I agree that it would be useful to provide an "original default gateway"
parameter to up scripts.

This would provide the support necessary to conveniently route all IP traffic
through the VPN tunnel.

Unfortunately, as is often the case with network configuration, there is no
standard API for doing this.

To make this work in OpenVPN, you would need to follow the model of tun.c and
route.c where there is a function such as get_default_gateway that has a bunch
of #ifdefs for each platform.

If you want this to work on Windows right now, I would suggest you run "route
print" in your up script and pipe the output to a program which parses out the
"default gateway" information and returns it to the script.

Then you can do the little routing dance where you route the VPN endpoint to
the original default gateway, then reset the default gateway to point to the
TAP adapter.

James

Re: [Openvpn-devel] Re: OpenVPN --resolv-retry and --chroot problem

[James Yonan]

Teemu Kiviniemi <teem...@iki.fi> said:

> Wed, 29-10-2003 at 23:38, James Yonan wrote:
> 
> > I would rather see this fix accomplished by adding some kind of dummy call
> > early on in the initialization sequence to trigger the dynamic load of the 
> > DNS
> > library -- but which doesn't touch the functionality of the current DNS name
> > resolution code.
> 
> Hi,
> 
> I made a new patch. This time the name lookup is done in openvpn.c if
> options->remote is set, just before entering the chroot jail.
> 
> http://iki.fi/teemuki/openvpn/cvs-resolvfix2.diff
> The patch is against the current CVS version.

Cool -- I merged it.

James

[Openvpn-devel] Re: OpenVPN --resolv-retry and --chroot problem

[James Yonan]

Teemu Kiviniemi  said:

> Hi,
> 
> OpenVPN 1.5beta12 and the CVS version have a problem when --resolv-retry
> and --chroot are used at the same time. In chroot environment,
> gethostbyname() can't resolve the remote IP address:
> 
> Wed Oct 29 17:19:17 2003 13: RESOLVE: Cannot resolve host address:
> somehost.somedomain: [unknown h_errno value]
> 
> This problem occurs with Debian Woody. I think it's related to the Glibc
> dynamic loader. If the name resolver libraries aren't loaded before
> OpenVPN enters the chroot jail, OpenVPN can't do any DNS queries. If
> gethostbyname() is run before entering chroot(), the resolver libraries
> are loaded and everything works as it should.
> 
> I changed link_socket_init_phase1() in socket.c to resolve the remote
> host even if resolve_retry_seconds is set. That way, gethostbyname() is
> run before chroot(). I don't know if that's the right way to do it, but
> it fixes the problem for me.
> 
> The patch for 1.5 beta12 and the CVS version is available at:
> http://iki.fi/teemuki/openvpn/openvpn-resolvfix.diff

Teemu,

The DNS name resolution code for --remote is somewhat delicate -- for example,
the phase1 code cannot block because it's called before daemonization.

I would rather see this fix accomplished by adding some kind of dummy call
early on in the initialization sequence to trigger the dynamic load of the DNS
library -- but which doesn't touch the functionality of the current DNS name
resolution code.

James

Re: [Openvpn-devel] a replacement for --tls-remote and verify-cn

[James Yonan]

Teemu Kiviniemi  said:

> Hi,
> 
> I ran into problems in using --tls-verify to verify the remote host with
> --chroot enabled. --tls-verify runs the verify script with system()
> command, so it assumes that /bin/sh is available. Usually, in a chroot
> environment, that's not true.
> 
> I implemented a new config option: --tls-remote x509name
> 
> With --tls-remote the remote host is verified by looking at the X509
> name. If the remote X509 name doesn't match the given x509name, the
> remote host is rejected.
> 
> With --tls-remote, it's possible to verify remote host even with a
> completely empty chroot directory. --tls-remote also removes the need
> for an external --tls-verify script in most cases.
> 
> Config example:
> tls-remote /O=exampleorg/CN=name
> 
> I have tested the patch with a TLS tunnel on Debian Woody.
> 
> A patch against OpenVPN 1.5 beta12 is available at:
> http://iki.fi/teemuki/openvpn/1.5_beta12-tlsremote.diff

Thanks, that looks like a useful patch.

One thing that would help me to merge it more easily, is if you could recode
against the current CVS which has advanced since beta12 and includes the
--crl-verify patch which touches the same parts of ssl.c as your patch.

The 1.5 beta series exists in the CVS under branch "EXP15".

James

[Openvpn-devel] RE: [Openvpn-users] connecting to multiple servers

[James Yonan]

Peter Sandström  said:

> I'm currently working on this, but as James says. This patch will be
> far to intrusive to be merged into 1.5 this late.
> The entire socketlayer needs to be ripped out and redone since alot
> of the current code assumes that there is always exactly one local
> and one remote address. Also there needs to be some kind of funky
> autolearning iprouting in order for it to work properly (working like
> a switch instead of a hub for those that want it in ethernet lingo).

I'm not sure that you need to rip out a lot of code to make this work.  The
socket layer does assume one local and one remote address, but this provides a
benefit in terms of making the code easy to understand and debug.

I would leave this code as it is, and do the following:

(1) Write code (which executes as a separate thread or process) which
implements a port multiplexing proxy.

(2) Write code (also as a separate thread) which implements a tun/tap sharing
proxy.

(3) Modify the socket code so that rather than doing connect(), bind(),
recvfrom(), sendto(), etc., it forwards these requests to the (1) proxy using
some kind of RPC-like mechanism.

(4) Modify the tun/tap code so that rather than
opening/reading/writing/closing the tun/tap file handle directly, it forwards
these requests to the (2) proxy.

This would give us UDP port and tun/tap multiplexing capability without
needing significant structural changes to the existing OpenVPN code.

James

Re: [Openvpn-devel] comments on beta12

[James Yonan]

julien Touche  said:

> test between debian linux  2.4.21 <-> openbsd 3.4, beta12 on the 2 sides
> works well
> 
> one comment for openbsd, "dev tun" doesn't work:
> 
> Tue Oct 14 12:14:14 2003 6: /sbin/ifconfig tun delete
> ifconfig: SIOCGIFFLAGS: Device not configured
> Tue Oct 14 12:14:14 2003 7: NOTE: Tried to delete pre-existing tun/tap 
> instance -- No Problem if failure
> Tue Oct 14 12:14:14 2003 8: /sbin/ifconfig tun 10.0.3.3 10.0.3.4 mtu 
> 1255 netmask 255.255.255.255 up
> ifconfig: SIOCGIFFLAGS: Device not configured
> => must precise tunX

Right, but I don't think this behavior has changed since 1.4.x?  You need to
give an explicit unit number (i.e. --dev tun0) because OpenBSD wants the
ifconfig to happen _before_ the tun open, therefore the tun open cannot be
used (as other OSes allow) as a mechanism for cycling through tunX and finding
the first free X.

Take a look at the ifconfig_order function in tun.h.  It tells OpenVPN whether
the ifconfig should come before or after the tun open.

Windows is the only other OS besides OpenBSD which likes the ifconfig before
the tun open.  And if you want --dev tun (without unit number) to work on
OpenBSD, you need to define a special case for OpenBSD in guess_tuntap_dev().

> test openbsd 3.4 <-> win2k, with dev tun (always beta12)
> works well too

> one mistery: on openbsd side, i can't ping itself in the vpn, all other 
> ping work.

Not sure about that -- it would be handled by the tun driver on OpenBSD.
OpenVPN never sees the packet when the local endpoint is pinged.

James

Re: [Openvpn-devel] CVS

[James Yonan]

Peter Sandström  said:

> Hey,
> 
> What's the current status of the CVS tree? I can't login using anonymous
> access.
> 
> I was planning on implementing multiple-connections-to-one-openvpn-instance
> since I need it for a usecase.
> Not beeing able to checkout the source complicates this though :)

I just checked, and it looks like the OpenVPN anonymous CVS is back online,
and the 24 hour delay seems to have vanished.

So these commands should set you up for working on the 1.5 beta series
(branch=EXP15):

cvs -d:pserver:anonym...@cvs.sourceforge.net:/cvsroot/openvpn login

cvs -z3 -d:pserver:anonym...@cvs.sourceforge.net:/cvsroot/openvpn co -r EXP15
openvpn

James

[Openvpn-devel] OpenVPN pre-beta8 is ready for testing.

[James Yonan]

I have a new beta release available with some very cool new features:

* The TAP-Win32 driver on Windows can now emulate a "tun" point-to-point IP
interface.  This completes the "compatibility matrix" meaning that OpenVPN on
Windows can now talk to OpenVPN on any other platform, including those which
do not have a "tap" driver available.

* The --ifconfig option now works for both "tun" and "tap" interfaces.

* --ifconfig also works now on Windows in the same way that it works on other
OSes (On Windows it is a proxy for the "netsh" command).

* Added a --route option that provides a platform-independent proxy to the
universal (but syntactically incompatible) route commands of the major OSes. 
Still need route cases for NetBSD and Mac OS X.

* Added a --route-up script callback which can optionally be executed n
seconds after connection establishment.

* A large number of useful parameters are now made available to scripts
through environmental variables.

* Added the --mssfix option to control TCP segment size.  --mssfix when used
in tandem with --fragment may turn out to be the solution we have been looking
for on the MTU front, where routers and firewalls that block Path MTU
Discovery have been wreaking havoc with IP encapsulation.  --mssfix lowers the
TCP packet size by mangling TCP SYN packets (just like iptables can do), and
--fragment does internal fragmentation on non-TCP packets.  They both work
together quite well.

* Significantly reworked the TAP-Win32 driver to bring it up to SMP standards.

* All new features are documented in the man page or the Win32 install notes.

There are few caveats as well to be aware of:

* I have experienced stalls in the Linux tap driver that seem to be
exacerbated when the TCP MSS is lowered using --mssfix.  All analysis so far
has pointed to the problem being in the Linux kernel.  The problem only occurs
on tap devices, not tun devices.

* There are a couple points to be aware of when using the new --dev tun
capability on Linux:  all ifconfig endpoint pairs must be the two usable
addresses in a /30 subnet.  The Windows install notes have more details about
this.  Also, --dev tun on Windows uses a --tun-mtu setting of 1500, so the
other side of the connection (if it is not also on Windows) must explicitly
have --tun-mtu 1500 in its config.

* The default value of --tun-mtu-extra was lowered from 64 to 32.  This
parameter describes the extra space over and above the MTU value, used for
things like the ethernet header.  If you are talking between different
versions of OpenVPN, and using TLS mode, you will need to explicitly state
--tun-mtu-extra 32 on both sides of the connection.

This is a limited release, primarily aimed at beta testers, so please report
experiences, both positive and negative.  If it tests well, it should be
promoted to 1.5-beta8 shortly.

Download:

http://openvpn.sourceforge.net/beta/

James

Re: [Openvpn-devel] Re: [Openvpn-users] Windows tun driver

[James Yonan]

Matthias Andree <ma+ov...@dt.e-technik.uni-dortmund.de> said:

> On Mon, 15 Sep 2003, James Yonan wrote:
> 
> > Yes, this is a problem.  For OpenBSD to talk to Windows over OpenVPN, we 
> > need
> > either a tun driver for Windows or a tap driver for OpenBSD.
> > 
> > My guess is that the easier and better solution would be to solve the tap on
> > OpenBSD problem, rather than the tun on Windows problem.
> 
> I'd like to challenge the "better" claim:

I mean "better" only in the sense of simpler configuration -- i.e. not needing
to set up a WINS server to make cross-subnet browsing work.  I agree that tun
is more scalable, secure, etc.

> The tap driver gives full ethernet tunnelling, so the Windows box gets
> to choose the IP, gets ARP traffic tunnelled and all that. That's pretty
> much power IMO.
> 
> The tun driver, in contrast, only works for a specific IP, if the
> Windows box chooses another one, it's not getting any traffic back.
> 
> I consider this a security relevant choice, if I have "half-trusted"
> users, tap isn't really an option.

I would agree that tun is a better choice for less than fully-trusted users.

> Background for the challenge is that OpenVPN might be useful as an
> additional security layer on top of WLAN-WEP, but tap somewhat defeats
> the purpose.
> 
> > I think that Windows users are going to prefer a tap interface anyways,
> > because it carries the kind of traffic and protocols which Windows
> > applications generate, such as broadcast traffic and non-IP protocols.
> 
> I for one don't need Windoze broadcast traffic gated, and "my" Windows
> boxes hardly generate non-IP traffic. IPX or NetBEUI drivers aren't
> installed on the Windows machines I maintain. ARP isn't needed. Granted,
> if you need IGMP, you'll want tap, but I'd guess that the SMB browsing
> can deal with most of the "problems".

I totally agree that a tun driver for Windows would be nice to have.  In fact
I would guess that the TAP-Win32 driver might even be close to the task, if
you could figure out the right DDK magic to export a point-to-point WAN
interface that binds to IPv4 instead of 802.3.  Interested in doing some
driver development?

James

[Openvpn-devel] RE: [Openvpn-users] Windows tun driver

[James Yonan]

Bert Shuler  said:

> James:
> Are you aware of a Windows tun project? While most windows users may
> prefer tap, I am interested in the point-to-point nature of the tun
> device. When setting up many routed connections, it seems that each TAP
> connection will use 1 ip and waste 2 others. I can also live without
> broadcast traffic and non-IP protocols.

While I do believe that the majority of Windows users will prefer a tap
interface, I say this simply because in my experience _most_ Windows users
prefer the option that is the easiest to configure.  Once you stop
automatically routing broadcasts and non-IP protocols, then you have to start
doing more configuration on Windows, i.e. setting up WINS servers and clients,
configuring samba differently, etc.

Having said that, I will agree that having a tun driver would be cool, and
that in many if not most circumstances, it is technically a better choice --
it is more scalable, it offers finer gradation of access control, it is more
universal across *nix platforms, etc. -- as long as you don't need to route
non-IP protocols.

The real problem is that very few open source developers are interested in
developing drivers for Windows, so there are not many choices available.  To
my knowledge there are three:  TAP-Win32, CIPE-Win32, and WinPcap, and none of
them provide tun capabilities.

James

[Openvpn-devel] New TAP-Win32 driver needs stress testing

[James Yonan]

I've made some significant changes in the TAP-Win32 driver, bringing it up to
SMP standards, and making some performance improvements in latency and overall
efficiency.

While it has admirably held up to my stress tests on a single processor XP
laptop, it needs testing on more machines, especially SMP machines, to flush
out any bugs that might be remaining.

The driver is here:

http://openvpn.sourceforge.net/beta/tapdrvr.sys

Install instructions


* Install OpenVPN normally.

* In Control Panel / Network connections, right click on all TAP-Win32
adapters and select Disable.

* Copy the new driver (tapdrvr.sys) to [your windows system
directory]\system32\drivers, overwriting the old copy.

* In Control Panel / Network connections, right click on the TAP-Win32 adapter
and select Enable.

* To verify that the correct driver is running, go to the adapter properties
-> Configure -> Driver -> Driver Details, and the file version should be
1.5-beta7.2 (DEBUG) or higher.

When you test it, I would encourage you to really STRESS TEST
it, i.e. copy large files over the tunnel while simultaneously running other
CPU or disk-intensive apps.

I would also encourage you to run the Driver Verifier.  It's
called verifier.exe, included on Win2K and later.  It will closely examine the
behavior of the driver and trigger a bug check if anything looks amiss.

Another good stress test is to have a heavy session going, then right-click
and disable the TAP adapter in the network connections control panel, while
the OpenVPN process is still running.  The OpenVPN process will generate a
stream of error messages when this happens -- this is okay.

And if you have a laptop, make sure to put it through a few sleep/resume
cycles, during heavy tunnel action.  The OpenVPN process may hiccup, but
should get back on track once the system is awake.

If you have any questions about testing the driver, don't hesitate to ask.

James

Re: [Openvpn-devel] Re: [Openvpn-users] New feature proposal: --route option

[James Yonan]

Tom Bin  said:

> 
> It's really a good idea.
> I think the syntax is good enough...,
> maybe you can take the metric(route cost) into consideration.

That's a good idea.  It looks like most IP stacks support metric, I see that
Windows does too so that is good.

> I would like to suggest the route is added once the vpn is up
> and deleted when the vpn is down.

Yes, that's what I'm planning.  I was also planning a --route-delay with a
number of seconds argument, so the routes addition could be delayed long
enough to allow a tap interface to get its DHCP parameters.

> Moreover, is it possible to have multiple routes added ?

Yes, definitely.

James

> 
> 
> 
> > I would like to implement a --route option that will be a proxy for the
> route
> > command, similar to the way that the --ifconfig option is a proxy for the
> > ifconfig command.
> >
> > The goal would be to present a kind of least-common-denominator route
> > functionality which is basic enough to be portable across OpenVPN's
> platform
> > space.
> >
> > I'm thinking of a syntax such as
> >
> >   --route network netmask gateway
> >
> > I'm looking for a syntax that will cover basic routing -- for more
> advanced
> > usage, one can always write a script.
> >
> > The overall goal is to simplify configuration by getting the common
> operations
> > out of --up scripts and into the OpenVPN config file where they will be
> > portable and easier to support.
> >
> > Comments?
> >
> > James
> 
> 
> 
> ---
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] New feature: --ifconfig for tap devices

[James Yonan]

One of the nice things about the --ifconfig option is that it lets you set TUN
adapter endpoint addresses (i.e. the virtual IP addresses for each end of the
tunnel) in a platform independent manner -- OpenVPN then translates the
--ifconfig option to the appropriate ifconfig command for your platform.

Up until now, the --ifconfig option has only worked for TUN adapters, but with
the increasing use of TAP adapters for ethernet bridging, and the fact that
the new Windows port only supports a TAP adapter, I've decided to extend
--ifconfig so that it works for TAP devices as well (this feature will be
included in 1.5-beta8).

--ifconfig is really a convenience function -- you can call ifconfig yourself
in an --up script, but letting OpenVPN run the ifconfig command for you makes
the configuration simpler and more portable.

The new --ifconfig will still work as always with --dev tun.  However if --dev
tap is specified, then the --ifconfig option will be interpreted as --ifconfig
ip-addr netmask.

What I need right now in order to make the TAP version of --ifconfig work
correctly, is the correct ifconfig command syntax for setting the IP address
and netmask of a TAP device, on all the OSes which OpenVPN supports.  I've
already coded templates for Linux and Windows, but I still need to know the
appropriate ifconfig syntax for FreeBSD, OpenBSD, NetBSD, Solaris, and Mac OS
X, with respect to setting the IP/netmask on a TAP device.

So if you are using one of these OSes with OpenVPN + TAP adapter, please let
us know what kind of ifconfig syntax you use in your --up script to set the
adapter parameters.

James

Re: [Openvpn-devel] Need 1.5 beta testers for *BSD, Linux 2.2, OS X

[James Yonan]

> question regarding windows openvpn (thanks a lot for this :), is it 
> possible to have some script executed (like add a route for the other 
> side subnet) ?

I'm thinking about something like this in a more generalized context, where
OpenVPN running as a server would actually generate the config file for the
client, and send it to the client via SSL after an initial authentication
handshake.  This would simplify the configuration on the client side, and
allow the server to send routes back to the client.

James

[Openvpn-devel] Need 1.5 beta testers for *BSD, Linux 2.2, OS X

[James Yonan]

If anyone out there is running 1.5-beta5 or later on OpenBSD, FreeBSD, NetBSD,
Mac OS X, or Linux 2.2, please let me know.

I want to make sure that 1.5 is tested on everything before 1.5 final is 
released.

Thanks,
James

[Openvpn-devel] Re: [Openvpn-users] OpenVPN ported to Windows

[James Yonan]

Yes, currently the CIPE TAP driver has the capability to run on NT 4, 2K, and
XP, but this first beta release of OpenVPN has only been tested on XP so far,
because that's the only windows development machine I have access to right
now.  OpenVPN uses a slightly forked version of the CIPE TAP, but I'm in
contact with Damion K. Wilson who is the author and maintainer of CIPE on
Windows and he has expressed interest in decoupling and modularizing the TAP
driver so that it can be used by other projects.

It would help if others came forward who have an interest in testing and
maintaining OpenVPN on W2K and NT4 -- the binaries really need to be compiled
on the version of windows that they are going to be run on, and compiling
everything from source is not really an option for the end-user as it is a
relatively complex undertaking compared with the ease of ./configure, apt-get,
and emerge that we have come to expect on other OSes.

While I expect that building OpenVPN for 2K and NT4 will be a relatively
straightforward undertaking, the two areas where compatibility breaks down
between the NT 4 series and the 2K/XP series are the .inf file (that's a file
that tells Windows how to install a particular device driver and how it binds
with other device drivers in the system), and the registry layout of network
device driver info.  OpenVPN needs to do some registry lookups in order to
translate the TAP adapter name given in --dev-node into a real filename which
can be passed to the Win32 open file function.

I would agree with Bishop that as far as running on the 9x/Me series is
concerned, I think it's unlikely given the much more limited networking driver
model that is available on that series.

James

bishop  said:

> My read of it suggested that, yeah, it only does NT or above, due to the 
> better net stack in the NT family tree.
> 
> Felipe Sanchez wrote:
> > 
> > 
> > This has to be one of the greatest news I've had this week   :-)  Count me
> > in as a heavy beta-tester!
> > 
> > 
> > I have one question: If I recall correctly the cipe TAP driver works only
> > on NT-class Windows operating systems (NT 4, 2K, XP) and not on 9x-class
> > ones (9x/Me).  Is this still the case?
> > 
> > 
> > 
> > ---
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> > http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
> > ___
> > Openvpn-users mailing list
> > openvpn-us...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 
> -- 
>   I tried joining the BATF, but it seems they're actually
>   AGAINST all three.  Some club they are!
> 



-- 

[Openvpn-devel] OpenVPN ported to Windows

[James Yonan]

Well some good news on the development front...

(1) OpenVPN has finally been ported to Windows.
(2) TCP protocol support has been added.

The Windows port was made possible by a number of emerging developments, most
importantly the stabilizing of the TAP driver component of the Cipe-Win32
project, thanks to the work of Damion K. Wilson and the other Cipe-Win32
developers.

My work on this effort involved decoupling the nascent Win32 TAP virtual
device driver from the Cipe-Win32 project, and making OpenVPN comfortable with
the Win32 API and the MinGW development environment.  This is a native port,
and does not require the presence of a Posix compatibility layer such as
Cygwin.  Performance appears to be comparable with Linux running on similar
hardware.

Some Notes:

* The port has been developed and tested on XP only at this point.

* With a few exceptions, most of the core functionality available under Posix
implementations of OpenVPN also works under Windows, including SSL/TLS, LZO
compression, the ability to call scripts (i.e. --up & --tls-auth), and support
for UDP or TCP tunnels.  Features that are missing from the current Windows
beta include --daemon, --shaper, pthread support, TUN devices, and options
such as --mlock or --user which don't have Posix-equivalent Win32 system
calls.  Another limitation is that installation must be done manually, i.e.
there is no Windows installer support yet.

* The --ifconfig option is not implemented on Windows OpenVPN, due to the lack
of an ifconfig executable to call.  Basically what happens when you install
the TAP-Win32 driver is that you get a new TAP network adapter that shows up
in your network control panel.  You right click on the TAP adapter and set the
TCP/IP properties, i.e. IP address and netmask.  Then you rename the TAP
adapter icon to something like "my-tap" and reference it using the --dev-node
option in OpenVPN.  So essentially the function of --ifconfig is accomplished
manually using the GUI and the network control panel.

* While OpenVPN on Windows supports multiple TAP adapters, I have not yet
found an easy way to create and delete TAP adapters using the Network Control
Panel.  Damion tells me that this can be done in the .inf file that is used to
install the driver, but I am still a beginner at understanding .inf files.

* The TAP-Win32 device driver is fairly stable at this point and did not crash
my system despite repeated editing, compiling, installing, and reinstalling
the driver.

* The other new feature is TCP support, for situations where using UDP is not
possible.  TCP support is enabled through the the new --proto option.  You can
select the protocol with --proto p, where p = udp | tcp-server | tcp-client. 
TCP support also works on Windows.  Since TCP is connection oriented, OpenVPN
needs to handle Connection Reset events.  Basically, on connection reset, a
TCP client or server will simulate a SIGUSR1 signal.  The server will go back
into a mode where it listens for a new connection, and the TCP client will
simulate a SIGUSR1 signal which will normally cause it to try to reestablish
the connection with the server.

Known Issues in the beta:

* TCP mode combined with --daemon doesn't work correctly yet -- this will be
fixed before 1.5 final.

* For some reason if a Solaris TCP client is connected to a TCP server, and
that TCP server resets the connection, the Solaris client will try to
reconnect, and will apparently succeeed, but then after reading a handful of
bytes from the remote, the client suddenly thinks that the connection was
reset again, and it will restart.  This client restart will also cause the
server to restart, and the whole process repeats again.  I have tested this
same scenario using both Windows and Linux TCP clients, but only Solaris TCP
clients show this problem.  The Solaris system I am using is:

SunOS [name] 5.9 Generic_112233-06 sun4u sparc SUNW,Ultra-1

Downloads
-

The beta version of the Windows distribution can be downloaded from here (with
source + pre-compiled binaries):

http://openvpn.sourceforge.net/beta/openvpn-1.4.99.3.zip

See the file INSTALL.w32 for Windows installation instructions.

The usual Posix distribution beta is here:

http://openvpn.sourceforge.net/beta/openvpn-1.4.99.3.tar.gz

The version numbering scheme is an attempt to denote a pre-1.5 beta in a way
that works with RPM spec files. 

The only differences between the distributions are compressed file formats
(.tar.gz for posix, .zip for windows) and the presence of a win32-binaries
directory on the .zip distribution which contains a pre-built openvpn exe,
OpenSSL DLLs, and the TAP-Win32 device driver.

James

[Openvpn-devel] OpenVPN 1.4.2 Released

[James Yonan]

1.4.2 has been released.  Details here:

http://openvpn.sourceforge.net/relnotes.html

James

Re: [Openvpn-devel] OpenVPN 1.4.2 release candidate, please test

[James Yonan]

Matthias Andree <ma+ov...@dt.e-technik.uni-dortmund.de> said:

> On Thu, 10 Jul 2003, James Yonan wrote:
> 
> > 
> > This is a maintenance release which (a) fixes the previously discussed ISO 
> > C99
> > vararg efficiency bug, and (b) further stabilizes the experimental
> > --mtu-dynamic option which causes OpenVPN to perform internal datagram
> > fragmentation in cases where native IP fragmentation is broken.
> > 
> > Testing will be helpful at this point, especially for non-x86-linux
platforms.
> 
> I am only compile testing, not testing runtime; these are Sun Workshop
> warnings:
> 
> "crypto.c", line 838: warning: argument #3 is incompatible with prototype:
> prototype: pointer to unsigned int :
"/usr/local/ssl/include//openssl/evp.h", line 551
> argument : pointer to int
> "ssl.c", line 310: warning: argument #2 is incompatible with prototype:
> prototype: pointer to unsigned char : "buffer.h", line 80
> argument : pointer to char
> "ssl.c", line 1523: warning: argument #1 is incompatible with prototype:
> prototype: pointer to const char : "options.h", line 191
> argument : pointer to unsigned char

These look like the kind of warnings you get with the gcc -Wconversion flag --
though Sun Workshop must be using a different warning algorithm because gcc
-Wconversion generates pages of warnings about similar things -- basically
function prototypes causing an implicit type conversion.  Most of these are
pretty harmless.

Anyway, I've fixed them.

James


James

[Openvpn-devel] OpenVPN 1.4.2 release candidate, please test

[James Yonan]

This is a maintenance release which (a) fixes the previously discussed ISO C99
vararg efficiency bug, and (b) further stabilizes the experimental
--mtu-dynamic option which causes OpenVPN to perform internal datagram
fragmentation in cases where native IP fragmentation is broken.

Testing will be helpful at this point, especially for non-x86-linux platforms.  
  

Download:

http://openvpn.sourceforge.net/beta/openvpn-1.4.1.9.tar.gz (or CVS)

Change Log:

* Removed adaptive bandwidth from
  --mtu-dynamic -- its absence appears
  to work better than its existence (1.4.1.2).
* Minor changes to --shaper to fix long
  retransmit timeouts at low bandwidth
  (1.4.1.2).
* Added LOG_RW flag to openvpn.h for
  debugging (1.4.1.2).
* Silenced spurious configure warnings (1.4.1.2).
* Backed out --dev-name patch, modified --dev
  to offer equivalent functionality (1.4.1.4).
* Added an optional parameter to --daemon and
  --inetd to support the passing of a custom
  program name to the system logger (1.4.1.5).
* Add compiled-in options to the program title
  (1.4.1.5).
* Coded the beginnings of a WIN32 port (1.4.1.5).
* Succeeded in porting to Win32 Mingw environment
  and running loopback tests (1.4.1.6).  Still
  need a kernel driver for full Win32
  functionality.
* Fixed a bug in error.h where
  HAVE_CPP_VARARG_MACRO_GCC was misspelled.
  This would have caused a significant slowdown
  of OpenVPN when built by compilers that
  lack ISO C99 vararg macros (1.4.1.6).
* Created an init script for Gentoo Linux
  in ./gentoo directory (1.4.1.6).

James

[Openvpn-devel] 1.4.x efficiency bug + 1.4.2 release candidate

[James Yonan]

1.4.0 and 1.4.1 have a fairly serious efficiency bug when built by compilers
which do not support ISO C99 vararg macros.  If you run ./configure with 1.4.0
or 1.4.1 and you see this line:

  checking for ISO C 1999 vararg macro support... no

you will be experiencing a significant slowdown due to this bug.

A minimal patch is available against 1.4.0 and 1.4.1:

http://openvpn.sourceforge.net/patch/isoc99fix.patch

Alternatively, you are encouraged to test the first 1.4.2 release candidate
which also contains a fix for the ISO C99 vararg bug, as well as:

* Removed adaptive bandwidth from
  --mtu-dynamic -- its absence appears
  to work better than its existence (1.4.1.2).
* Minor changes to --shaper to fix long
  retransmit timeouts at low bandwidth
  (1.4.1.2).
* Added LOG_RW flag to openvpn.h for
  debugging (1.4.1.2).
* Silenced spurious configure warnings (1.4.1.2).
* Backed out --dev-name patch, modified --dev
  to offer equivalent functionality (1.4.1.4).
* Added an optional parameter to --daemon and
  --inetd to support the passing of a custom
  program name to the system logger (1.4.1.5).
* Add compiled-in options to the program title
  (1.4.1.5).
* Coded the beginnings of a WIN32 port (1.4.1.5).
* Succeeded in porting to Win32 Mingw environment
  and running loopback tests (1.4.1.6).  Still
  need a kernel driver for full Win32
  functionality.
* Fixed a bug in error.h where
  HAVE_CPP_VARARG_MACRO_GCC was misspelled.
  This would have caused a significant slowdown
  of OpenVPN when built by compilers that
  lack ISO C99 vararg macros (1.4.1.6).
* Created an init script for Gentoo Linux
  in ./gentoo directory (1.4.1.6).

Download the release candidate:

http://openvpn.sourceforge.net/beta/openvpn-1.4.1.8.tar.gz

Release candidate is also available on CVS (note that sourceforge anonymous
CVS is now 24 hour delayed).

James

[Openvpn-devel] --dev and --dev-name under linux 2.4+

[James Yonan]

A debian bug report was submitted that inspired me to look deeper into the
operation of --dev and the new --dev-name flag.

--dev-name was a patch for tun.c which I received a few months ago, which only
really does anything for linux 2.4.  On first glance it appeared nominally
useful, so I merged it, but on further inspection it appears to be mostly
redundant with --dev.

It appears that the motivation for implementing --dev-name was that --dev
assumes its argument is either "tun", "tap", "null", or tun/tap with a unit
number (e.g. "tun4").  But --dev is limited in that it doesn't allow arbitrary
renaming.

In OpenVPN 1.3.2, if the --dev argument was larger than 3 chars, it was
assumed that a unit number was present.  In 1.4.1 that test was changed so
that an ascii digit needed to be present to assume a unit number.  If a unit
number was present, then the name of the device (as it appears in ifconfig)
would be changed to reflect the explicit unit number.  What I think probably
inspired the debian bug report is that in 1.3.2 if you said "--dev foobar
--dev-type tun", openvpn would have renamed the tun device to foobar, because
foobar is > 3 characters.  In 1.4.1, no rename would occur because "foobar"
doesn't contain any numerical digits.  In 1.4.1, you would need to say "--dev
tun --dev-name foobar" to get the same effect.  This seems somewhat arbitrary
and confusing.

My conclusion is that the implementation of --dev and --dev-name is mostly
redundant because --dev can just as easily set the device name based on its
argument, if that argument is something other than "tun", "tap", "null".  The
current operation of "--dev tun" or "--dev tap" would be preserved so that a
dynamic unit number would be allocated if, for example, "--dev tun4" is given.
 But you could also specify "--dev foo --dev-type tun" and a tun device named
foo would be created.

I've patched the current development release to remove --dev-name, and to
allow --dev to set a specific device name as in the above paragraph.

Download:

http://openvpn.sourceforge.net/beta/openvpn-1.4.1.4.tar.gz (or CVS)

James

[Openvpn-devel] OpenVPN 1.4.1 Released

[James Yonan]

This release fixes two bugs in 1.4.0, including a build issue on OpenBSD, and
a bug under Linux 2.4 that can cause 100% CPU utilization if the --verb 0
option is used to suppress all output.

In addition, if a Linux 2.4 TUN/TAP open attempt fails, the code will now fall
back to the 2.2 TUN/TAP interface and try again.

http://sourceforge.net/projects/openvpn/

James

[Openvpn-devel] Release candidate for 1.4.1

[James Yonan]

A couple of bugs have surfaced in 1.4.0, including a problem with --verb 0
under Linux 2.4 and a trivial compile problem for OpenBSD.

I'd like to release 1.4.1 soon, which resolves both of these issues.

Please test this release candidate if possible.

Download:

http://openvpn.sourceforge.net/beta/openvpn-1.4.0.3.tar.gz

ChangeLog:

* Modified the Linux 2.4 TUN/TAP open code to
  fall back to the 2.2 TUN/TAP interface if the
  open or ioctl fails.
* Fixed bug when --verb is set to 0 and non-fatal
  socket errors occur, causing 100% CPU utilization.
  Occurs on platorms where
  EXTENDED_SOCKET_ERROR_CAPABILITY is defined,
  such as Linux 2.4.
* Fixed typo in tun.c that was preventing
  OpenBSD build.

James

Re: [Openvpn-devel] an idea for openvpn..

[James Yonan]

Aaron,

I've found that the linux scheduler on 2.4 does a fairly good job at giving
openvpn the CPU that it needs, even on a more heavily loaded system.  When
openvpn is forwarding tunnel packets, it is essentially i/o bound, and as such
gets a priority boost.  When TLS keys are being negotiated, however, openvpn
becomes a CPU hog for as much as several seconds, so you wouldn't want to lock
up the machine during this period, especially given the fact that TLS
renegotiations are not in the critical path of tunnel packet forwarding
operations.  Overall, it's not clear to me that we need more scheduling
flexibility than --nice or --nice-work can give us.  And nice scheduling has
the safety factor as well of never completely locking up the machine, even if
something of high priority does a CPU grab.

James

Aaron Sethman  said:

> 
> One of the things that I just thought about is, that we can probably have
> openvpn call sched_setscheduler() using something like SCHED_RR.  This
> might be of more use than just renicing the process.  Considering we are
> in a fairly performance critical path for a userspace process this would
> seem to make sense.  Not sure how to deal with SCHED_RR wrt to threads
> though.  On my systems I haven't noticed much of a difference, when doing
> this, but my systems aren't heavily loaded either.
> 
> Thoughts, comments?
> 
> -Aaron
> 
> 
> ---
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] 1.4.0 Released

[James Yonan]

Download:

http://sourceforge.net/projects/openvpn/

Release Notes:

This release adds options for persistence of replay protection information
across sessions, pass through of IPv4 TOS bits from the TUN/TAP device to the
UDP link, some advanced MTU control options, moderate revamping of the build
system to improve portability, and misc bug fixes and web site additions.

Also new is a major restructuring of MTU and fragmentation handling. Much of
this code is experimental and must be explicitly enabled by defining
FRAGMENT_ENABLE and rebuilding.

Change Log:

* Added --replay-persist feature to allow replay
  protection across sessions.
* Fixed bug where --ifconfig could not be used
  with --tun-mtu.
* Added --tun-mtu-extra parameter to deal with
  the situation where a read on a TUN/TAP device
  returns more data than the device's MTU size.
* Fixed bug where some IPv6 support code for
  Linux was not being properly ifdefed out for
  Linux 2.2, causing compile errors.
* Added OPENVPN_EXIT_STATUS_x codes to
  openvpn.h to control which status value
  openvpn returns to its caller (such as
  a shell or inetd/xinetd) for various conditions.
* Added OPENVPN_DEBUG_COMMAND_LINE flag to
  openvpn.h to allow debugging in situations
  where stdout, stderr, and syslog cannot be used
  for message output, such as when OpenVPN is
  instantiated by inetd/xinetd.
* Removed owner-execute permission from file
  created by static key generator (Herbert Xu
  and Alberto Gonzalez Iniesta).
* Added --passtos option to allow IPv4 TOS bits
  to be passed from TUN/TAP input packets to
  the outgoing UDP socket (Craig Knox).
* Added code to prevent open socket file descriptors
  from being accessible to called scripts.
* Added --dev-name option (Christian Lademann).
* Added --mtu-disc option for manual control
  over MTU options.
* Show OS MTU value on UDP socket write failures
  (linux only).
* Numerous build system and portability
  fixes (Matthias Andree).
* Added better sensing of compiler support for
  variable argument macros, including (a) gcc
  style, (b) ISO C 1999 style, and (c) no support.
* Removed generated files from CVS.  Note INSTALL
  file for new CVS build commands.
* Changed all internal _* symbols to x_*
  for C standards compliance.
* Added TUN/TAP open code to cycle dynamically
  through unit numbers until it finds a free
  unit (based on code from Thomas Gielfeldt
  and VTun).
* Added dynamic MTU and fragmenting infrastructure
  (Experimental).  Rebuild with FRAGMENT_ENABLE
  defined to enable.
* Minor changes to SSL/TLS negotiation, use
  exponential backoff on retransmits, and use
  a smaller MTU size (note that no protocol
  changes have been made which would break
  compatibility with 1.3.x).
* Added --enable-strict-options flag
  to ./configure.  This option will cause
  a more strict check for options compatibility
  between peers when SSL/TLS negotiation is used,
  but should only be used when both OpenVPN peers
  are of the same version.
* Reorganization of debugging levels.
* Added a workaround in configure.ac for
  default SSL header location on Linux
  to fix RH9 build problem.
* Fixed potential deadlock when pthread support
  is used on OSes that allocate a small socketpair()
  message buffer.
* Fixed openvpn.init to be sh compliant
  (Bishop Clark).
* Changed --daemon to wait until all
  initialization is finished before becoming a
  daemon, for the benefit of initialization
  scripts that want a useful return status from
  the openvpn command.
* Made openvpn.init script more robust, including
  positive indication of initialization errors
  in the openvpn daemon and better sanity checks.
* Changed --chroot to wait until initialization
  is finished before calling chroot(), and allow
  the use of --user and --group with --chroot.
* When syslog logging is enabled (--daemon or
  --inetd), set stdin/stdout/stderr to point
  to /dev/null.
* For inetd instantiations, dup socket descriptor
  to a >2 value.
* Fixed bug in verify-cn script, where test would
  incorrectly fail if CN=x was the last component
  of the X509 composite string (Anonymous).
* Added Markus F.X.J. Oberhumer's special
  license exception to COPYING.

James

[Openvpn-devel] Third release candidate for 1.4.0

[James Yonan]

This release candidate fixes some longstanding annoyances with the
openvpn.init script, making it more robust, with better sanity checks on
command line options, and more accurate reporting of fail/success status back
to the caller.

The later feature required some changes to the way that --daemon works. 
--daemon now switches output to the syslog as soon as the daemon option is
parsed off the command line or config file.  But the daemonization point is
delayed until all initialization is complete.  Therefore, most fatal errors on
initialization will occur before daemonization, allowing the error status to
be returned to the init script.

http://openvpn.sourceforge.net/beta/openvpn-1.3.2.35.tar.gz

James

Re: [Openvpn-devel] Openvpn for RH62 - eek!

[James Yonan]

How do most other initialization scripts handle the differences between bash 1
and 2?  Do they just restrict themselves to the least common denominator (a)?

Or do they try to explicitly instantiate bash2 (b)?

-#!/bin/sh
+#!/bin/bash2

(b) could be risky if there are distros where where /bin/bash2 is not present.

I would lean towards (a) if trivial changes in the script can make it both
bash1 and bash2 compliant.  If that is not the case, and we think that we have
a reliable, distro-independent method to instantiate bash2, then I would favor
(b).

What does the patch look like for (a)?

James

bishop  said:

> James, Folks,
> 
> I noticed a minor problem as my RH62 box started up:
> 
> > $Starting openvpn: /etc/rc.d/init.d/openvpn: [: ==: binary operator expected
> 
> That's two distinct, common errors:
>   - $localization stuff that doesn't work on bash1
>   - an == in a [] in the script.
> 
> These are both directly related to the fact that the standard bash on 
> RH62 is bash1.  We can fix compatibility in a few ways:
>   - ignore the odd $localization $artefact and make the one change to 
> the init script (as if we did perl -pi -e 's:==:=:' to is) in one place.
> 
> OR
>   - this patch:
> 
> > --- /etc/rc.d/init.d/openvpn~   Sun Apr 27 03:51:51 2003
> > +++ /etc/rc.d/init.d/openvpnThu May  1 12:07:50 2003
> > @@ -1,4 +1,4 @@
> > -#!/bin/sh
> > +#!/bin/bash2
> >  #
> >  # openvpn   This shell script takes care of starting and stopping
> >  #   openvpn.
> 
> Super-trivial, but I'm wondering about any possible complications with 
> either approach.  As it is now, we do have a valid bug in that, on RH62, 
> openVPN will not start.
> 
> (I also noticed I can start it multiple times.  This may be another 
> problem - service openvpn start ; service openvpn start ; service 
> openvpn start ; service openvpn start - because it should normally 
> generate a minor gripe message)
> 
> Anyway, whatever the consensus, I can submit a patch.
> 
>   - bish
> 
> -- 
>   "Every well-bred petty crook knows -- the small concealable
>   weapons always go to the far left of the place setting."
>   -- Inara (Morena Baccarin), "Firefly"
>  (unaired - into production AFTER fox crushed it)
> 
> 
> 
> ---
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] 2nd release candidate for 1.4.0

[James Yonan]

This release candidate fixes some build problems that surfaced on the outliers
of the RedHat distribution (6.2 and 9.0).  Other minor fixes as well (see the
change log).

Tarball is here:

http://openvpn.sourceforge.net/beta/openvpn-1.3.2.30.tar.gz

James

Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

[James Yonan]

Aaron Sethman <andro...@ratbox.org> said:

> 
> On Thu, 24 Apr 2003, James Yonan wrote:
> > Actually, I was thinking more about the situation where people are forced to
> > tunnel IP over TCP, for whatever reason, when UDP is not an option.  Since 
> > IP
> > is designed to transit over an unreliable physical layer, when you tunnel it
> > over TCP (a la vpnd or IP over ssh) you end up with this problem:
> >
> > http://sites.inka.de/sites/bigred/devel/tcp-tcp.html (see Stacking TCPs)
> I've read the paper many times, heh ;)
> 
> >
> > The key issue here is that when you tunnel IP over TCP, that will usually 
> > mean
> > TCP over TCP.  And this tends to break TCP's retransmission algorithm.  As 
> > the
> > article above states: "The upper layer will queue up more retransmissions
> > faster than the lower layer can process them".
> >
> > So my idea is why not filter out the upper layer TCP retransmissions, and
> > synthesize the return ACKs so that the upper TCP layer doesn't begin the
> > exponential backing off of the retransmit timer that eventually will stall 
> > the
> > connection?  This process would essentially strip the upper layer TCP of its
> > reliability function, since now the lower TCP layer will provide that
> > function.  This is not difficult to implement, since to OpenVPN, the upper
> > layer protocols are all simply byte streams flowing over the TUN pipe.  They
> > can be filtered without resorting to raw sockets or any other such 
> > potentially
> > unportable constructs.
> What if you end up filtering out necessary retransmissions that occur
> elsewhere on the path.  Consider the situation of one end being a router
> and passing packets out to the rest of the world, and openvpn is being
> used to brige an insecure link like say an 802.11b network.  Personally I
> think mucking with this could be dangerous.

That's a good point.  Once you synthesize an ACK to avoid retransmission over
the TCP-tunnel segment of the path, you are guaranteeing to the sender that
the packet has been received at the destination.  This means you would need to
do some accounting of TCP sequence numbers at both ends of the tunnel, so that
you could differentiate retransmits caused by local congestion on the
TCP-tunnel from retransmits occurring due to lossage elsewhere on the path. 
The more you look at it, the uglier it gets.

What you need is a kind of TCP mode that strips out the reliability function.
 Of course we have it, it's called UDP ;)

James

Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

[James Yonan]

Aaron Sethman <andro...@ratbox.org> said:

> 
> 
> On Wed, 23 Apr 2003, Matthias Andree wrote:
> 
> > On Wed, 23 Apr 2003, James Yonan wrote:
> >
> > > I wonder if one could build a better tcp-over-tcp by doing some 
> > > intelligent
> > > packet filtering on the higher level tcp connection, such as filtering out
> > > retransmits and fudging return ACKs -- essentially removing those
elements of
> > > the TCP protocol which are designed to make TCP work over an unreliable
link.
> >
> > I wonder if that's necessary. Tunnelling through TCP is inherently
> > reliable no matter what you send, so TCP-nested-in-TCP is just overkill.
> > Cheating the OS doesn't help. Maybe some LD_PRELOAD library that turns
> > stream sockets into dgram sockets for connections that use the tunnel is
> > sufficient. However, this doesn't actually apply to openvpn because
> > openvpn does TCP-over-UDP.
> 
> I think you've got it backwards.  I think James is talking about the layer
> that openvpn is tunnelling over.  Basically fiddling with it to keep that
> layer from doing a lot of the reliabilitiy stuff.  To be honest I'm not
> sure its possible without using raw sockets and constructing your own TCP
> packets.  Even then though, I don't think that would work for some
> people's needs like being able to shove it through an SSL proxy or
> something like that.

Actually, I was thinking more about the situation where people are forced to
tunnel IP over TCP, for whatever reason, when UDP is not an option.  Since IP
is designed to transit over an unreliable physical layer, when you tunnel it
over TCP (a la vpnd or IP over ssh) you end up with this problem:

http://sites.inka.de/sites/bigred/devel/tcp-tcp.html (see Stacking TCPs)

The key issue here is that when you tunnel IP over TCP, that will usually mean
TCP over TCP.  And this tends to break TCP's retransmission algorithm.  As the
article above states: "The upper layer will queue up more retransmissions
faster than the lower layer can process them".

So my idea is why not filter out the upper layer TCP retransmissions, and
synthesize the return ACKs so that the upper TCP layer doesn't begin the
exponential backing off of the retransmit timer that eventually will stall the
connection?  This process would essentially strip the upper layer TCP of its
reliability function, since now the lower TCP layer will provide that
function.  This is not difficult to implement, since to OpenVPN, the upper
layer protocols are all simply byte streams flowing over the TUN pipe.  They
can be filtered without resorting to raw sockets or any other such potentially
unportable constructs.

Using raw sockets would be another potential method -- instead of removing the
reliability function from the upper layer TCP layer, remove it from the lower
layer.  This would require a sort of fake-TCP implementation in user-space
with the reliability function stripped out.  On first glance, this seems to be
a more complicated approach because you would need to implement a lot of the
TCP protocol in user space, and you would need to depend on the OS supporting
raw sockets.  The approach outlined in the previous paragraph doesn't need raw
sockets, and it doesn't need to reimplement TCP.  It only needs to examine the
byte stream of IP packets flowing over the TUN device, filter out TCP
retransmits, and synthesize return TCP ACKs.

Each method tries to stabilize TCP-over-TCP by eliminating a redundant
reliability layer.  Both of these methods, while somewhat ugly, would
eliminate a big part of the robustness issue of IP over TCP, for those who
lack IP over UDP as an option.

James

[Openvpn-devel] Release candidate for 1.4.0

[James Yonan]

We're on the final stretch for 1.4.0, so if possible, please give this release
a spin.

http://openvpn.sourceforge.net/beta/openvpn-1.3.2.24.tar.gz

I plan to release 1.4.0 shortly if there are no problems.

James

Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

[James Yonan]

Matthias Andree  said:

> On Sat, 19 Apr 2003, Aaron Sethman wrote:
> 
> > I'm not necessarly sure it belongs in OpenVPN, but then again, I can see
> > the advantages to automatically failover to other links.  Perhaps
> > abstracting things out in the code a bit that it would be possible to have
> > multiple methods of sending data out to the world, perhaps even non-ip
> > methods.  Or even implementing something as tunnelling over TCP(I do know
> > the reasons why you don't want to do this, but in some cases you don't
> > have a choice, and are willing to eat the performance loss).
> 
> TCP-over-TCP tunnelling isn't necessarily a performance loss, but it
> also exhibits excessive retransmit behaviour -- which isn't too bad if
> you have congested links and need to take a bigger share than the others
> ;-) I've always found vpnd (tcp-over-tcp) to be more stable than vtund
> (over udp in my configurations) across congested links, but I haven't
> compared vpnd to openvpn. (And I've found vtund to be fragile, a single
> ping -f into a tunnel usually let the tunnel collapse on Linux. OpenVPN
> is solid in these circumstances.)

I wonder if one could build a better tcp-over-tcp by doing some intelligent
packet filtering on the higher level tcp connection, such as filtering out
retransmits and fudging return ACKs -- essentially removing those elements of
the TCP protocol which are designed to make TCP work over an unreliable link.

James

[Openvpn-devel] Fwd: RE: Multi-channel VPN

[James Yonan]

I'm forwarding this discussion of an interesting feature request.  Namely,
could (and should) OpenVPN have a channel bonding capability, where more than
one UDP connection over different paths is used to connect two peers, and
OpenVPN does channel bonding, load balancing, and failover among the
connections?  Or does this function not belong in OpenVPN since it is
functionally distinct from the role of network security and tunneling and
could be implemented as a module or driver apart from OpenVPN?

James

Forwarded From: "R. Latimer" <lati...@orcon.net.nz>

> Hi,
> 
> Certainly, I don't mind if you wish to post to the list.
> 
> My reason for suggesting this be done in OpenVPN is primarily due to the
> ability to support multiple platforms (my e-mail should say
> platform-independant, not hardware-independant) without relying on
> additional software being installed at both ends, or OS-specific solutions.
> 
> Thanks,
> 
> - R. Latimer
> 
> -Original Message-
> From: James Yonan [mailto:j...@yonan.net]
> Sent: Thursday, 17 April 2003 22:40
> To: R. Latimer
> Subject: Re: Multi-channel VPN
> 
> 
> Mr. Latimer,
> 
> It's an interesting idea, though I'm not sure that OpenVPN is the right
> place
> to put the channel bonding code.
> 
> Since OpenVPN leaves all routing control to the OS, it would seem to make
> more
> sense to implement the channel bonding at the router level, since channel
> bonding is functionally distinct from the role of a VPN.
> 
> Having said that, it would certainly be possible to implement this in
> OpenVPN
> though it would add the complexity of load balancing, failover, to OpenVPN.
> It would also introduce issues of flow control on the UDP channel(s) that
> OpenVPN hasn't had to deal with before.
> 
> If you don't mind, I would like to post this thread to the list so that
> others
> can comment.
> 
> James
> 
> "R. Latimer" <lati...@orcon.net.nz> said:
> 
> > Hi James,
> >
> > Sorry to e-mail you directly rather than using the mailing list. I'm not
> > presently subscribed to the development list, but have a feature
> suggestion
> > you may wish to give some consideration (Post-1.4, perhaps much further
> down
> > the development path).
> >
> > I was wondering if it would be possible to allow OpenVPN to use multiple
> > paths to connect two networks? E.g. use two Internet connections here to
> > connect to a single remote VPN. I see no reason both ends couldn't use
> > multiple paths, but a simple one to many relationship alone would be
> handy.
> >
> > The reason for this is, Internet access in NZ is very expensive. I have a
> > 128k connection, and am looking at getting 128k a wireless connection as
> > well for use with a laptop. The VPN terminates in the US, where bandwidth
> is
> > plentiful, and supplying the VPN with 256k wouldn't be a problem.
> >
> > I would like to be able to join the two channels when the laptop is
> > connected to the LAN, and when unavailable, have all traffic automatically
> > sent through a single interface.
> >
> > Each interface would be with a different ISP, so traditional routing
> > protocols to one IP address wouldn't work in this case. In fact, the local
> > telephone company specifically disallows static IPs on the 128k
> > connections - they are only permitted on the expensive (pay per MB)
> > high-speed ADSL connections.
> >
> > I believe this would be possible using two instances of OpenVPN, and
> > NetGraph on FreeBSD, but unfortunately the remote end uses Linux. If
> > possible to do this in OpenVPN, it would provide a hardware-independant
> way
> > to link multiple channels. Currently NetGraph contains no code for
> > intelligently determining the path, it simply alternates between ports. It
> > would be great if OpenVPN could additionally favour one link over another
> > based on actual performance.
> >
> > I've been using OpenVPN since the FreeBSD port became available, and it
> > works very well. Thanks for such a great tool, and I hope you'll give my
> > suggestion some thought.
> >
> > Thanks,
> >
> > - R. Latimer
> >
> >
> 
> 
> 
> --
> 
> 
> 
> 
> 
> 



-- 

Re: [Openvpn-devel] Re: New beta available + progress update

[James Yonan]

Matthias Andree <ma+ov...@dt.e-technik.uni-dortmund.de> said:

> On Thu, 17 Apr 2003, James Yonan wrote:
> 
> > A better alternative (orginally suggested by you) is to avoid fragmenting in
> > the first place by bouncing back ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED to the 
> > TUN
> > device.  This won't work on TAP devices because the ethernet MTU is fixed
at 1500.
> > 
> > Unfortunately (or fortunately depending on your perspective), my network
> > connections are not broken enough to benefit from the FRAGMENT_ENABLE stuff
> > just yet, so I can't really test it properly.
> 
> Well, the peer that was behind an overloaded 1 Mbps 2 km radio link has
> now moved and has become a V.34+ modem link (33k6 bps), with
> corresponding effects on the MTU. I wonder if running a local pppd pair
> with properly MTU can be used to figure if fragmentation works, but
> there's yet have to be someone who drops individual fragments (unless
> gremlin mode does it already) for real testing.

Gremlin tests that the dynamic MTU/bandwidth algorithm can survive, but
doesn't really help when it comes to tuning the algorithm for optimality in
real-world conditions.

The nice part about a radio link is that it is probably under your control,
meaning that you can ensure that ICMPs get properly passed.  This allows path
MTU discovery to work and therefore solves a lot of the harder problems.

In this case, the FRAGMENT_ENABLE code would take the Path MTU hint from the
OS rather than trying to figure it out empirically by trial-and-error.  The
current FRAGMENT_ENABLE code knows how to get the PMTU from Linux, but still
needs code for other OSes.

> OTOH, fragmenting links also have a natural impact on the packet loss:
> if you assume 10% packet loss on the transport layer (that transports
> the fragment), and you fragment a TAP packet of 1500+ bytes into 3 of
> approx 500 bytes (say, MTU=552), the effective packet loss for TCP or
> something is much higher: it takes losing a single fragment to
> retransmit, so the effective packet loss will come out as 27% (not
> taking burst loss into account).

Good point.

> I also have another patch to fix prototype warnings:

Merged.

James

> 
> diff -u thread.h thread.h
> --- thread.h  17 Apr 2003 10:51:21 -
> +++ thread.h  17 Apr 2003 11:05:38 -
> @@ -118,17 +118,17 @@
>  #define MUTEX_UNLOCK(lock)
>  
>  static inline void
> -thread_init()
> +thread_init(void)
>  {
>  }
>  
>  static inline void
> -thread_cleanup()
> +thread_cleanup(void)
>  {
>  }
>  
>  static inline int
> -thread_number()
> +thread_number(void)
>  {
>return 0;
>  }
> @@ -139,7 +139,7 @@
>  }
>  
>  static inline void
> -work_thread_join ()
> +work_thread_join (void)
>  {
>  }
>  
> 
> -- 
> Matthias Andree
> 
> 
> ---
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

Re: [Openvpn-devel] Re: New beta available + progress update

[James Yonan]

Matthias Andree  said:

> > http://openvpn.sourceforge.net/beta/openvpn-1.3.2.21.tar.gz (or CVS)
> 
> I have a next round of patches to fix prototypes and types to quench
> compiler warnings and get a more robust source code against changed
> environments, to aid possible later debugging; it also includes GCC
> extensions (only used when GCC is being used) that allow stricter msg()
> and buf_printf() format string vs. argument checking, to avoid printing
> bogus data when type sizes differ (think 64 bit).

Yes, very good ideas.  I will merge.

> 
> One problem remains after applying the patch:
> openvpn.c: In function `openvpn':
> openvpn.c:470: warning: cast discards qualifiers from pointer target type

That's a tricky matter, because the struct options object is const, but it
needs to be passed to a thread, and normally you need to cast something to a
void* if you want to pass it to a thread as an argument, which then causes the
constness to be lost.

> Other than that, we have unused parameter warnings (you said before
> you're not fixing them), shadow parameter warnings (variable names being
> the same as system functions, such as time or nice)

I'm not too worried about the shadow parameters.  I think it's pretty obvious
when something is being used as a variable vs. a function call.

As for the unused parms, they are mostly a result of conditional compilation
making certain variables unnecessary.  OpenVPN has a large conditional
compilation state-space, so I'm not sure that it makes sense to try to
eliminate all such warnings.

> and in particular,
> aggregate (struct) values in function calls and function returns, these
> are inefficient (as the compiler must toss the whole struct on the
> stack, which involves copy overhead), and some of them (buffer.c in
> particular) look pretty suspicious. Is there any C standard that
> guarantees that returning an auto struct works and copies the return
> value?

While I can't quote chapter and verse, being able to manipulate structures in
a value context, such as returning them from functions or passing them on the
stack, has been a part of C for ages, and for a long time compilers have tried
very hard to optimize this usage as much as possible.

For example, when a function returns an automatic structure, most compilers
will optimize this into a zero-copy operation, where the functions's
references to the automatic structure go directly into a variable allocated by
the caller for its return.

My attitude towards optimization has been to optimize the code across the
critical path only, which is essentially the event loop in openvpn.c.  Code
outside the event loop (such as the SSL negotiation) does not need to be
optimized with respect to CPU usage, because it is executed infrequently in
relation to the main event loop and OpenSSL EVP crypto code.

Most of the expensive buffer.[ch] code is only executed on startup, shutdown,
SIGHUP, or when the debug level is high.

[ patch deleted ]

James

[Openvpn-devel] Re: New beta available + progress update

[James Yonan]

Matthias Andree  said:

> > What the FRAGMENT_ENABLE code does is to add an extra 4 byte header to each
> > datagram that includes, among other things, feedback on the number of
> > datagrams received as well as the maximum datagram size received.  This
> > information can then be used by an OpenVPN peer to dynamically set the MTU
> > size as well as the datagram transmit rate independently of the OS and the
> > proper functioning of path MTU discovery.  Ultimately this code can make
> > OpenVPN more robust in situations where fragmentation is necessary (such as 
> > in
> > TAP-based bridged ethernets) when firewalls or routers in the path break 
> > PMTU
> > discovery.
> 
> How about compatibility? Does this need a FRAGMENT_ENABLEd OpenVPN on
> either side of the tunnel or will OpenVPN negotiate the fragment
> capability dynamically as well?

Negotiation of the fragment capability is similar to how other parameters are
negotiated, such as cipher algorithm, lzo compression, etc.  The option
(--mtu-dynamic) must be used on both ends of the connection.  In SSL mode,
both peers will complain if --mtu-dynamic is used on one end but not the
other.  In non-SSL mode, there is no negotiation, so each peer assumes that
the other is using compatible options.

> Does this FRAGMENT_ENABLE rely on SSL or
> will it work with preshared keys?

No, it doesn't rely on SSL or pre-shared keys.  It can work even on plaintext
tunnels.

I think the major issue still to be worked out is how to make it efficient. 
While I've written a simple heuristic (see fragment_adjust_mtu_bandwidth() in
fragment.c) that is a starting point for determining MTU and transmit throttle
levels based on feedback from the peer, I'm finding a big performance dropoff
once the fragmenting code kicks in.  A big reason for this is packet loss,
that can be seen if you run ftp over the tunnel.  When there is a one-to-one
correspondence between TUN/TAP packets and UDP datagrams (as there is in
non-FRAGMENT_ENABLE openvpn), then the TCP level does the heavy lifting in
terms of pushing packets at the optimal rate to avoid packet loss.  Once
openvpn starts doing its own fragmenting, then it also needs to take explicit
control over the transmit rate (as it can now do statically with --shaper).

A better alternative (orginally suggested by you) is to avoid fragmenting in
the first place by bouncing back ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED to the TUN
device.  This won't work on TAP devices because the ethernet MTU is fixed at 
1500.

Unfortunately (or fortunately depending on your perspective), my network
connections are not broken enough to benefit from the FRAGMENT_ENABLE stuff
just yet, so I can't really test it properly.

James

[Openvpn-devel] New beta available + progress update

[James Yonan]

OpenVPN continues to evolve, and I thought I would take this opportunity to
briefly describe some of the current directions in the project (which,
incidentally, has passed its 1 year milestone).

For one, a new OpenVPN beta is available and testing would be appreciated.

http://openvpn.sourceforge.net/beta/openvpn-1.3.2.21.tar.gz (or CVS)

Thanks to the stability of 1.3.2, I've held off on making a new release that's
composed entirely of minor changes, and have instead focussed on some bigger
issues such as making the handling of MTU and fragmentation more dynamic and
automatic.  To this end, the new beta contains a number of improvements to
allow for dynamic MTU resizing.  This code is still experimental, and must be
explicitly enabled by defining FRAGMENT_ENABLE and rebuilding.

What the FRAGMENT_ENABLE code does is to add an extra 4 byte header to each
datagram that includes, among other things, feedback on the number of
datagrams received as well as the maximum datagram size received.  This
information can then be used by an OpenVPN peer to dynamically set the MTU
size as well as the datagram transmit rate independently of the OS and the
proper functioning of path MTU discovery.  Ultimately this code can make
OpenVPN more robust in situations where fragmentation is necessary (such as in
TAP-based bridged ethernets) when firewalls or routers in the path break PMTU
discovery.

My thinking right now is to make the next release 1.4.0 but leave the
FRAGMENT_ENABLE code off by default.  Even with the FRAGMENT_ENABLE code
disabled, there's enough new stuff here to justify a point release.

As well, there are a fair number of minor changes as well (see the ChangeLog
at the end of this message).

Looking post-1.4.0, the latest wishlist appears to be:

(1) Simplify configuration for setups that involve one server and numerous
roving clients (some of this has already been addressed by the --inetd option).

(2) Dynamic MTU support.  Ultimately, the FRAGMENT_ENABLE code will do this,
but it still needs testing and more developer input.

(3) Porting to Windows.  Judging by email I receive, there seems to be a lot
of demand for this.  In addition, a lot of developers have come forward who
are interested in working on a TUN/TAP driver for Windows (which is the
missing link), but so far I haven't seen much progress.  I may jump into the
fray and work on this myself, though due to the higher costs of developing for
Windows, I would need some corporate sponsorship to help defray costs.  Let me
know if you are interested in sponsoring such an undertaking.

If there are wishlist items I have missed, or if there is something you would
like to add, please let us know.

And also, please be reminded that the OpenVPN project is financially supported
by the user community.  Please consider donating to the project.  More info is
available here:

http://openvpn.sourceforge.net/donate.html

James

**

ChangeLog:

$Id: ChangeLog,v 1.69 2003/04/17 07:12:02 jimyonan Exp $

Upcoming version 1.4.0

* Added --replay-persist feature to allow replay
  protection across sessions.
* Fixed bug where --ifconfig could not be used
  with --tun-mtu.
* Added --tun-mtu-extra parameter to deal with
  the situation where a read on a TUN/TAP device
  returns more data than the device's MTU size.
* Fixed bug where some IPv6 support code for
  Linux was not being properly ifdefed out for
  Linux 2.2, causing compile errors.
* Added OPENVPN_EXIT_STATUS_x codes to
  openvpn.h to control which status value
  openvpn returns to its caller (such as
  a shell or inetd/xinetd) for various conditions.
* Added OPENVPN_DEBUG_COMMAND_LINE flag to
  openvpn.h to allow debugging in situations
  where stdout, stderr, and syslog cannot be used
  for message output, such as when OpenVPN is
  instantiated by inetd/xinetd.
* Removed owner-execute permission from file
  created by static key generator (Herbert Xu
  and Alberto Gonzalez Iniesta).
* Added --passtos option to allow IPv4 TOS bits
  to be passed from TUN/TAP input packets to
  the outgoing UDP socket (Craig Knox).
* Added code to prevent open socket file descriptors
  from being accessible to called scripts.
* Added --dev-name option (Christian Lademann).
* Added --mtu-disc option for manual control
  over MTU options.
* Show OS MTU value on UDP socket write failures
  (linux only).
* Numerous build system and portability
  fixes (Matthias Andree).
* Added better sensing of compiler support for
  variable argument macros, including (a) gcc
  style, (b) ISO C 1999 style, and (c) no support.
* Removed generated files from CVS.  Note INSTALL
  file for new CVS build commands.
* Changed all internal _* symbols to x_*
  for C standards compliance.
* Added TUN/TAP open code to cycle dynamically
  through unit numbers until it finds a free
  unit (based on code from Thomas Gielfeldt
  and VTun).
* Added dynamic MTU and fragmenting infrastructure
  (Experimental).  Rebuild with FRAGMENT_ENABLE
  defined 

Re: [Openvpn-devel] New pre-1.3.3 beta

[James Yonan]

Matthias,

Patch looks good, though why the dummy() functions?  They generate warnings on
gcc 2.96 if you build with --disable-lzo, --disable-crypto, etc.  Some
compiler that doesn't like empty source files?

James

Matthias Andree <ma+ov...@dt.e-technik.uni-dortmund.de> said:

> On Sat, 15 Mar 2003, James Yonan wrote:
> 
> > Yes, I think we should try to fix if it's only a trivial cast involved to
> > silence the warning.
> > 
> > I don't see them on gcc 2.96, even with "-Wall -W -Wpointer-arith
> > -Wsign-compare -Winline".
> 
> Indeed, it takes the sun compiler or the even more picky splint utility
> (www.splint.org) to see them.
> 
> The patch below doesn't fix
> "crypto.c", line 228: warning: end-of-loop code not reached
> 
> also on ll. 237 259 269 273 277 281 286 299 312 327.
> 
> Fixing that would require a rewrite of crypto.c, the issue is the
> 
> do { goto ...; } while(false);
> 
> I'm not fixing this and I don't recommend changing that at this time
> (after 1.3.3 maybe, if you're to fix that at all).
> 
> Here's the patch:
> 
> # buffer.c |   14 +++---
> # crypto.c |   12 ++--
> # error.c  |2 +-
> # lzo.c|2 ++
> # misc.c   |2 +-
> # packet_id.c  |4 ++--
> # reliable.c   |2 ++
> # session_id.c |2 ++
> # socket.c |4 ++--
> # ssl.c|6 --
> # thread.c |2 ++
> # tun.c|4 ++--
> # 12 files changed, 33 insertions(+), 23 deletions(-)
> 
> Index: buffer.c
> ===
> RCS file: /cvsroot/openvpn/openvpn/buffer.c,v
> retrieving revision 1.11
> diff -u -r1.11 buffer.c
> --- buffer.c  15 Mar 2003 07:18:00 -  1.11
> +++ buffer.c  15 Mar 2003 22:42:02 -
> @@ -115,14 +115,14 @@
>  {
>va_list arglist;
>  
> -  char *ptr = BEND (buf);
> +  uint8_t *ptr = BEND (buf);
>int cap = buf_forward_capacity (buf);
>  
>va_start (arglist, format);
> -  vsnprintf (ptr, cap, format, arglist);
> +  vsnprintf ((char *)ptr, cap, format, arglist);
>va_end (arglist);
>  
> -  buf->len += strlen (ptr);
> +  buf->len += strlen ((char *)ptr);
>  }
>  
>  /*
> @@ -137,7 +137,7 @@
>int len = strlen (str) + 1;
>if (len < buf_forward_capacity_total (buf))
>   {
> -   strncpynt (buf->data + buf->capacity - len, str, len);
> +   strncpynt ((char *)(buf->data + buf->capacity - len), str, len);
>   }
>  }
>  }
> @@ -148,7 +148,7 @@
>  void
>  convert_to_one_line (struct buffer *buf)
>  {
> -  char *cp = BPTR(buf);
> +  uint8_t *cp = BPTR(buf);
>int len = BLEN(buf);
>while (len--)
>  {
> @@ -185,7 +185,7 @@
>struct gc_entry *e;
>struct gc_thread* thread = _gc_thread[thread_number()];
>  
> -  while (e = thread->gc_stack)
> +  while ((e = thread->gc_stack))
>  {
>if (e->level < level)
>   break;
> @@ -235,5 +235,5 @@
>buf_printf (, "%02x", data[i]);
>  }
>buf_catrunc (, "[more...]");
> -  return out.data;
> +  return (char *)out.data;
>  }
> Index: crypto.c
> ===
> RCS file: /cvsroot/openvpn/openvpn/crypto.c,v
> retrieving revision 1.14
> diff -u -r1.14 crypto.c
> --- crypto.c  21 Feb 2003 16:14:05 -  1.14
> +++ crypto.c  15 Mar 2003 22:42:03 -
> @@ -184,7 +184,7 @@
> HMAC_Update (ctx->hmac, BPTR (), BLEN ());
> output = buf_prepend (, HMAC_size (ctx->hmac));
> ASSERT (output);
> -   HMAC_Final (ctx->hmac, output, _len);
> +   HMAC_Final (ctx->hmac, output, (unsigned int *)_len);
> ASSERT (hmac_len == HMAC_size (ctx->hmac));
>   }
>  
> @@ -229,7 +229,7 @@
>  
> HMAC_Update (ctx->hmac, BPTR (buf) + hmac_len,
>  BLEN (buf) - hmac_len);
> -   HMAC_Final (ctx->hmac, local_hmac, _hmac_len);
> +   HMAC_Final (ctx->hmac, local_hmac, (unsigned int *)_hmac_len);
> ASSERT (hmac_len == in_hmac_len);
>  
> /* Compare locally computed HMAC with packet HMAC */
> @@ -883,9 +883,9 @@
>if (fd == -1)
>  msg (M_ERR, "Cannot open shared secret file %s", filename);
>  
> -  while (size = read (fd, in.data, in.capacity))
> +  while ((size = read (fd, in.data, in.capacity)))
>  {
> -  const char *cp = in.data;
> +  const char *cp = (char *)in.data;
>while (size)
>   {
> const char c = *cp;
> @@ -923,7 +923,7 @@
>   if (hb_index == 2)
&

[Openvpn-devel] New pre-1.3.3 beta

[James Yonan]

If you have a chance, please test this beta.  I mostly use linux 2.4 for
development, so I don't have much of a chance to test on linux 2.2 and
non-linux OSes.

Since the last beta announcement on this list, there's been a bunch of changes
including build system portability fixes, --dev-name, and --mtu-disc.  The
latter gives access to a linux system call that allows some manual control
over how and whether Path MTU Discovery is implemented on the UDP socket.

You can download via CVS or from a tarball:

http://openvpn.sourceforge.net/beta/openvpn-1.3.2.17.tar.gz

Change Log:

* Added --replay-persist feature to allow replay
  protection across sessions.
* Fixed bug where --ifconfig could not be used
  with --tun-mtu.
* Added --tun-mtu-extra parameter to deal with
  the situation where a read on a TUN/TAP device
  returns more data than the device's MTU size.
* Fixed bug where some IPv6 support code for
  Linux was not being properly ifdefed out for
  Linux 2.2, causing compile errors.
* Added OPENVPN_EXIT_STATUS_x codes to
  openvpn.h to control which status value
  openvpn returns to its caller (such as
  a shell or inetd/xinetd) for various conditions.
* Added OPENVPN_DEBUG_COMMAND_LINE flag to
  openvpn.h to allow debugging in situations
  where stdout, stderr, and syslog cannot be used
  for message output, such as when OpenVPN is
  instantiated by inetd/xinetd.
* Removed owner-execute permission from file
  created by static key generator (Herbert Xu
  and Alberto Gonzalez Iniesta).
* Added --passtos option to allow IPv4 TOS bits
  to be passed from TUN/TAP input packets to
  the outgoing UDP socket (Craig Knox).
* Added code to prevent open socket file descriptors
  from being accessible to called scripts.
* Added --dev-name option (Christian Lademann).
* Added --mtu-disc option for manual control
  over MTU options.
* Show OS MTU value on UDP socket write failures
  (linux only).
* Numerous build system and portability
  fixes (Matthias Andree).
* Added better sensing of compiler support for
  variable argument macros, including (a) gcc
  style, (b) ISO C 1999 style, and (c) no support.
* Removed generated files from CVS.  Note INSTALL
  file for new CVS build commands.
* Changed all internal _* symbols to x_*
  for C standards compliance.

James

Re: [Openvpn-devel] [PATCH]: add config-variables to OpenVPN-1.3.2

[James Yonan]

Christian,

Rather than put a lot of scripting language infrastructure into OpenVPN's
config file parser, why not just use a shell script, i.e.:

  openvpn --dev-name vpn_${CUSTNO} \
  --port 5${CUSTNO} \
  --ifconfig 10.0.0.1 10.0.${CUSTNO}.1 \
  --dev-type tun \
  [ ... ]

After all, isn't this exactly the sort of problem that shell scripting
languages were supposed to solve?

James

ZLS Software GmbH <510047448921-0...@t-online.de> said:

> Hi, Jim,
> 
> here is another one:
> 
> I've added variable-expandion to config-values and the keywords "set" and
"unset".
> With this technique you can easily split configuration of one peer across
two files:
> one with the specific and one with the common config values in a way that
can help to
> minimize the number of "configuration-knobs". 
> 
> 
> An example:
> 
> /etc/openvpn/customer_123.conf:
> 
> # specific configuration for customer #123
>   set CUSTNO 123
> config ./customers.common
> 
> 
> /etc/openvpn/customer.common:
> 
> # meta-configuration for all customers
> dev-name vpn_$(CUSTNO) # vpn_001 to vpn_255
> port 5$(CUSTNO)# 5001 to 5255
> ifconfig 10.0.0.1 10.0.$(CUSTNO).1 # 10.0.001.1 to 10.0.255.1
> dev-type tun   # other stuff ...
>.
>.
>.
> 
> These are the same variable-expansion routines I committed to the Snort-IDS
some time ago.
> 
> The syntax is  follows:
> 
> set name valuedefine the variable "name" containing "value".
> unset nameundefine the variable "name".
> 
> $(name)   replace with the contents of variable "name".
> 
> $(name:-default)  replace with the contents of the variable "name" or with
>   "default" if "name" is undefined.
> 
> $(name:?message)  replace with the contents of variable "name" or print 
> out
>   the error message "message" and exit.
> 
> 
> The next thing could be something like $(( expression or calculation )).
> 
> As before, the patch is quite young and certanly needs more testing :-)
> 
> 
> Regards,
> 
> Christian Lademann 
> 
> -- 
> *  Christian A. Lademann, ZLS Software GmbH  mailto:ladem...@zls.de
> *  ZLS Software GmbH
> *  Frankfurter Strasse 59   Postfach 1628 mailto:z...@zls.de
> *  D-65779 Kelkheim D-65766 Kelkheim  http://www.zls.de
> *  Telefon +49-6195-9902-0  Telefax +49-6195-900600
> 
> 
> 



-- 

Re: [Openvpn-devel] MTU

[James Yonan]

Jan Johansson <jan.johans...@biomatsys.com> said:

> On Sun, 2003-02-23 at 17:10, James Yonan wrote:
> > Russ,
> > 
> > Have you tried the tracepath utility to attempt to measure the Path MTU?
> > 
> > Are the routers in the path properly forwarding ICMP code 3 (destination
> > unreachable), and ICMP code 4 (fragmentation needed but don't-fragment bit
set)?
> > 
> > Most MTU problems are caused by routers and firewalls which do not handle
> > these ICMP codes correctly, causing path MTU discovery to break.
> > 
> > The symptoms of this problem are as you show below...  Running an app over 
> > the
> >  tunnel works fine initially until the first large packet is sent, then the
> > app hangs.
> 
> I have a different theory here. 
> I am experiencing what I believe to be MTU problems, which have made me
> switch from RSA-auth to shared-key, just because the RSA auth stuff
> seems to trigger it also.

That's interesting, though it makes sense that if OpenVPN thinks the MTU is
higher than it really is, that this would occur.  That's because the SSL/TLS
handshake involves some relatively large exchanges (several K octets) that are
fragmented by OpenVPN to the udp-mtu packet size.  In this case, if OpenVPN
thinks that the udp-mtu is 1300 then it will attempt to send packets of
exactly 1300 octets in size, until it reaches the last fragment which will
probably be smaller.  So essentially, OpenVPN's current method of fragmenting
SSL/TLS handshakes guarantees that it will push the MTU parameter it's given
to the limit (udp_mtu in this case).

> My theory is that part of the problem lies in how the Linux kernel
> handles udp. I already got it into the README-file that openbsd firewall
> scrub rules will "kill" openvpn the same way it will kill Linux-nfs, but
> somehow other routers along the route probably do similar things.
> 
> One of the problems is that Linux sometimes (this is more a vague
> feeling and guesswork than the next part) sends fragments in reverse,
> meaning that the second half of the packet will be sent before the first
> part of a split packet. This is why, for instance, you can't netboot Sun
> boxes from Linux tftp-servers. The prom-code (bios sort of) in Sun
> machines can't reassemble fragged packets, at least not packets that
> arrive in reverse. This might make routers and firewalls along the way
> to behave badly, especially with the next part in mind:
> 
> The second part is that linux will tag all UDP (or at least all UDP from
> OpenVPN and NFS) as "Dont fragment". This is sort of ok. The problem is,
> they do get fragmented anyway. I can't prove that it isn't related to
> the transport in between me and the peers I have set up, but I find it
> likely that someone is fragmenting them anyway, perhaps even by the
> sending linux box itself. Since there is a *BSD box in between in my
> case, it will regard any fragmented UDP (or ip) packet with DF set as a
> bug, it silently and without mercy kills them. It may also mean that if
> the second half of a fragment comes first, with the DF flag on, it's
> even more suspicious.

Well actually what you are observing here is RFC 1191 ("Path MTU Discovery")
in action (or inaction as the case may be :)

http://www.faqs.org/rfcs/rfc1191.html

This process causes the DF bit to always be set on outgoing packets, but
assumes that other routers and firewalls in the path will play nice and return
an "ICMP need fragmentation but DF set message" if the packet is too big.

For linux at least, Path MTU discovery can be turned off for a given UDP
socket, causing all packets to be sent with DF cleared and no attempt by the
kernel to offer fragmentation or defragmentation services.

I already have a feature in the CVS under branch MTU_EXPERIMENTAL which gives
command line control over the Path MTU discovery settings on the UDP socket.

> As far as I can guess, this probably goes for lots of ISP's and other
> hardware involved in the transport of ip packets between me and my
> peers. 
> For some reason, I seem to get the feeling that RSA negotiation doesn't
> follow the udp-mtu (or tun-mtu-derived udp-mtu) settings, and send too
> large packets, and them getting fragmented leads to me having to revert
> back to precalced secrets.

I will check this, but I doubt that SSL/TLS could go over the udp-mtu (I would
expect lots of errors and/or assertion crashes in OpenVPN if this was the
case).  It seems more likely to me that the udp-mtu might be too large.

> It also means that I get the same error as you've described in the last
> mails. I have a remote-backup-over-rsync that is protected by both
> OpenVPN and ssh inside of that. It goes some 256k and then dies. It dies
> reliably every time, and almost always on the

Re: [Openvpn-devel] MTU

[James Yonan]

Aaron Sethman <andro...@ratbox.org> said:

> 
> On Sat, 22 Feb 2003, James Yonan wrote:
> >  This might be handled in a way similar to --ping-restart or SIGHUP/SIGUSR1,
> > where the openvpn daemon would essentially restart if the MTU size changed.
> > This would be effective if path MTU changes are infrequent but still creates
> > problems when --user/--group nobody is used, since the openvpn daemon will
> > lack sufficient privilege to reopen and re-ifconfig the TUN/TAP device.
> >
> 
> One option to deal with the --user/--group stuff is to keep a parent
> process running as root with the real work being done by the child with
> dropped privledges.  The parent just waits around waiting for a signal
> regarding the child, and then let the parent start a new child.  Of course
> if you are going to go down the IPC route, there is other fun things you
> can do like passing sockets via AF_UNIX sockets.  It really depends on how
> you want to do it.
> 
> Regards,
> 
> Aaron

Aaron,

Actually OpenVPN has some of this right now.  If built with pthread support,
it will negotiate SSL/TLS keys in a background thread and communicate with the
foreground via a pair of AF_UNIX sockets (this helps tunnel latency a lot). 
The split-privilege model is a good idea, and has been implemented with some
success in OpenSSH, but is arguably overkill for OpenVPN given that up till
now, OpenVPN has been able to do all of its privileged work at startup, then
downgrade to nobody with little loss of flexibility.  IMHO, the alternative is
more complex and prone to becoming a bug-magnet.

James

Re: [Openvpn-devel] MTU

[James Yonan]

Russ,

Have you tried the tracepath utility to attempt to measure the Path MTU?

Are the routers in the path properly forwarding ICMP code 3 (destination
unreachable), and ICMP code 4 (fragmentation needed but don't-fragment bit set)?

Most MTU problems are caused by routers and firewalls which do not handle
these ICMP codes correctly, causing path MTU discovery to break.

The symptoms of this problem are as you show below...  Running an app over the
 tunnel works fine initially until the first large packet is sent, then the
app hangs.

Right now OpenVPN relies on Path MTU Discovery (a service provided by the
kernel) to get the MTU right, so in the short run the best thing you can do is
to try to get Path MTU working.

You could also try to lower --udp-mtu by trial and error until you find
something that works (essentially a manual approach to MTU discovery).

If you are running tunnels over tunnels, the lower-level (more nested) tunnels
will need lower --udp-mtu settings. 

Longer-term, I hope to put some intelligence in OpenVPN to do this 
automatically.

James

R P Herrold <herr...@owlriver.com> said:

> On Sat, 22 Feb 2003, James Yonan wrote:
> 
> > Recently I've been taking a new look at MTU issues.  It seems that some 
> > people
> > are having problems lately that are related to MTU or PMTU discovery.
> > 
> > I was trying to think up some ways to make OpenVPN's handling of MTU a bit
> > less opaque, more automatic, and also give more manual control to those who
> > know what they're doing.
> 
> If it is any help, I can replicate the error on demand.  Coing 
> frm my host 'couch', through two openvpn legs, once of which 
> is running encryption, the other not, I get:
> 
> [root@couch ORC]# scp ftp.victim.lan:/etc/ORC/* .
> r...@ftp.victim.lan's password:
> Permission denied, please try again.
> r...@ftp.victim.lan's password:
> ORCsetPXE  0% | | 
> 0   --:-- ETAKilled by signal 2.
> 
> it is locked up and hung here.
> 
> [root@couch ORC]# ssh ftp.victim.lan
> r...@ftp.victim.lan's password:
> Last login: Sat Feb 22 15:21:51 2003 from router.victim.lan
> [root@ftp root]# cd /etc/ORC
> [root@ftp ORC]# scp * couch.basement.lan:/etc/ORC
> The authenticity of host 'couch.basement.lan (10.16.33.101)' can't be
established.
> RSA1 key fingerprint is 38:d4:69:9e:cb:96:81:68:d2:2b:6b:6f:b9:33:c2:39.
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added 'couch.basement.lan,10.16.33.101' 
> (RSA1) to the list of known hosts.
> r...@couch.basement.lan's password:
> ORCsetPXE100% |*|  3032   00:00
> ORCsetPXE~   100% |*|  2955   00:00
> installCDrc  100% |*|   234   00:00
> installCDrc-80   100% |*|   227   00:00
> installCDrc-8094 100% |*|   234   00:00
> installCDrc-LTSP 100% |*|   188   00:00
> installCDrc-template 100% |*|   565   00:00
> [root@ftp ORC]#
> [root@ftp ORC]# dmesg
> Linux version 2.4.18-17.8.0 (bhcomp...@daffy.perf.redhat.com) 
> (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Tue 
> Oct 8 13:51:08 EDT 2002
> 
>   it is locked up and hung here.
> 
> 
> going to another host in that same remote subnet, but behind 
> the router I also get:
> 
> (from 10.16.33.101 - host: couch )
> 
> bash-2.05b$ ssh ftp.victim.lan
> herr...@ftp.victim.lan's password:
> [herrold@ftp herrold]$ dmesg
> Linux version 2.4.18-17.8.0 (bhcomp...@daffy.perf.redhat.com) 
> (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Tue Oct 8 13:51:08
EDT 2002
> 
>    it is locked up and hung here.
> 
> 
> lots of these on ftp.victim.lan:
> 
> ISO 9660 Extensions: RRIP_1991A
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> 
> but no 'noise; attributable to the tun device or openvpn in 
> the router:
> 
> 
> eth0: Promiscuous mode enabled.
> device eth0 entered promiscuous mode
> Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
> divert: not allocating divert_blk