Matthias,
Okay, I just put a bunch of stuff in the CVS:
(1) your earlier patch (pre-variable argument macro fix)
(2) some warning removals
(3) my own vararg stuff (we'll have to reconcile our versions)
(4) removed generated files from CVS
(5) fixed --disable-crypto
(6) a better undefined
Matthias,
Hey, thanks for the patch and all the testing work on different platforms.
You raise a number of good points which I will address below:
(1) Signed/unsigned comparison warnings in packet_id.c and socket.c -- these
are obviously just cast issues and I will clean up for a mostly
Hello OpenVPN Users & Developers,
I thought it would be a good time to wrap up the minor fixes that have gone
into the codebase over the last couple months.
So here's a beta which I would encourage you to test as much as possible.
While the changes are mostly minor, some of the fixes such as
Aaron Sethman said:
> On Mon, 10 Feb 2003, Alberto Gonzalez Iniesta wrote:
>
> >
> > Hi,
> >
> > Again, I'm no C hacker, but I think this should be better:
> >
> > for(x = 3; x < 100; x++)
> >
> > Since the first 3 fds (stdin, stdout and stderr) should be kept open.
> >
>
Alberto,
Yes, I agree. The child process that executes a script doesn't need those
file descriptors, so they can be closed. Since openvpn uses the system()
function to run scripts, and because the system() function doesn't close any
file descriptors on its own, it would be necessary to write an
Hello Julien,
julien Touche said:
>
> Hi
>
> first greetings for openvpn which is a best of for easy VPN :)
Thanks!
>
> i have a small list of questions i can't answer myself:
>
> - at which stage is the win32 port ? always looking for tun driver ?
> i give a
> Hello James,
>
> That's good to hear,
>
> There are some questions that I had to over come with
> my experimental forking server, like when does a forked
> process exit? Should we always use something line --inactive
> or --ping-exit? Or should there be a control command for closing
> the
Sampo,
We've added some features to 1.3.2 and pre-1.3.3 code that are a step in the
direction of full forking server support.
For example, 1.3.2 supports instantiation by inetd/xinetd. xinetd has its own
DoS resistant features, and I added a new flag to the pre-1.3.3 code
(--replay-persist) in
e tap device will show trucated-ip missing bytes.
>
> zxu
>
> -Original Message-
> From: James Yonan
> To: Zhen Xu; ''openvpn-us...@lists.sourceforge.net' '
> Sent: 11/25/02 1:22 PM
> Subject: RE: [Openvpn-users] OpenVPN w/ TAP device on Linux/FreeBSD
>
> Zhen Xu
Craig Knox said:
> Hi,
>
> > One of the problems I can see with this is that you give some information
> > away about the payload, mind you not much, but you are regardless.
>
> That is true - but for me its either give away TOS or have things become
> unresponsive.
>
>
Felipe Sanchez said:
>
> Hi, I've been using openvpn for about a month now with great success, I
> have already setup about a dozen VPN connections in various environments.
>
> Lately I began wondering what would happen if I don't want some peer to be
> able to connect
Another beta is available to test. This one adds support and documentation for
on-demand xinetd instantiation of the openvpn daemon.
Changes since last beta:
* Added FreeBSD 4.1.1+ TUN/TAP driver notes to
INSTALL (Matthias Andree).
* Added inetd/xinetd support (--inetd) including
Matthias,
Thanks, I've merged with CVS.
James
Matthias Andree <ma+ov...@dt.e-technik.uni-dortmund.de> said:
> On Thu, 17 Oct 2002, James Yonan wrote:
>
> >
> > Here is the latest pre-1.3.2 beta that now supports IPv6 over tun on Linux.
> > Please test. I
Aaron,
Thanks for the patch, however I was not able to get it to work with IPv4 while
talking between a 2.4.9 and 2.4.17 kernel, where both peers are running the
patch. The code compiles and runs, but pings don't go through. Perhaps there
is a minimum kernel version necessary for this to
Richard A Nelson <cow...@vnet.ibm.com> said:
> On Tue, 27 Aug 2002, James Yonan wrote:
>
> > Hello Richard,
>
> Hi, thanks for the quick feedback
>
> > Normally we shouldn't get EAGAIN in the UDP read loop because we block on
> > select and don't
Hello Richard,
Normally we shouldn't get EAGAIN in the UDP read loop because we block on
select and don't call recvfrom until there is a datagram waiting for us. So
the fact that you are getting a lot of EAGAIN messages is interesting and
probably indicative of some kind of problem. Is there
As many of you have probably noticed, the OpenSSL project released a
security update today which fixes potential remote buffer overflows.
What you may not have known is that the ASN1 parser bug was independently
discovered in the process of stress testing OpenVPN, earning yours truly the
dubious
Dimitri,
Thanks for the patch, I will apply it to the CVS shortly.
One question I have, were you able to connect OpenVPN running on NetBSD to
OpenVPN running on a different platform such as Linux?
I ask because some tun/tap devices will prepend unnecessary stuff onto the
datagram that must be
Hi Dimitri,
Yes, it would be great if you would like to do a NetBSD port. I imagine it
would be pretty straightforward, given the existence of FreeBSD, OpenBSD,
and Mac OS X ports.
The "PORTS" file has a nice rundown on making a clean port, with some points
on testing to make sure all the major
> > Hi Sampo,
> >
> > > I have been busy writing a forking server
> > > addon to openvpn.
Will forking server only work for TLS mode?
> >
> > Cool... Does each potential connecting client need a separate config
file,
> > or does the server use a common client template and then keep track of
> >
Hi Sampo,
> I have been busy writing a forking server
> addon to openvpn.
Cool... Does each potential connecting client need a separate config file,
or does the server use a common client template and then keep track of
things like dynamic ports, dynamic endpoint addresses, etc?
> In openvpn.c
Hi Michael,
You are right that it is not difficult for an attacker to replay UDP
datagrams. OpenVPN uses a variant of the "sliding-window" algorithm used by
IPSec where each packet is tagged with a unique, incrementing sequence
number, allowing any replayed datagrams to be identified and
1.3.0 had a small bug in openvpn.spec and openvpn.init that caused an RPM
upgrade failure.
This bug is fixed in 1.3.1.
1.3.1 Release Notes:
If you are trying to upgrade OpenVPN via an RPM package, there is a bug in
the RPM uninstall script from 1.2.1 that doesn't handle RPM upgrades
properly.
1.3.0 had a small bug in openvpn.spec and openvpn.init that caused an RPM
upgrade failure.
This bug is fixed in 1.3.1.
1.3.1 Release Notes:
If you are trying to upgrade OpenVPN via an RPM package, there is a bug in
the RPM uninstall script from 1.2.1 that doesn't handle RPM upgrades
properly.
What should the default MTU be?
Right now the default UDP MTU is 1500 if you use --ifconfig, which is
probably too high, because as Matthias Andree pointed out, 1500 + IP header
size is greater than 1500 and will cause fragmentation on ethernet networks
where the MTU is 1500.
1450 might make
What should the default MTU be?
Right now the default UDP MTU is 1500 if you use --ifconfig, which is
probably too high, because as Matthias Andree pointed out, 1500 + IP header
size is greater than 1500 and will cause fragmentation on ethernet networks
where the MTU is 1500.
1450 might make
> Hi James,
>
> I do agree that forking and using a new port is a good solution due to
> it's simplicity. And fork cost ain't much for normal traffic since it's
> done only once per tunnel opening.
>
> There could also be a limit for the speed new childs are forked. Since it
> does not matter if
> Hi James,
>
> I do agree that forking and using a new port is a good solution due to
> it's simplicity. And fork cost ain't much for normal traffic since it's
> done only once per tunnel opening.
>
> There could also be a limit for the speed new childs are forked. Since it
> does not matter if
On 28 Jun 2002, Jan Johansson wrote:
>
> > Is it a different problem than with an unknown ip address allowed to connect
> > to a single port ?
> >
> > Does somebody know about an udp server forking and using different ports,
> > with
> > code available, of course ;-).
> >
> > I may be wrong,
On 28 Jun 2002, Jan Johansson wrote:
>
> > Is it a different problem than with an unknown ip address allowed to connect
> > to a single port ?
> >
> > Does somebody know about an udp server forking and using different ports,
> > with
> > code available, of course ;-).
> >
> > I may be wrong,
On Fri, 28 Jun 2002, Sampo Nurmentaus wrote:
>
> Hello all,
>
> > > Hi,
> > >
> > > I don't know if my idea are really pertinent pertinent, I haven't deeply
> > read
> > > the code nor have a lot of experience, but here they are.
> > >
> > > > As far as ports are concerned, I am thinking that a
On Fri, 28 Jun 2002, Sampo Nurmentaus wrote:
>
> Hello all,
>
> > > Hi,
> > >
> > > I don't know if my idea are really pertinent pertinent, I haven't deeply
> > read
> > > the code nor have a lot of experience, but here they are.
> > >
> > > > As far as ports are concerned, I am thinking that a
Hi Alberto,
> I'd like to ask for a couple of features (little ones) added to OpenVPN.
> Comments welcomed.
>
> 1) OpenVPN should refuse to start a connection based on shared secret
> when the file containing that key is world readable (or writable).
> Paranoia won't even like group readable :-)
Hi Alberto,
> I'd like to ask for a couple of features (little ones) added to OpenVPN.
> Comments welcomed.
>
> 1) OpenVPN should refuse to start a connection based on shared secret
> when the file containing that key is world readable (or writable).
> Paranoia won't even like group readable :-)
On 24 Jun 2002, Jan Johansson wrote:
> On Sun, 2002-06-23 at 09:18, James Yonan wrote:
> > Hello Pat,
> >
> > I think it's a good idea, something we're considering for the next release.
>
> I would like to have some info then on how to stop accepting a certain
> cl
On 24 Jun 2002, Jan Johansson wrote:
> On Sun, 2002-06-23 at 09:18, James Yonan wrote:
> > Hello Pat,
> >
> > I think it's a good idea, something we're considering for the next release.
>
> I would like to have some info then on how to stop accepting a certain
> cl
Hello Pat,
I think it's a good idea, something we're considering for the next release.
James
- Original Message -
From: "Patrice DUMAS - DOCT"
To:
Sent: Friday, June 21, 2002 12:01 PM
Subject: [Openvpn-devel] add a server
Hello Pat,
I think it's a good idea, something we're considering for the next release.
James
- Original Message -
From: "Patrice DUMAS - DOCT"
To:
Sent: Friday, June 21, 2002 12:01 PM
Subject: [Openvpn-devel] add a server
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" <audiopoppi...@audioriders.fi>
To: <sampo.nurment...@audioriders.fi>
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" <audiopoppi...@audioriders.fi>
To: <sampo.nurment...@audioriders.fi>
> 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
> 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
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
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
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
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
> > * 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:
>
> ---
> > * 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:
>
> ---
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).
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).
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
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
> 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:
> 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:
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
401 - 468 of 468 matches
Mail list logo