openvpn-devel — OpenVPN developers list

[Openvpn-devel] Small thought.

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

The redhat-initscript (well, linuxish initscript) that comes in the
sample-scripts (openvpn.init) really needs to have $prefix somewhere,
since it does count on you installing openvpn in /usr/sbin, though
configure puts everything in /usr/local by default.

--=20
Jan Johansson (jan...@bi...)
BioMat System AB
Klarabergsgatan 37, III
SE-111 21 Stockholm, Sweden
Phone: +46-(0)8-233500, Fax: +46-(0)70-3873952

THIS COMMUNICATION IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL, OR
ENTITY, TO WHICH IT IS DIRECTED AND MAY CONTAIN INFORMATION THAT IS
PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE
LAW.  IF RECEIVED IN ERROR: PLEASE NOTIFY US IMMEDIATELY THROUGH
IN...@BI....

[Openvpn-devel] windows port

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

I discovered today that OpenVPN 1.2.1 builds and runs almost perfectly in
the Cygwin environment under windows.  Of course there's no tun or tap
device yet, but by running with --dev null and --ping 1, you can put OpenVPN
through many of its paces including crypto and UDP network connectivity.  I
was able to connect to a linux peer using SSL/TLS mode and send pings back
and forth.

So it looks like the OpenVPN code itself is ready to go on windows as soon
as we can get a tun or tap driver working.

James

Re: [Openvpn-devel] Porting to an embedded linux

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

Sampo,

Check out the latest OpenVPN beta in CVS or:

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

I added a --dev-node option.

James

----- Original Message -----
From: "Sampo Nurmentaus" <aud...@au...>
To: <sam...@au...>
Cc: "James Yonan" <ji...@nt...>; <ope...@li...>
Sent: Thursday, June 13, 2002 6:27 AM
Subject: Re: [Openvpn-devel] Porting to an embedded linux


>
> Forget it,
>
> It works now. I just found out
> that setting the name of the device
> couses the ioctl to fail.
> Don't know if this is a
> platform dependent issue or
> a feature of the tun driver in 2.4.14
>
> I suppose the latter since tun driver
> is after all a quite high level one.
>
>
> I also added a new optional command line
> parameter to change the /dev/net/tun to
> point somewhere else to avoid reflashing :-)
>
> I included a patch agains openvpn-1.2.0
> if someone else has similar problem.
>
> Syntax is as fallows:
> --tundev /tmp/tun
>
>
> Thanks to you all for this beautiful software.
>
> As an user space program it was mutch more
> easy to port than freeswan, since kernel hackin'
> would have required a million reflashings and
> a great deal of serial debugging, since our
> device has no display.
>
>
> Sampo Nurmentaus
>
> >
> > Thanks James,
> >
> > It really helped. Simple recrosscompiling first kernel
> > and then openvpn fixed it.
> >
> > And now I have faced a new one :-(
> >
> > ioctl on line 216 in tun.c (TUNSETIFF)  seems to fail
> > complainin' about Invalid argument with errno 22.
> > I use tun driver shipped with 2.4.14 kernel and
> > if_tun.h which is identical to one in the kernel
> > source tree.
> >
> > Any ideas?
> >
> >
> > Sampo Nurmentaus
> >
> >
> >
> > > From: "Sampo Nurmentaus" <aud...@au...>
> > > To: <ope...@li...>
> > > Sent: Wednesday, June 12, 2002 8:31 AM
> > > Subject: [Openvpn-devel] Porting to an embedded linux
> > >
> > >
> > > > Hello folks,
> > > >
> > > >
> > > > I have been recently busy porting openssl, openssh
> > > > and openvpn to our embended linux environment
> > > > build on etrax 100lx processor from axis communications.
> > > >
> > > > Openvpn's code was, thanks to you guys, quite easy to
> > > > port but then I ran into problems when open vpn tries
> > > > to ioctl tun device:
> > > >
> > > > ....
> > > > 65: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
> > > > 66: Static Decrypt: Using 160 bit message digest 'SHA1' for HMAC
> > > > authentication
> > > > 67: Data Channel MTU parms: mtu=1456 extra_frame=44 extra_buffer=44
> > > > extra_tun=0
> > > > 68: Cannot ioctl TUNSETIFF tun0: File descriptor in bad state
(errno=77)
> > > > 69: Exiting
> > > >
> > > >
> > > > I have changed device to locate
> > > > in /tmp/tun, but that shuld not couse this kind of problems.
> > > > /dev is on flash image so it is easier to use /tmp for testing.
> > > > I created the device as should with:
> > > > mknod /tmp/tun c 10 200
> > > >
> > > > If I try to cat tun device read returns with the very same
> > > > error text.
> > > >
> > > >  I compiled support to kernel (not as a module)
> > > > so it should always be there.
> > > >
> > > >
> > > > Any ideas?
> > >
> > > Sampo,
> > >
> > > See message below from a previous thread on openvpn-users, and with
> > > references to vtun list.
> > >
> > > James
> > >
> > > >
> > > > Thanx in advange,
> > > >
> > > > Sampo Nurmentaus
> > >
> > > James Yonan wrote:
> > > >>Hi James,
> > > >>
> > > >>Thank you for your prompt and detailed reply.  What was happening
> > > >>earlier was that I built openvpn first, then realized I needed to
build
> > > >>the tun/tap kernel module, so built that and then rebuilt openvpn -
but
> > > >>configure (god bless it) used the cached result of NOT finding
if_tun.h.
> > > >>  I cleared configure's cache and rebuilt it again - this time it
found
> > > >>"tun/tap v1.4".  Now I'm onto a new set of problems though.  Now I
get:
> > > >>
> > > >>34: Cannot ioctl TUNSETIFF tun: File descriptor in bad state
(errno=77)
> > > >
> > > >
> > > > Though I've never seen this error personally, it has been talked
about
> > > > extensively on the vtun list (another tunneling daemon that uses the
> > > TUN/TAP
> > > > driver).
> > > >
> > > > Go to http://sourceforge.net/mailarchive/forum.php?forum_id=1826
> > > >
> > > > and search for "bad state".
> > > >
> > > > It appears to be caused by a mismatch between the tun/tap kernel
module
> > > and
> > > > the kernel itself.
> > > >
> > > > What kernel version are you using?
> > > >
> > > > Because in versions 2.4.6 and higher, the TUN/TAP module is integral
to
> > > the
> > > > kernel -- if you try to build an external version of the module,
rather
> > > than
> > > > using the one already bundled, it will likely fail.
> > >
> > > Also I've read a few posts that suggest that /usr/src/linux needs to
point
> > > to headers that match the running kernel.  Depending on what Sean has,
it
> > > may be worthwhile to ensure all the various versions
> > > (kernel/headers/tunTap) all match.
> > >
> > >
> > >
> > > _______________________________________________________________
> > >
> > > Sponsored by:
> > > ThinkGeek at http://www.ThinkGeek.com/
> > > _______________________________________________
> > > Openvpn-devel mailing list
> > > Ope...@li...
> > > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> > >
> >
> >
> > _______________________________________________________________
> >
> > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
> >
> > _______________________________________________
> > Openvpn-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> >
>

Re: [Openvpn-devel] Porting to an embedded linux

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

> Forget it,
>
> It works now. I just found out
> that setting the name of the device
> couses the ioctl to fail.
> Don't know if this is a
> platform dependent issue or
> a feature of the tun driver in 2.4.14

Note the distinction between --dev and --dev-type with respect to device
selection and naming.

> I suppose the latter since tun driver
> is after all a quite high level one.
>
>
> I also added a new optional command line
> parameter to change the /dev/net/tun to
> point somewhere else to avoid reflashing :-)
>
> I included a patch agains openvpn-1.2.0
> if someone else has similar problem.
>
> Syntax is as fallows:
> --tundev /tmp/tun

I would probably change the syntax somewhat and use "--dev-dir /tmp" to keep
in line with --dev and --dev-type.  If --dev-dir is unspecified, it defaults
to /dev.

Also, if possible, please use "diff -ur" for generating patches, since the
"unified" format is more flexible for patch merging.

> Thanks to you all for this beautiful software.
>
> As an user space program it was mutch more
> easy to port than freeswan, since kernel hackin'
> would have required a million reflashings and
> a great deal of serial debugging, since our
> device has no display.

Cool!  I'm glad it worked out for you.

James

Re: [Openvpn-devel] Porting to an embedded linux

[Sampo N. <aud...@au...>]

Forget it,

It works now. I just found out
that setting the name of the device
couses the ioctl to fail.
Don't know if this is a
platform dependent issue or
a feature of the tun driver in 2.4.14

I suppose the latter since tun driver
is after all a quite high level one.


I also added a new optional command line
parameter to change the /dev/net/tun to
point somewhere else to avoid reflashing :-)

I included a patch agains openvpn-1.2.0
if someone else has similar problem.

Syntax is as fallows:
--tundev /tmp/tun


Thanks to you all for this beautiful software.

As an user space program it was mutch more
easy to port than freeswan, since kernel hackin'
would have required a million reflashings and
a great deal of serial debugging, since our
device has no display.


Sampo Nurmentaus

>
> Thanks James,
>
> It really helped. Simple recrosscompiling first kernel
> and then openvpn fixed it.
>
> And now I have faced a new one :-(
>
> ioctl on line 216 in tun.c (TUNSETIFF)  seems to fail
> complainin' about Invalid argument with errno 22.
> I use tun driver shipped with 2.4.14 kernel and
> if_tun.h which is identical to one in the kernel
> source tree.
>
> Any ideas?
>
>
> Sampo Nurmentaus
>
>
>
> > From: "Sampo Nurmentaus" <aud...@au...>
> > To: <ope...@li...>
> > Sent: Wednesday, June 12, 2002 8:31 AM
> > Subject: [Openvpn-devel] Porting to an embedded linux
> >
> >
> > > Hello folks,
> > >
> > >
> > > I have been recently busy porting openssl, openssh
> > > and openvpn to our embended linux environment
> > > build on etrax 100lx processor from axis communications.
> > >
> > > Openvpn's code was, thanks to you guys, quite easy to
> > > port but then I ran into problems when open vpn tries
> > > to ioctl tun device:
> > >
> > > ....
> > > 65: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
> > > 66: Static Decrypt: Using 160 bit message digest 'SHA1' for HMAC
> > > authentication
> > > 67: Data Channel MTU parms: mtu=1456 extra_frame=44 extra_buffer=44
> > > extra_tun=0
> > > 68: Cannot ioctl TUNSETIFF tun0: File descriptor in bad state (errno=77)
> > > 69: Exiting
> > >
> > >
> > > I have changed device to locate
> > > in /tmp/tun, but that shuld not couse this kind of problems.
> > > /dev is on flash image so it is easier to use /tmp for testing.
> > > I created the device as should with:
> > > mknod /tmp/tun c 10 200
> > >
> > > If I try to cat tun device read returns with the very same
> > > error text.
> > >
> > >  I compiled support to kernel (not as a module)
> > > so it should always be there.
> > >
> > >
> > > Any ideas?
> >
> > Sampo,
> >
> > See message below from a previous thread on openvpn-users, and with
> > references to vtun list.
> >
> > James
> >
> > >
> > > Thanx in advange,
> > >
> > > Sampo Nurmentaus
> >
> > James Yonan wrote:
> > >>Hi James,
> > >>
> > >>Thank you for your prompt and detailed reply.  What was happening
> > >>earlier was that I built openvpn first, then realized I needed to build
> > >>the tun/tap kernel module, so built that and then rebuilt openvpn - but
> > >>configure (god bless it) used the cached result of NOT finding if_tun.h.
> > >>  I cleared configure's cache and rebuilt it again - this time it found
> > >>"tun/tap v1.4".  Now I'm onto a new set of problems though.  Now I get:
> > >>
> > >>34: Cannot ioctl TUNSETIFF tun: File descriptor in bad state (errno=77)
> > >
> > >
> > > Though I've never seen this error personally, it has been talked about
> > > extensively on the vtun list (another tunneling daemon that uses the
> > TUN/TAP
> > > driver).
> > >
> > > Go to http://sourceforge.net/mailarchive/forum.php?forum_id=1826
> > >
> > > and search for "bad state".
> > >
> > > It appears to be caused by a mismatch between the tun/tap kernel module
> > and
> > > the kernel itself.
> > >
> > > What kernel version are you using?
> > >
> > > Because in versions 2.4.6 and higher, the TUN/TAP module is integral to
> > the
> > > kernel -- if you try to build an external version of the module, rather
> > than
> > > using the one already bundled, it will likely fail.
> >
> > Also I've read a few posts that suggest that /usr/src/linux needs to point
> > to headers that match the running kernel.  Depending on what Sean has, it
> > may be worthwhile to ensure all the various versions
> > (kernel/headers/tunTap) all match.
> >
> >
> >
> > _______________________________________________________________
> >
> > Sponsored by:
> > ThinkGeek at http://www.ThinkGeek.com/
> > _______________________________________________
> > Openvpn-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> >
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
>
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

Re: [Openvpn-devel] Porting to an embedded linux

[Sampo N. <aud...@au...>]

Thanks James,

It really helped. Simple recrosscompiling first kernel
and then openvpn fixed it.

And now I have faced a new one :-(

ioctl on line 216 in tun.c (TUNSETIFF)  seems to fail
complainin' about Invalid argument with errno 22.
I use tun driver shipped with 2.4.14 kernel and
if_tun.h which is identical to one in the kernel
source tree.

Any ideas?


Sampo Nurmentaus



> From: "Sampo Nurmentaus" <aud...@au...>
> To: <ope...@li...>
> Sent: Wednesday, June 12, 2002 8:31 AM
> Subject: [Openvpn-devel] Porting to an embedded linux
>
>
> > Hello folks,
> >
> >
> > I have been recently busy porting openssl, openssh
> > and openvpn to our embended linux environment
> > build on etrax 100lx processor from axis communications.
> >
> > Openvpn's code was, thanks to you guys, quite easy to
> > port but then I ran into problems when open vpn tries
> > to ioctl tun device:
> >
> > ....
> > 65: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
> > 66: Static Decrypt: Using 160 bit message digest 'SHA1' for HMAC
> > authentication
> > 67: Data Channel MTU parms: mtu=1456 extra_frame=44 extra_buffer=44
> > extra_tun=0
> > 68: Cannot ioctl TUNSETIFF tun0: File descriptor in bad state (errno=77)
> > 69: Exiting
> >
> >
> > I have changed device to locate
> > in /tmp/tun, but that shuld not couse this kind of problems.
> > /dev is on flash image so it is easier to use /tmp for testing.
> > I created the device as should with:
> > mknod /tmp/tun c 10 200
> >
> > If I try to cat tun device read returns with the very same
> > error text.
> >
> >  I compiled support to kernel (not as a module)
> > so it should always be there.
> >
> >
> > Any ideas?
>
> Sampo,
>
> See message below from a previous thread on openvpn-users, and with
> references to vtun list.
>
> James
>
> >
> > Thanx in advange,
> >
> > Sampo Nurmentaus
>
> James Yonan wrote:
> >>Hi James,
> >>
> >>Thank you for your prompt and detailed reply.  What was happening
> >>earlier was that I built openvpn first, then realized I needed to build
> >>the tun/tap kernel module, so built that and then rebuilt openvpn - but
> >>configure (god bless it) used the cached result of NOT finding if_tun.h.
> >>  I cleared configure's cache and rebuilt it again - this time it found
> >>"tun/tap v1.4".  Now I'm onto a new set of problems though.  Now I get:
> >>
> >>34: Cannot ioctl TUNSETIFF tun: File descriptor in bad state (errno=77)
> >
> >
> > Though I've never seen this error personally, it has been talked about
> > extensively on the vtun list (another tunneling daemon that uses the
> TUN/TAP
> > driver).
> >
> > Go to http://sourceforge.net/mailarchive/forum.php?forum_id=1826
> >
> > and search for "bad state".
> >
> > It appears to be caused by a mismatch between the tun/tap kernel module
> and
> > the kernel itself.
> >
> > What kernel version are you using?
> >
> > Because in versions 2.4.6 and higher, the TUN/TAP module is integral to
> the
> > kernel -- if you try to build an external version of the module, rather
> than
> > using the one already bundled, it will likely fail.
>
> Also I've read a few posts that suggest that /usr/src/linux needs to point
> to headers that match the running kernel.  Depending on what Sean has, it
> may be worthwhile to ensure all the various versions
> (kernel/headers/tunTap) all match.
>
>
>
> _______________________________________________________________
>
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

[Openvpn-devel] OpenVPN 1.2.1 Released

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

Binary RPMs are now provided for Red Hat 7.2 and 7.3 on the download page.  
Successfully tested with OpenSSL 0.9.7 Beta 1 and the AES cipher.  Revamp 
of SIGUSR1 to provide fine-grained control over resets, the goal being to 
make OpenVPN as robust as possible on dynamic networks where DHCP/Dial-in, 
NAT, and firewalls must all be negotiated in a dynamic context.  Hostname 
resolution errors are now non-fatal and can be retried.  Added --mute for 
logging verbosity control and --group for GID downgrade after 
initialization.  Smarter pthread handling in configure.  Updates to 
website and docs.

Download:

http://sourceforge.net/project/showfiles.php?group_id=48978&release_id=94530

Enjoy!

James

Re: [Openvpn-devel] Porting to an embedded linux

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

From: "Sampo Nurmentaus" <aud...@au...>
To: <ope...@li...>
Sent: Wednesday, June 12, 2002 8:31 AM
Subject: [Openvpn-devel] Porting to an embedded linux


> Hello folks,
>
>
> I have been recently busy porting openssl, openssh
> and openvpn to our embended linux environment
> build on etrax 100lx processor from axis communications.
>
> Openvpn's code was, thanks to you guys, quite easy to
> port but then I ran into problems when open vpn tries
> to ioctl tun device:
>
> ....
> 65: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
> 66: Static Decrypt: Using 160 bit message digest 'SHA1' for HMAC
> authentication
> 67: Data Channel MTU parms: mtu=1456 extra_frame=44 extra_buffer=44
> extra_tun=0
> 68: Cannot ioctl TUNSETIFF tun0: File descriptor in bad state (errno=77)
> 69: Exiting
>
>
> I have changed device to locate
> in /tmp/tun, but that shuld not couse this kind of problems.
> /dev is on flash image so it is easier to use /tmp for testing.
> I created the device as should with:
> mknod /tmp/tun c 10 200
>
> If I try to cat tun device read returns with the very same
> error text.
>
>  I compiled support to kernel (not as a module)
> so it should always be there.
>
>
> Any ideas?

Sampo,

See message below from a previous thread on openvpn-users, and with
references to vtun list.

James

>
> Thanx in advange,
>
> Sampo Nurmentaus

James Yonan wrote:
>>Hi James,
>>
>>Thank you for your prompt and detailed reply.  What was happening
>>earlier was that I built openvpn first, then realized I needed to build
>>the tun/tap kernel module, so built that and then rebuilt openvpn - but
>>configure (god bless it) used the cached result of NOT finding if_tun.h.
>>  I cleared configure's cache and rebuilt it again - this time it found
>>"tun/tap v1.4".  Now I'm onto a new set of problems though.  Now I get:
>>
>>34: Cannot ioctl TUNSETIFF tun: File descriptor in bad state (errno=77)
>
>
> Though I've never seen this error personally, it has been talked about
> extensively on the vtun list (another tunneling daemon that uses the
TUN/TAP
> driver).
>
> Go to http://sourceforge.net/mailarchive/forum.php?forum_id=1826
>
> and search for "bad state".
>
> It appears to be caused by a mismatch between the tun/tap kernel module
and
> the kernel itself.
>
> What kernel version are you using?
>
> Because in versions 2.4.6 and higher, the TUN/TAP module is integral to
the
> kernel -- if you try to build an external version of the module, rather
than
> using the one already bundled, it will likely fail.

Also I've read a few posts that suggest that /usr/src/linux needs to point
to headers that match the running kernel.  Depending on what Sean has, it
may be worthwhile to ensure all the various versions
(kernel/headers/tunTap) all match.

[Openvpn-devel] Porting to an embedded linux

[Sampo N. <aud...@au...>]

Hello folks,


I have been recently busy porting openssl, openssh
and openvpn to our embended linux environment
build on etrax 100lx processor from axis communications.

Openvpn's code was, thanks to you guys, quite easy to
port but then I ran into problems when open vpn tries
to ioctl tun device:

....
65: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
66: Static Decrypt: Using 160 bit message digest 'SHA1' for HMAC
authentication
67: Data Channel MTU parms: mtu=1456 extra_frame=44 extra_buffer=44
extra_tun=0
68: Cannot ioctl TUNSETIFF tun0: File descriptor in bad state (errno=77)
69: Exiting


I have changed device to locate
in /tmp/tun, but that shuld not couse this kind of problems.
/dev is on flash image so it is easier to use /tmp for testing.
I created the device as should with:
mknod /tmp/tun c 10 200

If I try to cat tun device read returns with the very same
error text.

 I compiled support to kernel (not as a module)
so it should always be there.


Any ideas?

Thanx in advange,

Sampo Nurmentaus

[Openvpn-devel] Beta available, please test

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

This beta is pretty close to being 1.2.1.  Let me know if there are any
problems.

Download from CVS or:

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

Change Log since 1.2.0:

* Added --ping-restart option to restart
  connection on ping timeout using SIGUSR1
  logic (Matthias Andree).
* Added --persist-tun, --persist-key,
  --persist-local-ip, and --persist-remote-ip
  options for finer-grained control over SIGUSR1
  and --ping-restart restarts.  To
  replicate previous SIGUSR1 functionality,
  use --persist-remote-ip.
* Changed residual IV fetching code to take
  IV from tail of ciphertext.
* Added check to make sure that CFB or OFB
  cipher modes are only used with SSL/TLS
  authentication mode, and added a caveat
  to INSTALL.
* Changed signal handling during initialization
  (including re-initialization during restarts)
  to exit on SIGTERM or SIGINT and ignore other
  signals which would ordinarily be caught.
* Added --resolv-retry option to allow
  retries on hostname resolution.
* Expanded the --float option to also
  allow dynamic changes in source port number
  on incoming datagrams.
* Added --mute option to limit repetitive
  logging of similar message types.
* Added --group option to downgrade GID
  after initialization.
* Try to set ifconfig path automatically
  in configure.
* Successfully tested with
  OpenSSL 0.9.7 Beta 1 and AES cipher.
* Added RPM notes to INSTALL.
* Added ACX_PTHREAD (from the autoconf
  macro archive) to configure.ac
  to figure out the right pthread
  options for a given platform.
* Broke out macro definitions from
  configure.ac to acinclude.m4.
* Minor changes to docs and HOWTO.
* All changes maintain protocol compatibility
  with OpenVPN versions since 1.1.0.

James

[Openvpn-devel] Beta available, please test

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

This beta is pretty close to being 1.2.1.  Let me know if there are any
problems.

Download from CVS or:

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

Change Log since 1.2.0:

* Added --ping-restart option to restart
  connection on ping timeout using SIGUSR1
  logic (Matthias Andree).
* Added --persist-tun, --persist-key,
  --persist-local-ip, and --persist-remote-ip
  options for finer-grained control over SIGUSR1
  and --ping-restart restarts.  To
  replicate previous SIGUSR1 functionality,
  use --persist-remote-ip.
* Changed residual IV fetching code to take
  IV from tail of ciphertext.
* Added check to make sure that CFB or OFB
  cipher modes are only used with SSL/TLS
  authentication mode, and added a caveat
  to INSTALL.
* Changed signal handling during initialization
  (including re-initialization during restarts)
  to exit on SIGTERM or SIGINT and ignore other
  signals which would ordinarily be caught.
* Added --resolv-retry option to allow
  retries on hostname resolution.
* Expanded the --float option to also
  allow dynamic changes in source port number
  on incoming datagrams.
* Added --mute option to limit repetitive
  logging of similar message types.
* Added --group option to downgrade GID
  after initialization.
* Try to set ifconfig path automatically
  in configure.
* Successfully tested with
  OpenSSL 0.9.7 Beta 1 and AES cipher.
* Added RPM notes to INSTALL.
* Added ACX_PTHREAD (from the autoconf
  macro archive) to configure.ac
  to figure out the right pthread
  options for a given platform.
* Broke out macro definitions from
  configure.ac to acinclude.m4.
* Minor changes to docs and HOWTO.
* All changes maintain protocol compatibility
  with OpenVPN versions since 1.1.0.

Re: [Openvpn-devel] New OpenVPN beta available for testing

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

> > * Added ACX_PTHREAD (from the autoconf
> >   macro archive) to configure.ac
> >   to figure out the right pthread
> >   options for a given platform.
>
> Hi James,
>
> I some archs in Debian build binary packages using gcc3, the following
> patch solved the problem:
>
> --- openvpn-1.2.0.orig/configure
> +++ openvpn-1.2.0/configure
> @@ -9716,7 +9716,7 @@
>                 CFLAGS="$CFLAGS -pthread"
>                 ;;
>           *)
> -               CFLAGS="$CFLAGS -pthread"
> +               CFLAGS="$CFLAGS -lpthread"
>                 ;;
>           esac
>
> --- openvpn-1.2.0.orig/configure.ac
> +++ openvpn-1.2.0/configure.ac
> @@ -284,7 +284,7 @@
>                 CFLAGS="$CFLAGS -pthread"
>                 ;;
>           *)
> -               CFLAGS="$CFLAGS -pthread"
> +               CFLAGS="$CFLAGS -lpthread"
>                 ;;
>
>
> The new configure* scripts work flawlessly :-)

Cool!  I did see that patch over on Debian, unfortunately it's not a
portable solution...  I did some fishing and found ACX_PTHREAD which looks
like it's the Right way to do this.

James

Re: [Openvpn-devel] New OpenVPN beta available for testing

[Alberto G. I. <ag...@ag...>]

On Sat, Jun 01, 2002 at 01:02:44PM -0600, James Yonan wrote:
> This beta revamps SIGUSR1 signal processing to make it like SIGHUP except
> with more fine-grained control over which OpenVPN subsystems are reset.  It
> also allows a SIGUSR1 to be generated internally based on --ping
> and --ping-restart.  The goal is to make OpenVPN as robust as possible on
> dynamic networks where DHCP, NAT, and firewalls must all be negotiated in a
> dynamic context.  The --persist-tun option allows a reset without closing
> and reopening the tun device (which allows seamless connectivity through the
> tunnel across DHCP resets).  The --persist-ip option allows for preservation
> of remote IP address across DHCP resets.  This allows both OpenVPN peers to
> be DHCP clients.
> 
> Also changed is the pthread handling in the configure script.  The script
> now uses the ACX_PTHREAD macro from the autoconf macro archive to
> intelligently figure out which cc/gcc option to use when building with POSIX
> thread support.  Some problems were reported when trying to build OpenVPN
> with pthread support using gcc3.
> 
> * Added ACX_PTHREAD (from the autoconf
>   macro archive) to configure.ac
>   to figure out the right pthread
>   options for a given platform.

Hi James,

I some archs in Debian build binary packages using gcc3, the following
patch solved the problem:

--- openvpn-1.2.0.orig/configure
+++ openvpn-1.2.0/configure
@@ -9716,7 +9716,7 @@
                CFLAGS="$CFLAGS -pthread"
                ;;
          *)
-               CFLAGS="$CFLAGS -pthread"
+               CFLAGS="$CFLAGS -lpthread"
                ;;
          esac

--- openvpn-1.2.0.orig/configure.ac
+++ openvpn-1.2.0/configure.ac
@@ -284,7 +284,7 @@
                CFLAGS="$CFLAGS -pthread"
                ;;
          *)
-               CFLAGS="$CFLAGS -pthread"
+               CFLAGS="$CFLAGS -lpthread"
                ;;


The new configure* scripts work flawlessly :-)

Regards,

Alberto

-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
ag...@ag...                     | to obtain a little temporary safety
Encrypted mail preferred       | deserve neither liberty nor safety.

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3

[Openvpn-devel] New OpenVPN beta available for testing

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

This beta revamps SIGUSR1 signal processing to make it like SIGHUP except
with more fine-grained control over which OpenVPN subsystems are reset.  It
also allows a SIGUSR1 to be generated internally based on --ping
and --ping-restart.  The goal is to make OpenVPN as robust as possible on
dynamic networks where DHCP, NAT, and firewalls must all be negotiated in a
dynamic context.  The --persist-tun option allows a reset without closing
and reopening the tun device (which allows seamless connectivity through the
tunnel across DHCP resets).  The --persist-ip option allows for preservation
of remote IP address across DHCP resets.  This allows both OpenVPN peers to
be DHCP clients.

Also changed is the pthread handling in the configure script.  The script
now uses the ACX_PTHREAD macro from the autoconf macro archive to
intelligently figure out which cc/gcc option to use when building with POSIX
thread support.  Some problems were reported when trying to build OpenVPN
with pthread support using gcc3.

I expect to make a new release in a few days if no problems are encountered.

Here is the full change log:

* Added --ping-restart option to restart
  connection on ping timeout using SIGUSR1
  logic (Matthias Andree).
* Added --persist-tun and --persist-ip options
  for finer-grained control over SIGUSR1
  and --ping-restart restarts.  To
  replicate previous SIGUSR1 functionality,
  use --persist-ip.
* Changed residual IV fetching code to take
  IV from tail of ciphertext.
* Added check to make sure that CFB or OFB
  cipher modes are only used with SSL/TLS
  authentication mode, and added a caveat
  to INSTALL.
* Added RPM notes to INSTALL.
* Added ACX_PTHREAD (from the autoconf
  macro archive) to configure.ac
  to figure out the right pthread
  options for a given platform.
* Broke out macro definitions from
  configure.ac to acinclude.m4.
* All changes maintain protocol compatibility
  with 1.1.0+.

Download from CVS or:

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

James

[Openvpn-devel] OpenVPN 1.2.0 Released

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

Download:

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

Release Notes:

OpenVPN 1.2.0 adds pthread support for background processing of SSL/TLS key
negotiations, allowing efficient usage of large RSA keys (i.e. 2048 bits or
larger). The OpenVPN web site has been considerably expanded, including a
new HOWTO page that gives detailed instructions for setting up a complete
telecommuting solution with firewall, VPN, NAT, and DHCP support. OpenVPN
1.2.0 has additional feature improvements including configuration file
support and running daemon statistics via SIGUSR2.

Since version 1.1.1, OpenVPN has seen extensive porting activity, including
ports to Solaris, OpenBSD, Mac OS X (Darwin), and 64-bit Linux.

ChangeLog from 1.1.1 -> 1.2.0

* Added configuration file support via
  the --config option.
* Added pthread support to improve latency.
  With pthread support, OpenVPN
  will offload CPU-intensive tasks such as RSA
  key number crunching to a background thread
  to improve tunnel packet forwarding
  latency.  pthread support can be enabled
  with the --enable-pthread configure option.
  Pthread support is currently available
  only for Linux and Solaris.
* Added --dev-type option so that tun/tap
  device names don't need to begin with
  "tun" or "tap".
* Added --writepid option to write main
  process ID to a file.
* Numerous portability fixes to ease
  porting to other OSes including changing
  all network types to uint8_t and uint32_t,
  and not assuming that time_t is 32 bits.
* Backported to OpenSSL 0.9.5.
* Ported to Solaris.
* Finished OpenBSD port except for
  pthread support.
* Added initialization script:
  sample-scripts/openvpn.init
  (Douglas Keller)
* Ported to Mac OS X (Christoph Pfisterer).
* Improved resilience to DoS attacks when
  TLS mode is used without --remote or
  --tls-auth, or when --float is used
  with --remote.  Note however that the best
  defense against DoS attacks in TLS mode
  is to use --tls-auth.
* Eliminated automake/autoconf dependency
  for non-developers.
* Ported configure.in to configure.ac
  and autoconf 2.50+.
* SIGHUP signal now causes OpenVPN to restart
  and re-read command line and or config file,
  in conformance with canonical daemon behaviour.
* SIGUSR1 now does what SIGHUP did in
  version 1.1.1 and earlier -- close and reopen
  the UDP socket for use when DHCP changes
  host's IP address and preserve most recently
  authenticated peer address without rereading
  config file.
* SIGUSR2 added -- outputs current statistics,
  including compression statistics.
* All changes maintain protocol compatibility
  with 1.1.1 and 1.1.0.

James

[Openvpn-devel] Re: [Openvpn-users] New Beta, Please Test

[bishop <bi...@pl...>]

Douglas Keller wrote:
> James Yonan writes:
>  > This beta can be considered an initial release candidate for 1.2.0.  See
>  > changelog below.
>  > 
> 
> Things are looking good for me...built the rpm with
> "rpm -ta openvpn-1.1.1.18.tar.gz", the rpm included the init
> script correctly.  I installed it on my machines without any problems
> (I had been running 1.1.1.16 for the last couple of days without any
> problems).
> 
> doug

Doug,

The init scripts are only good for very recent machines;  RH62, for 
instance, will completely hate it.  It's a common mistake, I have a 
one-line diff later on this evening.

Not sure if this is a blocker for the 1.2.0 release.

  - bish

[Openvpn-devel] New Beta, Please Test

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

This beta can be considered an initial release candidate for 1.2.0.  See
changelog below.

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

Beta web site:

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

Changes since 1.1.1:

2002.05.19 -- Version 1.1.1.18

* Added configuration file support via
  the --config option.
* Added pthread support to improve latency.
  With pthread support, OpenVPN
  will offload CPU-intensive tasks such as RSA
  key number crunching to a background thread
  to improve tunnel packet forwarding
  latency.  pthread support can be enabled
  with the --enable-pthread configure option.
  Pthread support is currently available
  only for Linux and Solaris.
* Added --dev-type option so that tun/tap
  device names don't need to begin with
  "tun" or "tap".
* Added --writepid option to write main
  process ID to a file.
* Numerous portability fixes to ease
  porting to other OSes including changing
  all network types to uint8_t and uint32_t,
  and not assuming that time_t is 32 bits.
* Backported to OpenSSL 0.9.5.
* Ported to Solaris.
* Finished OpenBSD port except for
  pthread support.
* Added initialization script:
  sample-scripts/openvpn.init
  (Douglas Keller)
* Ported to Mac OS X (Christoph Pfisterer).
* Improved resilience to DoS attacks when
  TLS mode is used without --remote or
  --tls-auth, or when --float is used
  with --remote.  Note however that the best
  defense against DoS attacks in TLS mode
  is to use --tls-auth.
* Eliminated automake/autoconf dependency
  for non-developers.
* Ported configure.in to configure.ac
  and autoconf 2.50+.
* SIGHUP signal now causes OpenVPN to restart
  and re-read command line and or config file,
  in conformance with canonical daemon behaviour.
* SIGUSR1 now does what SIGHUP did in
  version 1.1.1 and earlier -- close and reopen
  the UDP socket for use when DHCP changes
  host's IP address and preserve most recently
  authenticated peer address without rereading
  config file.
* SIGUSR2 added -- outputs current statistics,
  including compression statistics.
* All changes maintain protocol compatibility
  with 1.1.1 and 1.1.0.

James

[Openvpn-devel] Re: [Openvpn-users] 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

I had quite no feedback on autovpn. Is there any interest?
If not, we'll keep it for us :-(

Anyone interested?
-jec

[Openvpn-devel] Re: [Openvpn-users] encryption problems

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

> thank you very much. I just tried 1.1.1.13 and I got a working tunnel
> even using my axp-box. For this the tunnel is between an 1.1.1-i386 and
> an 1.1.1.13-axp.

Cool.  The latest beta version of OpenVPN has lots of portability fixes
which make minimal assumptions about word sizes, and use uint8_t and
uint32_t for all network types, while being fully protocol compatible with
1.1.0 and 1.1.1.

> BTW: Is there someone building a config file for openvpn? I'm just
> playing with a small set of scripts and an config file with one line per
> connection. At this time I only apply on preshared secrets.

Config files are supported in the current beta releases, and will be
supported in the next stable release which will be 1.2.0.

Right now there's also a "beta version" of the web site which will go live
when 1.2.0 is released that has a new HOWTO and lots of config file
examples:

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

James

Re: [Openvpn-devel] Mac OS X support

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

Hello Christoph,

Hey, that's great news.  It looks like you were able to make it work with a
very small patch.

A couple comments:

(1) The TYPE_SOCKLEN_T macro is cool, but we can't rely on people having
autoconf 2.5 or newer (unless we start distributing configure in addition to
configure.in).  Is there a way the macro could be coded to eliminate this
dependency?  What is it in the macro that requires 2.5?

(2) You might want to take a look at 1.1.1.9 which is on the CVS now.  In
particular, tun.c has seen a lot of work over the weekend to add support for
solaris, freebsd, and openbsd.  You will want to add an #ifdef TARGET_DARWIN
to the mix.  You might also want to add a TARGET_DARWIN case to
do_ifconfig(), so OpenVPN's --ifconfig option works correctly on Mac OS X.

Can you edit INSTALL with the appropriate Mac OS X info, including a URL
where they can get your tun driver, and initial steps to create and
configure the tun device?

I will merge everything in your patch now except the TYPE_SOCKLEN_T macro
pending more thought.

Great Work!

James

----- Original Message -----
From: "Christoph Pfisterer" <cp...@ch...>
To: <ope...@li...>
Sent: Monday, May 06, 2002 7:08 AM
Subject: [Openvpn-devel] Mac OS X support


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