openvpn-devel — OpenVPN developers list

[Openvpn-devel] CVS commit to 1.1.1.9

[James Y. <ji...@nt...>]

The CVS is now updated to 1.1.1.9.

Changes since 1.1.1.6 include the Solaris port and backport to OpenSSL
0.9.5.

James

RE: [Openvpn-devel] autovpn 0.1

[Jean-Eric C. <Jea...@li...>]

> I am interested in knowing wha tyour AutoVPN project does, but I
didn't=20
> understand after reading your letter.  Can you explain what it does?

OK. I thought I was clear... :-)

We need to let some of our users access our network from their home
through their Internet access (Modem or Cable or ADSL). So we need a VPN
for them. There is one called SecuRemote that comes with checkpoint
Firewall. But it's only for windows, not for Linux.

The goal is to have a VPN that needs only an account into one machine,
not a certificate. It's because it's easier to manage for a large bunch
of users. So we are using OpenVPN with *shared key*, not with TLS +
certificate.

The way that works:
- Open am SSH session to our gateway (inside the network)
- The user gives its password (no RSA key)
- A script is called on the server which:
  - generate a shared key
  - starts openvpn with it
  - returns this key to the client
- Then, the client starts openvpn passing the shared key
- The VPN is open.
Advatage:
- No need of certificates for every people
- No need of pre-shared key. It'changed every time a new autovpn session
is made

Understand better?
-jec

[Openvpn-devel] Mac OS X support

[Christoph P. <cp...@ch...>]

Hi all!

With some tweaking, I was able to get OpenVPN running on Mac OS X and 
use it happily with a Linux peer. Discussion and patches follow.

First of all, current versions of Mac OS X don't include a tun 
driver, although it is present in the source tree (publicly available 
via CVS). An independent port of the FreeBSD driver as a loadable 
module exists, but OpenVPN uncovered some bugs in it. I was able to 
fix those bugs and effectively took over maintenance of the driver. 
It is available from <http://chrisp.de/en/projects/tunnel.html>; 
OpenVPN requires at least version 1.1.0.

OpenVPN itself also needed some small patches, mostly due to Mac OS 
X's customized GCC and its outdated BSD headers. There are three main 
problems:

1. There is no in_addr_t and uint32_t is not automatically defined. 
Some research revealed that uint32_t is defined in <stdint.h>, which 
is not included explicitly. On Linux, it is included implicitly by 
<netinet/in.h>, but not so on Mac OS X. This is easily fixed in 
syshead.h.

2. Apple's precompiling version of cpp doesn't know about macros with 
variable arguments. Passing the "--no-cpp-precomp" command line 
option gets rid of this. I added a small check to configure to add it 
automatically.

3. There is no socklen_t. Coming up with a quick workaround was easy, 
but fixing it properly wasn't. I found a quite complete configure 
test for this in OpenSSH, it actually originated from curl. 
Unfortunately it only works with autoconf 2.50 or newer.

The attached patch is against the current CVS version (which 
identifies itself as 1.1.1.6). It compiles and runs fine on my Mac OS 
X box, although I haven't tested the new features yet.

Please let me know what you think.

Greetings,
chrisp

-- 
chrisp a.k.a. Christoph Pfisterer   "Any sufficiently advanced
cp...@ch... - http://chrisp.de      bug is indistinguishable
PGP key & geek code available        from a feature."

[Openvpn-devel] autovpn 0.1

[Jean-Eric C. <jea...@li...>]

Hi,
I made a package to us openvpn in a defined configuration, we want to do
the same as securemote from CheckPoint since there is no securemote for
Linux
Need to make it working:
- A Linux machine with access to the entire netowk (the gateway in fact.
  - It must have openvpn-1.1.1 + autovpn installed
- An SSH access on this machine for each user that  want remote access
to the network.
- autovpn installed on the client too.

Autovpn is written in Perl. It's made of 6-7 simple scripts.

To install:
On the client and the server:
  - untar autovpn.tar in /usr/local (not configuarble at the moment)
  - check that autovpn-server.pl is setuid root (has rws for user and
that user is root)

Then on the client (as root), issue: /usr/local/autovpn.pl
It should ask for your password on the gateway.
Then the terminal is blocked until you type ENTER to close the VPN.
That's all!

It's 0.1 version, so there is probably some problems.
The config file is in ~/.autovpn It's a simple text file.

The needed Perl modules are (on the client only):
- Config::IniFiles
- Data::Dumper

Good luck!
-jec


-- 
Jean-Eric Cuendet
Linkvest SA
Av des Baumettes 19, 1020 Renens Switzerland
Tel +41 21 632 9043  Fax +41 21 632 9090
E-mail: jea...@li...
http://www.linkvest.com
--------------------------------------------------------

[Openvpn-devel] OpenVPN 1.2.0 Beta available, Please Test

[James Y. <ji...@nt...>]

Release Notes:

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

Download:

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

This release also has a "beta" version of the web site to go along with it:

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

As you will notice, this release has been ported to Solaris, while ports to
OpenBSD and FreeBSD are ongoing.  If you use OpenBSD or FreeBSD and would
like to test OpenVPN on your platform, please email me.

This release of OpenVPN is protocol compatible with 1.1.1.

Enjoy,

James

[Openvpn-devel] Re: OpenVPN and OpenSSL 0.9.7 was: Re: Integration of AES algorith to OpenSSL Crypto library

[Ildar G. <il...@nn...>]

James,
For the moment I will be using the patch but will move to official 0.9.7 as
soon as it is ready.

Thank you very much.

Ildar.

----- Original Message -----
From: "James Yonan" <ji...@nt...>
To: "Ildar Gabdulline" <il...@nn...>
Cc: <ope...@li...>
Sent: Friday, May 03, 2002 10:10 PM
Subject: Re: OpenVPN and OpenSSL 0.9.7 was: Re: Integration of AES algorith
to OpenSSL Crypto library


> > I'll be glad to receive such patch because I need to integrate AES
> algorithm
> > to openvpn
> > (my boss requested this).
>
> If you can wait a few days, I would recommend waiting for the official
0.9.7
> openssl beta which will probably solve the problem.  If you can't wait,
> here's a patch:
>
> http://openvpn.sourceforge.net/patch/openssl097.patch
>
> Remember, 0.9.7 is pre-beta at this point so you're on your own.  I have
not
> extensively tested this patch other than a brief test to confirm that it
> fixed the EVP incompatibility.
>
> James
>
>
>
>
>
>

[Openvpn-devel] Re: OpenVPN and OpenSSL 0.9.7 was: Re: Integration of AES algorith to OpenSSL Crypto library

[James Y. <ji...@nt...>]

> I'll be glad to receive such patch because I need to integrate AES
algorithm
> to openvpn
> (my boss requested this).

If you can wait a few days, I would recommend waiting for the official 0.9.7
openssl beta which will probably solve the problem.  If you can't wait,
here's a patch:

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

Remember, 0.9.7 is pre-beta at this point so you're on your own.  I have not
extensively tested this patch other than a brief test to confirm that it
fixed the EVP incompatibility.

James

[Openvpn-devel] openvpn and openssl 0.9.7+

[Ildar G. <il...@nn...>]

Hi,

Is anybody here who uses openvpn with openssl version 0.9.7 (latest =
snapshots)
with AES encryption algorithm ?
The problem is that I've tried to compile openvpn with snapshot from 1st =
May and it crashed.

Thanks,

Ildar.

[Openvpn-devel] OpenVPN 1.1.1 Released

[James Y. <ji...@nt...>]

Download:

http://prdownloads.sourceforge.net/openvpn/openvpn-1.1.1.tar.gz

Release Notes:

OpenVPN 1.1.1 is mostly a bugfix release, but also adds some new options for
keeping connections through stateful firewalls alive and specifying an
inactivity disconnect for dynamic VPN sessions.  The new --ifconfig option
calls ifconfig to configure the tunnel automatically, eliminating the need
for an --up script.  Also added a loopback test mode (--test-crypto) to
allow testing of OpenVPN's crypto component independently of its network
component.  1.1.1 is protocol compatible with 1.1.0.

Change Log:

2002.04.22 -- Version 1.1.1

* Added --ifconfig option to automatically configure
  TUN device.
* Added inactivity disconnect (--inactive
  and --ping-exit options).
* Added --ping option to keep stateful firewalls
  from timing out.
* Added sanity check to command line parser to
  err if any TLS options are used in non-TLS mode.
* Fixed build problem with compiler environments that
  define printf as a macro.
* Fixed build problem on linux systems that have
  an integrated TUN/TAP driver but lack the persistent
  tunnel feature (TUNSETPERSIST).  Some linux kernels
  >= 2.4.0 and < 2.4.7 fall into this category.
* Changed all calls to EVP_CipherInit to use explicit
  encrypt/decrypt mode in order to fix problem with
  IDEA-CBC and AES-256-CBC ciphers.
* Minor changes to control channel transmit limiter
  algorithm to fix problem where TLS control channel
  might not renegotiate within the default 60 second window.
* Simplified man page examples by taking advantage
  of the new --ifconfig option.
* Minor changes to configure.in to check more
  rigourously for OpenSSL 0.9.6 or greater.
* Put back openvpn.spec, eliminated
  openvpn.spec.in.
* Modified openvpn.spec to reflect new automake-based
  build environment (Bishop Clark).
* Other documentation changes.
* Added --test-crypto option for debugging.
* Added "missing" and "mkinstalldirs" automake
  support files.

James

[Openvpn-devel] OpenVPN 1.1.1 Release Candidate #1 -- Please Test

[James Y. <ji...@nt...>]

An OpenVPN 1.1.1 release candidate is ready -- please test and report any
problems to the list.

OpenVPN 1.1.1 is mostly a bugfix release, but also adds some new options for
keeping stateful firewalls alive and specifying an inactivity disconnect for
dynamic VPN sessions.  The new --ifconfig option calls ifconfig
automatically, eliminating the need for an --up script.  Also added a
loopback test mode (--test-crypto) to allow testing of OpenVPN's crypto
component independently of its network component.  1.1.1 is protocol
compatible with 1.1.0.

Download release candidate:

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

Change Log:

* Added --ifconfig option to automatically configure
  TUN device.
* Added inactivity disconnect (--inactive
  and --ping-exit options).
* Added --ping option to keep stateful firewalls
  from timing out.
* Added sanity check to command line parser to
  err if any TLS options are used in non-TLS mode.
* Fixed build problem with compiler environments that
  define printf as a macro.
* Fixed build problem on linux systems that have
  an integrated TUN/TAP driver but lack the persistent
  tunnel feature (TUNSETPERSIST).  Some linux kernels
  >= 2.4.0 and < 2.4.7 fall into this category.
* Changed all calls to EVP_CipherInit to use explicit
  encrypt/decrypt mode in order to fix problem with
  IDEA-CBC and AES-256-CBC ciphers.
* Minor changes to control channel transmit limiter
  algorithm to fix problem where TLS control channel
  might not renegotiate within the default 60 second window.
* Simplified man page examples by taking advantage
  of the new --ifconfig option.
* Minor changes to configure.in to check more
  rigorously for OpenSSL 0.9.6 or greater.
* Put back openvpn.spec, eliminated
  openvpn.spec.in.
* Modified openvpn.spec to reflect new automake-based
  build environment (Bishop Clark).
* Other documentation changes.
* Added --test-crypto option for debugging.
* Added "missing" and "mkinstalldirs" automake
  support files.

James

[Openvpn-devel] --inactive flag

[Jean-Eric C. <jea...@li...>]

Hi,
I tried 1.1.0.5 with --inactive flag.
It's working great and it's cool.
I'll post the scripts I made to automatically open a VPN between a 
client and a server that can communicate through SSH as soon as I've 
more time to polish them
Thanks for your job. openvpn is great!
-jec

RE: [Openvpn-devel] Multi-user openvpn

[Jean-Eric C. <Jea...@li...>]

>One other thing that would be cool, would be a flag to let openvpn
accept a connection within a certain amount of time and shutdown after
that.

The inactivity disconnect should handle that case.

If you start an openvpn session with --inactive 300, and the peer never
connects, the session will exit in 5 minutes.

Yes, that would work.
But the typical usage would be:
- Shutdown after 30 seconds if no connection
- Shutdown after 60-120 minutes if no network activity (after connection
was successful)

But inact timeout would be sufficient for our basic needs.
-jec

Re: [Openvpn-devel] Multi-user openvpn

[James Y. <ji...@nt...>]

Jean-Eric,

> Hi,
> We found openvpn last week and tried it for our needs.
> We have a mix of Windows+Linux clients, some of which wants to connect
> to the main site through VPN.
> The windows users use CheckPoint securemote and we want that Linux users
> use openvpn.
> We made some tests and want to congratulate you fr your great job. It's
> working well and is simple!

Thanks!

> Now, our questions.
> We want to be able to let multiple users that have an SSH connection on
> one VPN server, opens a VPN with openvpn. It must have dynamic
> addresses, should be opened as users, not root, should not run if there
> is no more traffic.
> We want to make a server script that:
> - create a tun device as a user
> - assign the client an address
> - create a symmetric key for openvpn
>
> We are able to:
> - opening a tun device as a simple user
> - run openvpn as a user
> - Providing dynamic address is not simple, but possible with the script.
>
> What lacks is the ability to let openvpn stop automatically when there
> is no traffic after a lap of time

We're thinking of adding this feature in the future -- an inactivity
disconnect.  A related feature that's also on the To Do list is a "ping"
that sends packets at least every n seconds to keep stateful firewall rules
alive.

These features are not difficult to add, given the current structure of
openvpn -- a main event loop in openvpn.c blocks on a select call with an
optional timeout.

> Another problem is that for 1 client to open a VPN, 2 addresses are
> needed, one for client and one for the server tun device.
> Does TAP device resolve this? Is it possible to use only 1 address for 1
> client with TAP device? And is it possible to use TAP device with openvpn?

Yes, openvpn supports tap devices.  And you are correct that tap devices
only require a local endpoint.  For example:

./openvpn --dev tap --up ./mktap ...

[root@boulder openvpn]# cat mktap
#!/bin/bash
ifconfig $1 10.5.0.1 netmask 255.255.255.0 mtu $2

This will set up a tap dev with endpoint 10.5.0.1.  On the other peer just
use 10.5.0.2 or something else in the subnet.

One caveat of this approach is that it uses ARP broadcasts over the ethernet
tunnel to resolve addresses.  Not only is this more inefficient, but these
periodic broadcasts may defeat any kind of inactivity timeout you devise.

> Thanks.
> -jec
>
> PS: Would you be interested in our script in the openvpn distribution?

Certainly... We plan to set up a contributions directory.

When you are finished, just post your script as an attachment to one of our
mailing lists.  Try to document it as much as possible, including a short
abstract of what it does.

Thanks,
James

[Openvpn-devel] Multi-user openvpn

[Jean-Eric C. <jea...@li...>]

Hi,
We found openvpn last week and tried it for our needs.
We have a mix of Windows+Linux clients, some of which wants to connect 
to the main site through VPN.
The windows users use CheckPoint securemote and we want that Linux users 
use openvpn.
We made some tests and want to congratulate you fr your great job. It's 
working well and is simple!

Now, our questions.
We want to be able to let multiple users that have an SSH connection on 
one VPN server, opens a VPN with openvpn. It must have dynamic 
addresses, should be opened as users, not root, should not run if there 
is no more traffic.
We want to make a server script that:
- create a tun device as a user
- assign the client an address
- create a symmetric key for openvpn

We are able to:
- opening a tun device as a simple user
- run openvpn as a user
- Providing dynamic address is not simple, but possible with the script.

What lacks is the ability to let openvpn stop automatically when there 
is no traffic after a lap of time
Another problem is that for 1 client to open a VPN, 2 addresses are 
needed, one for client and one for the server tun device.
Does TAP device resolve this? Is it possible to use only 1 address for 1 
client with TAP device? And is it possible to use TAP device with openvpn?

Thanks.
-jec

PS: Would you be interested in our script in the openvpn distribution?

-- 
Jean-Eric Cuendet
Linkvest SA
Av des Baumettes 19, 1020 Renens Switzerland
Tel +41 21 632 9043  Fax +41 21 632 9090
E-mail: jea...@li...
http://www.linkvest.com
--------------------------------------------------------

[Openvpn-devel] OpenVPN 1.1.0 released

[James Y. <ji...@nt...>]

Download:

http://prdownloads.sourceforge.net/openvpn/openvpn-1.1.0.tar.gz

Change Log:

2002.04.09 -- Version 1.1.0

* Strengthened replay protection and IV handling,
  extending it fully to both static key and
  TLS dynamic key exchange modes.
* Added --mlock option to disable paging and ensure that key
  material and tunnel data is never paged to disk.
* Added optional traffic shaping feature to cap the maximum
  data rate of the tunnel.
* Converted to automake (The Platypus Brothers 2002-04-01).
* Ported to OpenBSD by Janne Johansson.
* Added --tun-af-inet option to work around an incompatibility
  between Linux and BSD tun drivers.
* Sequence number-based replay protection using the
  IPSec sliding window model is now the default,
  disable with --no-replay.
* Explicit IV is now the default, disable with --no-iv.
* Disabled all cipher modes except CBC, CFB, and OFB.
* In CBC mode, use explicit IV and carry forward residuals,
  using IPSec model.
* In CFB/OFB mode, IV is timestamp, sequence number.
* Eliminated --packet-id, --timestamp, and max-delta parameter to
  the --tls-auth option as they are now supplanted by improved
  replay code which is enabled by default.
* Eliminated --rand-iv as it is now obsolete with improved
  IV code.
* Eliminated --reneg-err option as it increases vulnerability
  to DoS attacks.
* Added weak key check for DES ciphers.
* --tls-freq option is no longer specified on the command line,
  instead it now inherits its parameter from the
  --tls-timeout option.
* Fixed bug that would try to free memory on exit that was
  never malloced if --comp-lzo was not specified.
* Errata fixed in the man page examples: "test-ca" should be
  "tmp-ca".
* Updated manual page.
* Preliminary work in porting to OpenSSL 0.9.7.
* Changed license to allowing linking with OpenSSL.

[Openvpn-devel] OpenVPN 1.1-pre2 available

[James Y. <ji...@nt...>]

Another beta is available, please test.

1.1 final should be forthcoming in a couple days if I don't hear of any
problems.

pre1 -> pre2 changes:

* New option --shaper that does traffic shaping (i.e. bandwidth limiting).
This option could be used for example to build two tunnels between the same
peers, one running at full speed, and the other at reduced bandwidth for
batch-type transfers such as off-site-backups.  See the man page for more
info.

* Fixed "make install" to also install the man page.

* OpenBSD and --tun-af-inet fixes.

* Other minor fixes.

* CVS updated.

* Manual page updated.

http://openvpn.sourceforge.net/beta/openvpn-1.1-pre2.tar.gz

James

[Openvpn-devel] OpenVPN 1.1 beta available

[James Y. <ji...@nt...>]

Here's the latest beta...  Contains a lot of cool stuff including automake
configuration, a BSD 3.0 port, fixes for CFB/OFB IV, reworked replay
protection and IV based on IPSec,  --mlock (to disable paging), special
handling for all DES keys wrt. parity and weak keys, and an updated manual
page.

The only known issue right now is that for some reason (on my machine) "make
install" only installs the binary, not the man page.  I'm an automake newbie
and haven't really tried to figure it out yet.

Anyway, build it, test it, beat on it, etc.

http://openvpn.sourceforge.net/beta/openvpn-1.1-pre1.tar.gz

James

************************************

ChangeLog

2002.04.07 -- Version 1.1-pre1

* Strengthened replay protection and IV handling,
  extending it fully to both static key and
  TLS dynamic key exchange modes.
* Added --mlock option to disable paging and ensure that key
  material and tunnel data is never paged to disk.
* Converted to automake by The Platypus Brothers 2002-04-01.
* Ported to OpenBSD by Janne Johansson.
* Added --tun-af-inet option to work around an incompatibility
  between Linux and BSD tun drivers.
* Sequence number-based replay protection using the
  IPSec sliding window model is now the default,
  disable with --no-replay.
* Explicit IV is now the default, disable with --no-iv.
* Disabled all cipher modes except CBC, CFB, and OFB.
* In CBC mode, use explicit IV and carry forward residuals,
  using IPSec model.
* In CFB/OFB mode, IV is timestamp, sequence number.
* Eliminated --packet-id, --timestamp, and max-delta parameter to
  the --tls-auth option as they are now supplanted by improved
  replay code which is enabled by default.
* Eliminated --rand-iv as it is now obsolete with improved
  IV code.
* Eliminated --reneg-err option as it increases vulnerability
  to DoS attacks.
* Added weak key check for DES ciphers.
* --tls-freq option is no longer specified on the command line,
  instead it now inherits its parameter from the
  --tls-timeout option.
* Errata fixed in the man page examples: "test-ca" should be
  "tmp-ca".
* Other manual page changes.
* Preliminary work in porting to OpenSSL 0.9.7.

Re: [Openvpn-devel] Now it works far better on/against BSD.

[James Y. <ji...@nt...>]

Janne,

On BSD, is there any way to ioctl away the leading AF_INET, or is it
necessary to have the linux side conform to the BSD side with --remote-bsd?

>It compiles cleanly on Linux2.4 and with 2 warnings on OpenBSD3.0.
==============================================
gcc -g -O2  -I/usr/local/include  -c openvpn.c
openvpn.c: In function `openvpn':
openvpn.c:777: warning: passing arg 5 of `tls_multi_process' from
incompatible pointer type
openvpn.c:780: warning: passing arg 3 of `interval_set_timeout' from
incompatible pointer type
=========================
Weird.

What's the type of the tv_sec member of struct timeval on BSD?  On linux
it's time_t.  It's probably something else on BSD, hence the warning.

Jim

[Openvpn-devel] Now it works far better on/against BSD.

[Janne J. <jan...@bi...>]

Ok, this is tested in cleartext tunnel mode, and ssl-with-preshared-key.

Both methods work if the Linux side has "--remote-bsd" on the command
line, and they do not work without it.
(Given that the remote IS bsd of course =3D)
Both machines were little-endian, I haven't tested BE machines yet.
(I have a BSD sparc that I can test with later)

I haven't tested lzo yet, nor certificate-based encryption, but I don't
think they will cause more problems now that SSL works.

It compiles cleanly on Linux2.4 and with 2 warnings on OpenBSD3.0.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
gcc -g -O2  -I/usr/local/include  -c openvpn.c
openvpn.c: In function `openvpn':
openvpn.c:777: warning: passing arg 5 of `tls_multi_process' from
incompatible pointer type
openvpn.c:780: warning: passing arg 3 of `interval_set_timeout' from
incompatible pointer type
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Weird.

Also, I'm not sure if the frame-extension stuff
(+sizeof(u_int32_t)  bytes if remote is bsd)
is 100% correct for all cases but at least pings work. =3D)
Please look over that part.

The line I used on Linux was: (got 10.0.0.2 for its address)
prompt> ./openvpn --local 1.2.3.4 --remote 2.3.4.5 --dev tun
--remote-bsd&
prompt> ifconfig tun0 10.0.0.2 pointopoint 10.0.0.1 mtu 1450 up

On BSD: (Which got 10.0.0.1 as the local tun-ip-address)
prompt> ./openvpn --local 2.3.4.5 --remote 1.2.3.4 --dev tun0 &
prompt> ifconfig tun0 10.0.0.1 10.0.0.2 mtu 1450 up
...
prompt> ifconfig tun0 delete

On BSD, the tun device is always refered to by number (tun0)
and it will not be brought down on openvpn exits like on Linux.
Apart from that, it's quite straightforward.

It should be easy(er) to make a Net/FreeBSD/Solaris port
now if anyone wants.

This patch is against a clean 1.0.3 and incorporates the
NULL-fix, and the de/encrypt() -> openvpn_de/encrypt() rename.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dcut here=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
diff -ru openvpn-1.0.3/basic.h obsd-openvpn-1.0.3/basic.h
--- openvpn-1.0.3/basic.h	Sat Mar 23 16:56:41 2002
+++ obsd-openvpn-1.0.3/basic.h	Tue Apr  2 11:50:27 2002
@@ -37,6 +37,8 @@
 /* clear an object */
 #define CLEAR(x) memset(&(x), 0, sizeof(x))
=20
+#ifndef NULL
 #define NULL ((void *)0)
+#endif /* NULL */
=20
 #endif
diff -ru openvpn-1.0.3/crypto.c obsd-openvpn-1.0.3/crypto.c
--- openvpn-1.0.3/crypto.c	Thu Mar 28 07:50:45 2002
+++ obsd-openvpn-1.0.3/crypto.c	Tue Apr  2 12:59:00 2002
@@ -79,7 +79,7 @@
   do { msg (D_CRYPT_ERRORS, "%s: " format, error_prefix, args); goto error=
_exit; } while (false)
=20
 void
-encrypt (struct buffer *buf, struct buffer work,
+openvpn_encrypt (struct buffer *buf, struct buffer work,
 	 const struct crypto_options *opt,
 	 const struct frame* frame,
 	 const time_t current)
@@ -186,7 +186,7 @@
 }
=20
 void
-decrypt (struct buffer *buf, struct buffer work,
+openvpn_decrypt (struct buffer *buf, struct buffer work,
 	 const struct crypto_options *opt,
 	 const struct frame* frame,
 	 const time_t current)
diff -ru openvpn-1.0.3/crypto.h obsd-openvpn-1.0.3/crypto.h
--- openvpn-1.0.3/crypto.h	Sun Mar 24 04:18:02 2002
+++ obsd-openvpn-1.0.3/crypto.h	Tue Apr  2 12:59:15 2002
@@ -97,12 +97,12 @@
 void init_key_ctx (struct key_ctx *key_ctx, struct key *key,
 		   const struct key_type *kt, const char *prefix);
=20
-void encrypt (struct buffer *buf, struct buffer work,
+void openvpn_encrypt (struct buffer *buf, struct buffer work,
 	      const struct crypto_options *opt,
 	      const struct frame* frame,
 	      const time_t current);
=20
-void decrypt (struct buffer *buf, struct buffer work,
+void openvpn_decrypt (struct buffer *buf, struct buffer work,
 	      const struct crypto_options *opt,
 	      const struct frame* frame,
 	      const time_t current);
diff -ru openvpn-1.0.3/openvpn.c obsd-openvpn-1.0.3/openvpn.c
--- openvpn-1.0.3/openvpn.c	Fri Mar 29 01:43:12 2002
+++ obsd-openvpn-1.0.3/openvpn.c	Thu Apr  4 14:45:09 2002
@@ -30,6 +30,7 @@
 #include <unistd.h>
 #include <signal.h>
 #include <stdio.h>
+#include <sys/socket.h>
=20
 #include "openvpn.h"
 #include "common.h"
@@ -91,6 +92,8 @@
   "                : 8 -- show all debug info\n"
   "--gremlin       : Simulate dropped & corrupted packets + network outage=
s\n"
   "                  to test robustness of protocol (for debugging only).\=
n"
+  "--remote-bsd    : If the remote system is using BSD tun devices that ad=
d\n"
+  "                  protocol info on each packet sent.\n"
 #ifdef USE_LZO
   "--comp-lzo      : Use fast LZO compression -- may add up to 1 byte per\=
n"
   "                  packet for uncompressible data.\n"
@@ -210,6 +213,7 @@
   o->verbosity =3D 1;
   o->bind_local =3D true;
   o->tun_mtu =3D DEFAULT_TUN_MTU;
+  o->remotebsd =3D false;
 #ifdef USE_LZO
   o->comp_lzo_adaptive =3D true;
 #endif
@@ -262,6 +266,7 @@
   SHOW_INT (nice);
   SHOW_INT (verbosity);
   SHOW_BOOL (gremlin);
+  SHOW_BOOL (remotebsd);
=20
 #ifdef USE_LZO
   SHOW_BOOL (comp_lzo);
@@ -426,6 +431,17 @@
=20
 static void frame_finalize(struct frame *frame, const struct options *opti=
ons)
 {
+  if (options->remotebsd)
+    {
+      frame->extra_frame +=3D 4;
+    }
+#ifdef __OpenBSD__
+  else
+    {
+      frame->extra_frame +=3D 4;
+    }
+#endif /* OBSD */
+
   if (options->tun_mtu_defined)
     {
       frame->mtu =3D options->tun_mtu;
@@ -836,6 +852,11 @@
 		   print_sockaddr (&from), PROTO_DUMP (&buf));
 	      if (buf.len > 0)
 		{
+
+#ifdef __OpenBSD__
+		  buf_advance(&buf, sizeof(u_int32_t));
+#endif /* OBSD */
+
 		  udp_socket_incoming_addr (&buf, &udp_socket, &from);
 #ifdef USE_CRYPTO
 #ifdef USE_SSL
@@ -845,7 +866,7 @@
 			interval_trigger(&tmp_int, current);
 		    }
 #endif
-		  decrypt (&buf, decrypt_buf, &crypto_options, &frame, current);
+		  openvpn_decrypt (&buf, decrypt_buf, &crypto_options, &frame, current);
 #endif
 #ifdef USE_LZO
 		  if (options->comp_lzo)
@@ -872,6 +893,10 @@
 	      check_status (buf.len, "read from tun");
 	      if (buf.len > 0)
 		{
+#ifdef __OpenBSD__
+		      buf_advance(&buf, sizeof(u_int32_t));
+#endif /* OBSD */
+
 #ifdef USE_LZO
 		  if (options->comp_lzo)
 		    lzo_compress (&buf, lzo_compress_buf, &lzo_compwork, &frame, current=
);
@@ -882,7 +907,7 @@
 		    tls_pre_encrypt (tls_multi, &buf, &crypto_options);
 #endif
=20
-		  encrypt (&buf, encrypt_buf, &crypto_options, &frame, current);
+		  openvpn_encrypt (&buf, encrypt_buf, &crypto_options, &frame, current);
 #endif
 		  udp_socket_get_outgoing_addr (&buf, &udp_socket,
 						&to_udp_addr);
@@ -905,6 +930,10 @@
 	  if (FD_ISSET (td, &writes))
 	    {
 	      int size;
+#ifdef __OpenBSD__
+	      u_int32_t af =3D htonl(AF_INET);
+	      buf_write_prepend(&to_tun, &af ,sizeof (u_int32_t));
+#endif /* OBSD */	     =20
 	      ASSERT (to_tun.len > 0 && to_tun.len <=3D MAX_RW_SIZE_TUN(&frame));
 	      size =3D write (td, BPTR (&to_tun), BLEN (&to_tun));
 	      check_status (size, "write to tun");
@@ -917,6 +946,12 @@
 	      socklen_t tolen =3D sizeof (to_udp_addr);
 	      int size;
=20
+	      if (options->remotebsd)
+		{
+		  u_int32_t af =3D htonl(AF_INET);
+		  buf_write_prepend(&to_udp, &af ,sizeof (u_int32_t));
+		}
+
 	      ASSERT (to_udp.len > 0 && to_udp.len <=3D max_rw_size_udp);
 	      ASSERT (ADDR (to_udp_addr));
 	      if (!options->gremlin || ask_gremlin())
@@ -1154,6 +1189,10 @@
       else if (streq (p1, "--nobind"))
 	{
 	  options.bind_local =3D false;
+	}
+      else if (streq (p1, "--remote-bsd"))
+	{
+	  options.remotebsd =3D true;
 	}
 #ifdef USE_LZO
       else if (streq (p1, "--comp-lzo"))
diff -ru openvpn-1.0.3/openvpn.h obsd-openvpn-1.0.3/openvpn.h
--- openvpn-1.0.3/openvpn.h	Sat Mar 30 03:24:00 2002
+++ obsd-openvpn-1.0.3/openvpn.h	Thu Apr  4 13:17:09 2002
@@ -53,6 +53,7 @@
   int nice;
   int verbosity;
   bool gremlin;
+  bool remotebsd;
=20
 #ifdef USE_LZO
   bool comp_lzo;
Only in obsd-openvpn-1.0.3: out
diff -ru openvpn-1.0.3/socket.c obsd-openvpn-1.0.3/socket.c
--- openvpn-1.0.3/socket.c	Fri Mar 29 01:20:16 2002
+++ obsd-openvpn-1.0.3/socket.c	Thu Apr  4 15:45:19 2002
@@ -27,7 +27,13 @@
=20
 #include <netdb.h>		/* gethostbyname */
 #include <netinet/in.h>		/* struct sockaddr_in */
-#include <linux/if.h>		/* inet stuff */
+
+#ifdef __OpenBSD__
+#include <net/if_tun.h>		/* inet stuff */
+#else
+#include <linux/if_tun.h>
+#endif /* OBSD */
+
 #include <stdlib.h>		/* system() */
=20
 #include "socket.h"
diff -ru openvpn-1.0.3/socket.h obsd-openvpn-1.0.3/socket.h
--- openvpn-1.0.3/socket.h	Thu Mar 28 20:13:14 2002
+++ obsd-openvpn-1.0.3/socket.h	Thu Apr  4 16:00:56 2002
@@ -26,7 +26,10 @@
 #ifndef SOCKET_H
 #define SOCKET_H
=20
+#include <netinet/in.h>
+#include <sys/socket.h>
 #include <arpa/inet.h>
+
 #include "buffer.h"
 #include "common.h"
=20
diff -ru openvpn-1.0.3/ssl.c obsd-openvpn-1.0.3/ssl.c
--- openvpn-1.0.3/ssl.c	Fri Mar 29 01:43:10 2002
+++ obsd-openvpn-1.0.3/ssl.c	Tue Apr  2 13:03:08 2002
@@ -943,7 +943,7 @@
   *header =3D ks->key_id | (opcode << P_OPCODE_SHIFT);
   if (session->tls_auth.key_ctx_bi->encrypt.hmac_defined)
     {
-      encrypt (buf, null, &session->tls_auth, NULL, current); /* no encryp=
tion, only write hmac */
+      openvpn_encrypt (buf, null, &session->tls_auth, NULL, current); /* n=
o encryption, only write hmac */
       ASSERT (swap_hmac (buf, &session->tls_auth, false));
     }
   *to_udp_addr =3D ks->remote_addr;
@@ -970,7 +970,7 @@
=20
       /* authenticate only (no decrypt) and remove the hmac record
          from the head of the buffer */
-      decrypt (buf, null, co, NULL, current);
+      openvpn_decrypt (buf, null, co, NULL, current);
       if (!buf->len)
 	{
 	  msg (D_TLS_ERRORS,
diff -ru openvpn-1.0.3/ssl.h obsd-openvpn-1.0.3/ssl.h
--- openvpn-1.0.3/ssl.h	Thu Mar 28 10:16:53 2002
+++ obsd-openvpn-1.0.3/ssl.h	Tue Apr  2 13:04:00 2002
@@ -28,6 +28,7 @@
 #include <openssl/ssl.h>
 #include <openssl/bio.h>
 #include <openssl/rand.h>
+#include <netinet/in.h>
 #include "basic.h"
 #include "crypto.h"
 #include "packet_id.h"
diff -ru openvpn-1.0.3/tun.c obsd-openvpn-1.0.3/tun.c
--- openvpn-1.0.3/tun.c	Sat Mar 23 16:56:41 2002
+++ obsd-openvpn-1.0.3/tun.c	Thu Apr  4 15:19:30 2002
@@ -25,12 +25,12 @@
=20
 #include "config.h"
=20
-#include <sys/socket.h>
 #include <sys/ioctl.h>
-#include <linux/if.h>
 #include <fcntl.h>
=20
 #ifndef OLD_TUN_TAP
+#include <sys/socket.h>
+#include <linux/if.h>
 #include <linux/if_tun.h>
 #endif /* OLD_TUN_TAP */
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3Dcut here=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--=20
Janne Johansson
jan...@bi...
BioMat Systems AB
Klarabergsg 37 3tr
111 21 Stockholm

Re: [Openvpn-devel] More BSD TUN info.

[James Y. <ji...@nt...>]

>I think the solution would be to have openvpn disable TUN_NO_IP for
Linux tun devices and just not care about the actual value when
the packets arrive.

So if the linux side disables TUN_NO_PI, does the problem go away when
connecting to BSD?

James

Re: [Openvpn-devel] More BSD TUN info.

[Janne J. <jan...@bi...>]

> >Yes, but since BSD wont let you choose if you want it or not, and the
> chance of changing Linux-TUN-drivers now is slim, I guess it has to be
> the application that takes care of this. I'll try to make a patch and
> test it, and send you the diff later.
>=20
> Some thoughts:
>=20
> * probably the best place to add/remove the AF_INET is by calling some
> routine in the main event loop in openvpn.c, conditional on --remote-is-b=
sd.
>=20
> * add and remove u_int_32 by manipulating struct buffer (see buf_prepend =
and
> buf_advance in particular).
>=20
> * remember that when you add a new buffer prepend item, you must modify t=
he
> appropriate struct frame which will contain the MTU parms, so that
> everything gets sized right.  For an example, see
> crypto_adjust_frame_parameters().

I have made an attempt but I must warn you, I'm no guru on pointers
and stuff, so I'd like you to check my calls to see that I'm on the
right track please:
I will test this asap and tell you if it works.

diff -ru openvpn-1.0.3/openvpn.c new_openvpn-1.0.3/openvpn.c
--- openvpn-1.0.3/openvpn.c	Fri Mar 29 01:43:12 2002
+++ new_openvpn-1.0.3/openvpn.c	Thu Apr  4 12:09:32 2002
@@ -91,6 +91,8 @@
   "                : 8 -- show all debug info\n"
   "--gremlin       : Simulate dropped & corrupted packets + network outage=
s\n"
   "                  to test robustness of protocol (for debugging only).\=
n"
+  "--remote-bsd    : If the remote system is using BSD tun devices that ad=
d\n"
+  "                  protocol info on each packet sent.\n"
 #ifdef USE_LZO
   "--comp-lzo      : Use fast LZO compression -- may add up to 1 byte per\=
n"
   "                  packet for uncompressible data.\n"
@@ -210,6 +212,7 @@
   o->verbosity =3D 1;
   o->bind_local =3D true;
   o->tun_mtu =3D DEFAULT_TUN_MTU;
+  o->remotebsd =3D false;
 #ifdef USE_LZO
   o->comp_lzo_adaptive =3D true;
 #endif
@@ -262,6 +265,7 @@
   SHOW_INT (nice);
   SHOW_INT (verbosity);
   SHOW_BOOL (gremlin);
+  SHOW_BOOL (remotebsd);
=20
 #ifdef USE_LZO
   SHOW_BOOL (comp_lzo);
@@ -426,6 +430,11 @@
=20
 static void frame_finalize(struct frame *frame, const struct options *opti=
ons)
 {
+  if (options->remotebsd)
+    {
+      frame->extra_frame +=3D 4;
+    }
+
   if (options->tun_mtu_defined)
     {
       frame->mtu =3D options->tun_mtu;
@@ -872,6 +881,11 @@
 	      check_status (buf.len, "read from tun");
 	      if (buf.len > 0)
 		{
+		  if (options->remotebsd)
+		    {
+		      buf_advance(&buf, sizeof(u_int32_t));
+		    }
+
 #ifdef USE_LZO
 		  if (options->comp_lzo)
 		    lzo_compress (&buf, lzo_compress_buf, &lzo_compwork, &frame, current=
);
@@ -905,6 +919,13 @@
 	  if (FD_ISSET (td, &writes))
 	    {
 	      int size;
+
+	      if (options->remotebsd)
+		{
+		  u_int32_t af =3D htonl(AF_INET);
+		  buf_write_prepend(&to_tun, &af ,sizeof (u_int32_t));
+		}
+
 	      ASSERT (to_tun.len > 0 && to_tun.len <=3D MAX_RW_SIZE_TUN(&frame));
 	      size =3D write (td, BPTR (&to_tun), BLEN (&to_tun));
 	      check_status (size, "write to tun");
@@ -1155,6 +1176,10 @@
 	{
 	  options.bind_local =3D false;
 	}
+      else if (streq (p1, "--remote-bsd"))
+	{
+	  options.remotebsd =3D true;
+	}
 #ifdef USE_LZO
       else if (streq (p1, "--comp-lzo"))
 	{
diff -ru openvpn-1.0.3/openvpn.h new_openvpn-1.0.3/openvpn.h
--- openvpn-1.0.3/openvpn.h	Sat Mar 30 03:24:00 2002
+++ new_openvpn-1.0.3/openvpn.h	Thu Apr  4 11:16:46 2002
@@ -53,6 +53,7 @@
   int nice;
   int verbosity;
   bool gremlin;
+  bool remotebsd;
=20
 #ifdef USE_LZO
   bool comp_lzo;

--=20
Janne Johansson
jan...@bi...
BioMat Systems AB
Klarabergsg 37 3tr
111 21 Stockholm

Re: [Openvpn-devel] More BSD TUN info.

[James Y. <ji...@nt...>]

On Thu, 2002-04-04 at 10:46, James Yonan wrote:
> >I don't know the openvpn data format, but if 45000054 is some sort of
> openvtun identifier, you/we/I could add some code that checked for
> 00000002 followed by 45000054 and then strip the first u_int_32 from
> the packet and go on. Perhaps a --remote-is-bsd or something similar?
>
> Openvpn doesn't look at the tunnel data... it just encrypts, decrypts,
> forwards etc.  The 45000054 is the beginning of the IP header of the
packets
> going over the tunnel.

Dang. =)
(Sorry for mistyping it as openvtun)
Still, it's just as well, since that data would look different when
encrypted anyway.

> Yeah, an option might be right thing.  So --remote-is-bsd would remove the
> AF_INET from incoming packets and add them to outgoing packets.  A bit of
a
> kludge.

>Yes, but since BSD wont let you choose if you want it or not, and the
chance of changing Linux-TUN-drivers now is slim, I guess it has to be
the application that takes care of this. I'll try to make a patch and
test it, and send you the diff later.

Some thoughts:

* probably the best place to add/remove the AF_INET is by calling some
routine in the main event loop in openvpn.c, conditional on --remote-is-bsd.

* add and remove u_int_32 by manipulating struct buffer (see buf_prepend and
buf_advance in particular).

* remember that when you add a new buffer prepend item, you must modify the
appropriate struct frame which will contain the MTU parms, so that
everything gets sized right.  For an example, see
crypto_adjust_frame_parameters().

>I'll also try to make a diff to let BSD tun devices ioctl away that
particurlar u_int_32.

Good idea.

>BTW, is it just me or is the sourceforge lists slow?
The turnaround time seems like hours to me.

Doesn't seem too bad to me.

James

Re: [Openvpn-devel] More BSD TUN info.

[Janne J. <jan...@bi...>]

On Thu, 2002-04-04 at 10:46, James Yonan wrote:
> >I don't know the openvpn data format, but if 45000054 is some sort of
> openvtun identifier, you/we/I could add some code that checked for
> 00000002 followed by 45000054 and then strip the first u_int_32 from
> the packet and go on. Perhaps a --remote-is-bsd or something similar?
>=20
> Openvpn doesn't look at the tunnel data... it just encrypts, decrypts,
> forwards etc.  The 45000054 is the beginning of the IP header of the pack=
ets
> going over the tunnel.

Dang. =3D)
(Sorry for mistyping it as openvtun)
Still, it's just as well, since that data would look different when
encrypted anyway.

> Yeah, an option might be right thing.  So --remote-is-bsd would remove th=
e
> AF_INET from incoming packets and add them to outgoing packets.  A bit of=
 a
> kludge.

Yes, but since BSD wont let you choose if you want it or not, and the
chance of changing Linux-TUN-drivers now is slim, I guess it has to be
the application that takes care of this. I'll try to make a patch and
test it, and send you the diff later.

I'll also try to make a diff to let BSD tun devices ioctl away that
particurlar u_int_32.

BTW, is it just me or is the sourceforge lists slow?
The turnaround time seems like hours to me.

--=20
Janne Johansson
jan...@bi...
BioMat Systems AB
Klarabergsg 37 3tr
111 21 Stockholm

Re: [Openvpn-devel] More BSD TUN info.

[James Y. <ji...@nt...>]

>I don't know the openvpn data format, but if 45000054 is some sort of
openvtun identifier, you/we/I could add some code that checked for
00000002 followed by 45000054 and then strip the first u_int_32 from
the packet and go on. Perhaps a --remote-is-bsd or something similar?

Openvpn doesn't look at the tunnel data... it just encrypts, decrypts,
forwards etc.  The 45000054 is the beginning of the IP header of the packets
going over the tunnel.

Yeah, an option might be right thing.  So --remote-is-bsd would remove the
AF_INET from incoming packets and add them to outgoing packets.  A bit of a
kludge.

>I wonder if Vtun ever did work between linux-vs-bsd ?

I doubt it.  I did a grep on vtun sources for AF_INET and didn't find any
usage other than the usual places.

James

[Openvpn-devel] Re: Debian package

[James Y. <ji...@nt...>]

> > Are you saying you want OpenVPN to read configuration options from a
config
> > file rather than the command line when -f is used?
> >
> > James
> >
>
> That's right. Configuration files have some advantages from my point of
> view:
> - Only one script to start/stop VPNs. A init.d-like script that will
>   call OpenVPN for each one of the conf. files.
> - Configuration files are easier to edit via scripts than shell scripts
>   with lots of '--option val \' lines
> - Configuration files are easier to comment and can even have all
>   options OpenVPN support (Soe commented out, some not)

Hmmm.  I am hesitant to put in a configuration file parser because
linux/unix already seem to have so many powerful external tools to do this,
e.g.

***********

cat >openvpn.config
dnl this is a sample OpenVPN config file

dnl local host
--local near.bar.net

dnl remote host
--remote far.bar.net

dnl tun/tap device
--dev tun1

<control-d>

openvpn `m4 openvpn.config`

********************

which gives you the power of m4 if you want it, but also gives you the
simplicity to be able to build a tunnel with just a short command line.

James