openvpn-devel — OpenVPN developers list

[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

[Openvpn-devel] More on BSD vs Linux tun devices.

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

There isn't an option to remove the AF_INET attachment on tun packets
on OpenBSD at least, although there are ioctl's to add more "junk" at
the beginning, such as the sender ip address.

After checking the Linux kernel source, there seems to be an
option that MIGHT add info to packets, called "IFF_NO_PI",
which you set, meaning that you remove the PI-option and
don't add info to packets.

Now, I don't know what this PI stuff is for, the comments around it
are sparse, to say the least. ;-)

Here is a snippet from your code, on the 2.4 dynamic tun-stuff:

int
open_tun (const char *dev, char *actual, int size)
{
  <..cut some lines away...>
  ifr.ifr_flags =3D IFF_NO_PI;


And the corresponding Linux kernel code that gets to run
if IFF_NO_PI is not set (the flag name is TUN_NO_PI):

/* Get packet from user space buffer(already verified) */
static __inline__ ssize_t tun_get_user(struct tun_struct *tun, const
char *buf, size_t count)
{
	struct tun_pi pi =3D { 0, __constant_htons(ETH_P_IP) };
	register const char *ptr =3D buf;=20
	register int len =3D count;
	struct sk_buff *skb;

	if (!(tun->flags & TUN_NO_PI)) {
		if ((len -=3D sizeof(pi)) < 0)
			return -EINVAL;

		copy_from_user(&pi, ptr, sizeof(pi));
		ptr +=3D sizeof(pi);
	}


This seems (to me) to mean:
if TUN_NO_PI is not set, and len gets sizeof(pi) subtracted but still
is larger (or eq) than 0, get a "pi" struct from userspace and copy
it to the beginning of the space that "ptr" is pointing to.

In the receive function, we see:

	struct tun_pi pi =3D { 0, skb->protocol };
	int len =3D count, total =3D 0;
	char *ptr =3D buf;

	if (!(tun->flags & TUN_NO_PI)) {
		if ((len -=3D sizeof(pi)) < 0)
			return -EINVAL;

		if (len < skb->len) {
			/* Packet will be striped */
			pi.flags |=3D TUN_PKT_STRIP;
		}
=20
		copy_to_user(ptr, &pi, sizeof(pi));

		total +=3D sizeof(pi);
		ptr +=3D sizeof(pi);
	}

Which seems to indicate that the protocol might be stored in the
tun_pi struct after all.
The tun_pi is defined to contain two unsigned shorts, one "flags" and
one "proto".
The TUN_PKT_STRIP seems to have no other effect than to just exist
so that someone might read it in the packet. But that's just my guess.

Next problem. The proto filled in by TUN is "htons(ETH_P_IP)" which
is 0x0800 in intel byte order, which would be something like
0x0008 if my htons guess is correct for a short.

So BSD and Linux say different things. BSDs say "here comes IPv4 stuff"
with AF_INET in a htonl(u_int_32) and Linux says
"here comes Ethernet IPv4 stuff" with two shorts, one containing
ETH_P_IP in intel byte order or it says nothing at all.

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.

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

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

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

On Wed, 2002-04-03 at 00:44, James Yonan wrote:
> >Sorry for "spamming" so much with my porting issues.
>=20
> Hey, I think it's great you're trying to port it!  Post as much as you wa=
nt.
>=20
> >Now it seems that BSD (at least Free/OpenBSD) TUN devices send AF_INET
> as a u_int32_t in network byte order first, which Linux tun-devs
> dont.
>=20
> Interesting.  We should post something about that on the TUN/TAP list.  I
> would think that network byte order should be the correct behaviour.

I'll get back to this further down, but to clarify, _each_ packet read
from tun will have this u_int_32 prepended.

> >That's why my last mail contains sending of "00000002" as the first
> 32 bits, it's telling the other end which AF to use.
>=20
> >When initiated from the Linux end, the BSD will say
> "unknown address family" or something very similar, which is true
> since it gets "45000054" as the first data.
>=20
> >Is there two types of tun or is the BSD tuns just slightly different and
> incompatible by design?
>=20
> Also sounds like a TUN/TAP list question.  I know the TUN/TAP driver beca=
me
> an official part of the linux kernel as of the early 2.4 releases.
>=20
> A fix on the linux side to conform to network byte ordering would be dice=
y
> since it would break compatibility.

Well, sooner or later Linux should do that too, to support big endian
machines. But the issue was more to the fact that the BSD sends this:
"00000002 45000054 ..blabla" whereas Linux sends this:
"45000054 ..blabla".

The manpage for tun on BSD says:
"The first u_int32_t of data will always be the address family
 (eg, AF_INET) of the packet in network byte order.
 By default, the packet data follows immediately, but if the PREPADDR
 bit is set, the address to which the packet is to be sent is placed =20
 after the address family u_int32_t and before the packet data."

Now, I don't want to rant about OSes, but being able to just type
"man tun" when you're dealing with tun interfaces and get serious info
is quite nice. I googled a bit yesterday and could not find neither tun
info for Linux nor the kernel source as cvsweb, so I could read the
source at least. 8-/

> My approach would be to do the fix on the linux side but add an extra che=
ck
> for compatibility and allow packets if the order is wrong.  Since there
> aren't too many address families to worry about, the bad ordering test
> should't be terribly ambiguous.
>=20
> And since linux kernel changes take a long time to happen, it might be
> necessary to add a workaround in OpenVPN to deal with this.
>=20
> What do you think?

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?

The last bit of the manpage says:
"NOTES
 Very old versions of the tunnel device did not include the address
 family at the start of the packet.  More recent versions passed the
 address family as a single byte, but this caused problems with bpf,
 hence the current version passes a u_int32_t of address family.
 This was initially pass in host byte order, but the current version
 now uses network byte order."

I checked the CVS for openbsd, and the native -> network byte order
change was done 3 years ago, which is a really long time.
I wonder if Vtun ever did work between linux-vs-bsd ?
Or does it have code to handle this?

--=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...>]

>Sorry for "spamming" so much with my porting issues.

Hey, I think it's great you're trying to port it!  Post as much as you want.

>Now it seems that BSD (at least Free/OpenBSD) TUN devices send AF_INET
as a u_int32_t in network byte order first, which Linux tun-devs
dont.

Interesting.  We should post something about that on the TUN/TAP list.  I
would think that network byte order should be the correct behaviour.

>That's why my last mail contains sending of "00000002" as the first
32 bits, it's telling the other end which AF to use.

>When initiated from the Linux end, the BSD will say
"unknown address family" or something very similar, which is true
since it gets "45000054" as the first data.

>Is there two types of tun or is the BSD tuns just slightly different and
incompatible by design?

Also sounds like a TUN/TAP list question.  I know the TUN/TAP driver became
an official part of the linux kernel as of the early 2.4 releases.

A fix on the linux side to conform to network byte ordering would be dicey
since it would break compatibility.

My approach would be to do the fix on the linux side but add an extra check
for compatibility and allow packets if the order is wrong.  Since there
aren't too many address families to worry about, the bad ordering test
should't be terribly ambiguous.

And since linux kernel changes take a long time to happen, it might be
necessary to add a workaround in OpenVPN to deal with this.

What do you think?

James

[Openvpn-devel] More BSD TUN info.

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

Sorry for "spamming" so much with my porting issues.

Now it seems that BSD (at least Free/OpenBSD) TUN devices send AF_INET
as a u_int32_t in network byte order first, which Linux tun-devs
dont.

That's why my last mail contains sending of "00000002" as the first
32 bits, it's telling the other end which AF to use.

When initiated from the Linux end, the BSD will say
"unknown address family" or something very similar, which is true
since it gets "45000054" as the first data.

Is there two types of tun or is the BSD tuns just slightly different and
incompatible by design?


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

[Openvpn-devel] OBSD more tests done and failed.

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

Either I failed before, or something happened during my tests.

My success-mail might have been a bit premature, since I can't
get it to work now at all. One of the machines is the def-gw of
the other usually, so I might have mis-configured it to not use
the tunnel somehow. 8-(

I was about to test ssl, and didn't get it to work. Then I thought
I'd go back to unencrypted tests and they didn't work either.

Side 1 (OBSD 1.2.3.4) goes like this:

./openvpn --dev tun1 --remote 1.2.3.5 --local 1.2.3.4 --verb 8=20

51: TUN/TAP device /dev/tun1 opened
52: ******* WARNING *******: all encryption and authentication features
disabled -- all data will be tunnelled as cleartext
53: Data Channel MTU parms: mtu=3D1450 extra_frame=3D0 extra_buffer=3D0
54: INTERVAL TRIGGER
55: select returned 1
56: read from tun returned 88
57: ENCRYPT FROM: 00000002 45000054 c85a0000 ff01df4b 0a000002 0a000001
080011cf da07000[more...]
58: ENCRYPT TO: 00000002 45000054 c85a0000 ff01df4b 0a000002 0a000001
080011cf da07000[more...]
59: select returned 1
60: write to udp returned 88
61: UDP WRITE to 1.2.3.5:5000:  DATA 00000002 45000054 c85a0000 ff01df4b
0a000002 0a000001 080011cf da07000[more...]

and side 2 (Linux 1.2.3.5) was set up like this:

./openvpn --dev tun0 --remote 1.2.3.4  --local 1.2.3.5 --verb 8

53: TUN/TAP device tun0 opened
54: ******* WARNING *******: all encryption and authentication features
disabled -- all data will be tunnelled as cleartext
55: Data Channel MTU parms: mtu=3D1450 extra_frame=3D0 extra_buffer=3D0
56: INTERVAL TRIGGER
57: select returned 1
58: read from udp returned 88
59: UDP READ from 1.2.3.4:5000:  DATA 00000002 45000054 c85a0000
ff01df4b 0a000002 0a000001 080011cf da07000[more...]
60: IP Address OK from 1.2.3.4:5000
61: Peer Connection Initiated with 1.2.3.4:5000
62: select returned 1
63: write to tun returned 88
64: select returned 1
65: read from udp returned 88
66: UDP READ from 1.2.3.4:5000:  DATA 00000002 45000054 f27a0000
ff01b52b 0a000002 0a000001 0800fba0 da07000[more...]
67: IP Address OK from 1.2.3.4:5000
68: select returned 1
69: write to tun returned 88
70: select returned 1
71: read from udp returned 88



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

[Openvpn-devel] Success with my OBSD diffs.

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

I have now pinged between linux2.4 with openvpn1.0.3 and openbsd3.0
running the version that comes out of my diff.

There is need for a small readme, since ifconfig differs on bsd
but apart from that, everything went smoothly after some initial
mistesting on my part. =3D)
It was done on an unencrypted channel, but since --keygen worked
without problems, I can't see how ssl would pose a problem.

I'll get back to you when I have tested ssl.

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