openvpn-devel — OpenVPN developers list

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

[Farkas L. <lf...@bn...>]

Mathias Sundman wrote:
> Hi!
>=20
>  > we use our linux vpn gateway and some win2000 road warrior clients w=
ith
>  > openvpn. I would like to route all internet traffic trough our firew=
all
>  > from the windows clients.
>=20
>  I=B4ve been thinking about doing this too, but never accually tried it=
.
>=20
>  What you basicly need to do is:
>=20
>  1. Don=B4t set a default gateway on your ethernet adapter.

you have to set otherwise the vpn connection can't estabilished.

>  2. Add a route to your openvpn server with a /32 mask pointing to the
>     gateway on your ethernet.
>=20
>     In your exampel this would be done with the following command on
>     Win2K where w.x.y.z is the IP of your remote openvpn server,
>     and a.b.c.254 is your local gateway.
>=20
>     ROUTE ADD w.x.y.z MASK 255.255.255.255 a.b.c.254
>=20
>  3. Setup OpenVPN as usual but also add a default gateway route to
>     the TAP interface.
>=20
>=20
>  The reason why I havn=B4t tried this is because I don=B4t know how to =
solve
>  the problem that the ROUTE command will be diffrent for each network y=
ou
>  hook your laptop into. So if you don=B4t want to manually do this ever=
y
>  time, you would need to write a little app that looks at the IP and
>  default gateway that has been assigned by DHCP, switch to static IP an=
d
>  add the correct route.
>=20
>  Anyone that has a better solution to this?

you see exactly the problem!
on linux I can do (eg. in the up script):
----------------------------------
route add -host <remote-server-ip> dev ppp0
route del default dev ppp0
route add default dev tun0
----------------------------------
and we got it, but unfotunately on windows you can't route by interface=20
(or to be more precise on windos the interface is defined by it's ip=20
address even if you can specify the interface).
so I'd like to suggest a new option for openvpn to be portable (like in=20
the case of --route):
--route-internal
   which do exactly as the above on all platform.
since openvpn know whcih ip address has the under the tun/tap interface.
or may it would be more better if the up script has one more (6th)=20
paramter and the underlying interface's ip address:
-----------------------------------
cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip=20
underlying_ip [ init | restart ]
cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask=20
underlying_ip [ init | restart ]
-----------------------------------
and in this case on linux we cn write an up script as:
----------------------------------
route add -host $5 dev ppp0
route del default dev ppp0
route add default dev tun0
----------------------------------
while on windows
----------------------------------
route add $5 gw $6
route delete 0.0.0.0 mask 0.0.0.0 $5
route add 0.0.0.0 mask 0.0.0.0 $4
----------------------------------
does it possible? or any better solution?

--=20
   Levente                               "Si vis pacem para bellum!"

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

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

Teemu Kiviniemi <te...@ik...> said:

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

Cool -- I merged it.

James

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

[Teemu K. <te...@ik...>]

Wed, 29-10-2003 at 23:38, James Yonan wrote:

> I would rather see this fix accomplished by adding some kind of dummy cal=
l
> early on in the initialization sequence to trigger the dynamic load of th=
e DNS
> library -- but which doesn't touch the functionality of the current DNS n=
ame
> resolution code.

Hi,

I made a new patch. This time the name lookup is done in openvpn.c if
options->remote is set, just before entering the chroot jail.

http://iki.fi/teemuki/openvpn/cvs-resolvfix2.diff
The patch is against the current CVS version.

Teemu

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

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

Teemu Kiviniemi <te...@ik...> said:

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

Teemu,

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

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

James

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

[Teemu K. <te...@ik...>]

Hi,

OpenVPN 1.5beta12 and the CVS version have a problem when --resolv-retry
and --chroot are used at the same time. In chroot environment,
gethostbyname() can't resolve the remote IP address:

Wed Oct 29 17:19:17 2003 13: RESOLVE: Cannot resolve host address:
somehost.somedomain: [unknown h_errno value]

This problem occurs with Debian Woody. I think it's related to the Glibc
dynamic loader. If the name resolver libraries aren't loaded before
OpenVPN enters the chroot jail, OpenVPN can't do any DNS queries. If
gethostbyname() is run before entering chroot(), the resolver libraries
are loaded and everything works as it should.

I changed link_socket_init_phase1() in socket.c to resolve the remote
host even if resolve_retry_seconds is set. That way, gethostbyname() is
run before chroot(). I don't know if that's the right way to do it, but
it fixes the problem for me.

The patch for 1.5 beta12 and the CVS version is available at:
http://iki.fi/teemuki/openvpn/openvpn-resolvfix.diff

Teemu

Re: [Openvpn-devel] --tls-cipher documentation bug

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

Teemu,

Thanks for the --tls-remote and --tls-cipher patches.  I've merged them and
they will be included in the next 1.5 beta release.

James

Teemu Kiviniemi <te...@ik...> said:

> Hi,
> 
> I think I found a bug in the openvpn(8) man page:
> 
> > --tls-cipher l
> >     A  list  l  of allowable TLS ciphers separated by |
> 
> When I use the character '|' to separate the ciphers, OpenSSL complains.
> The correct format is described in the ciphers(1) man page:
> 
> > CIPHER LIST FORMAT
> > The cipher list consists of one or more cipher strings separated
> > by colons.  Commas or spaces are also acceptable separators but colons
> > are normally used.
> 
> I changed '|' to be ':'. The patch is available at:
> http://iki.fi/teemuki/openvpn/cvs-docfix.diff
> 
> The patch is against EXP15 CVS branch with my cvs-tlsremote.diff merged.
> The patch changes also the help text in options.c.
> 
> Teemu
> 
> 



-- 

[Openvpn-devel] --tls-cipher documentation bug

[Teemu K. <te...@ik...>]

Hi,

I think I found a bug in the openvpn(8) man page:

> --tls-cipher l
>     A  list  l  of allowable TLS ciphers separated by |

When I use the character '|' to separate the ciphers, OpenSSL complains.
The correct format is described in the ciphers(1) man page:

> CIPHER LIST FORMAT
> The cipher list consists of one or more cipher strings separated
> by colons.  Commas or spaces are also acceptable separators but colons
> are normally used.

I changed '|' to be ':'. The patch is available at:
http://iki.fi/teemuki/openvpn/cvs-docfix.diff

The patch is against EXP15 CVS branch with my cvs-tlsremote.diff merged.
The patch changes also the help text in options.c.

Teemu

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

[Teemu K. <te...@ik...>]

Mon, 27-10-2003 at 22:49, James Yonan wrote:

> One thing that would help me to merge it more easily, is if you could rec=
ode
> against the current CVS which has advanced since beta12 and includes the

Hi,

I rewrote the patch against the EXP15 branch in CVS. I tested it briefly
and it worked just fine. The patch is available at:
http://iki.fi/teemuki/openvpn/cvs-tlsremote.diff

Teemu

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

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

Teemu Kiviniemi <te...@ik...> said:

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

Thanks, that looks like a useful patch.

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

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

James

[Openvpn-devel] Splitting functionality of VPN daemons

[Guus S. <gu...@sl...>]

Hello,

Today there are lots of VPN implementations, each having their strengths
and weaknesses. In particular, OpenVPN has focussed on creating tunnels
using standards such as SSL/TLS and ESP and provides better security
than many other VPN implementations. Tinc on the other hand is probably
the only VPN daemon that handles multiple tunnels on one tun/tap device,
using built-in routing. In order to allow both projects (and maybe
others) to combine their efforts in a manageable way, their should be a
standardised API, so that code can be reused without having to change it.
You can find a concept here:

http://sliepen.eu.org/~guus/vpnsplit.html

This is by no means finished, your input is greatly appreciated.

--=20
Met vriendelijke groet / with kind regards,
    Guus Sliepen <gu...@sl...>

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

[Teemu K. <te...@ik...>]

Hi,

I ran into problems in using --tls-verify to verify the remote host with
--chroot enabled. --tls-verify runs the verify script with system()
command, so it assumes that /bin/sh is available. Usually, in a chroot
environment, that's not true.

I implemented a new config option: --tls-remote x509name

With --tls-remote the remote host is verified by looking at the X509
name. If the remote X509 name doesn't match the given x509name, the
remote host is rejected.

With --tls-remote, it's possible to verify remote host even with a
completely empty chroot directory. --tls-remote also removes the need
for an external --tls-verify script in most cases.

Config example:
tls-remote /O=3Dexampleorg/CN=3Dname

I have tested the patch with a TLS tunnel on Debian Woody.

A patch against OpenVPN 1.5 beta12 is available at:
http://iki.fi/teemuki/openvpn/1.5_beta12-tlsremote.diff

Feel free to use it. :)

Teemu

[Openvpn-devel] tcp vpn

[Julien T. <jul...@ly...>]

Hello

i've setup a vpn between
linux 2.4 <-> winxp (1.5b12 both)
tcp-server -  tcp-client

works well
but it seems that when the client stops, the server died

Sun Oct 26 18:53:50 2003 0: OpenVPN 1.5_beta12 i586-pc-linux-gnu [SSL]
[LZO] built on Oct 14 2003
Sun Oct 26 18:53:50 2003 1: Static Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
Sun Oct 26 18:53:50 2003 2: Static Encrypt: Using 160 bit message digest
'SHA1' for HMAC authentication
Sun Oct 26 18:53:50 2003 3: Static Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
Sun Oct 26 18:53:50 2003 4: Static Decrypt: Using 160 bit message digest
'SHA1' for HMAC authentication
Sun Oct 26 18:53:50 2003 5: LZO compression initialized
Sun Oct 26 18:53:50 2003 6: TUN/TAP device tun9 opened
Sun Oct 26 18:53:50 2003 7: /sbin/ifconfig tun9 10.0.2.5 pointopoint
10.0.2.6 mtu 1500
Sun Oct 26 18:53:50 2003 8: Data Channel MTU parms [ L:1547 D:1547 EF:47
EB:19 ET:0 ]
Sun Oct 26 18:53:50 2003 9: Local Options hash (VER=V3): '282853c2'
Sun Oct 26 18:53:50 2003 10: Expected Remote Options hash (VER=V3):
'30cfa287'
Sun Oct 26 18:53:50 2003 11: GID set to nogroup
Sun Oct 26 18:53:50 2003 12: UID set to nobody
Sun Oct 26 18:53:50 2003 13: Listening for incoming TCP connection on
[undef]:16889
Sun Oct 26 18:53:51 2003 14: TCP connection established with
129.129.200.79:2873
Sun Oct 26 18:53:51 2003 15: TCPv4_SERVER link local (bound): [undef]:16889
Sun Oct 26 18:53:51 2003 16: TCPv4_SERVER link remote: 129.129.200.79:2873
Sun Oct 26 18:53:51 2003 17: Peer Connection Initiated with
129.129.200.79:2873
Sun Oct 26 18:54:20 2003 18: Connection reset, restarting [-1]
Sun Oct 26 18:54:20 2003 19: Closing TCP/UDP socket
Sun Oct 26 18:54:20 2003 20: Closing TUN/TAP device
Sun Oct 26 18:54:20 2003 21: OpenVPN 1.5_beta12 i586-pc-linux-gnu [SSL]
[LZO] built on Oct 14 2003
Sun Oct 26 18:54:20 2003 22: Static Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
Sun Oct 26 18:54:20 2003 23: Static Encrypt: Using 160 bit message
digest 'SHA1' for HMAC authentication
Sun Oct 26 18:54:20 2003 24: Static Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
Sun Oct 26 18:54:20 2003 25: Static Decrypt: Using 160 bit message
digest 'SHA1' for HMAC authentication
Sun Oct 26 18:54:20 2003 26: LZO compression initialized
Sun Oct 26 18:54:20 2003 27: Note: Cannot open TUN/TAP dev /dev/net/tun:
Permission denied (errno=13)
Sun Oct 26 18:54:20 2003 28: Note: Attempting fallback to kernel 2.2
TUN/TAP interface
Sun Oct 26 18:54:20 2003 29: Cannot open TUN/TAP dev /dev/tun9: No such
file or directory (errno=2)
Sun Oct 26 18:54:20 2003 30: Exiting


nothing have changed, and i need to reboot openvpn at hand.
and it works
ideas ?

one side question, multiple route are supported in config file, right ?

regards

		Julien

note: i have also test a link with udp but i get this
Sun Oct 26 16:48:13 2003 119: UDPv4 link local (bound): [undef]:16889
Sun Oct 26 16:48:13 2003 120: UDPv4 link remote: 129.129.200.79:16889
WWWWWWWWRSun Oct 26 16:49:31 2003 121: Peer Connection Initiated with
129.129.200.79:16889
WRWWRWWRWWRWSun Oct 26 16:50:13 2003 122: NOTE: failed to obtain options
consistency info from peer -- this could occur if the remote peer is
running a version of OpenVPN before 1.5-beta8 or if there is a network
connectivity problem, and will not necessarily prevent OpenVPN from
running (300 bytes received from peer, 84 bytes authenticated data
channel traffic) -- you can disable the options consistency check with
--disable-occ.
RWRWrWrWRWRwrWRwrWRWrWRwrWRwrWRWRWRWRWRWR

and ping doesn't work.

[Openvpn-devel] RE: OpenVPN and Windows

[Noam R. <no...@be...>]

Hi,

I was able to compile the OpenVPN under the Visual C++ environment it
required some changes
1) I need to change
#define OPENVPN_S_ERROR          -1
#define OPENVPN_S_UNDEF           0
#define OPENVPN_S_INITIAL         1	/* tls_init() was called */
#define OPENVPN_S_PRE_START       2	/* waiting for initial reset &
acknowledgement */
#define OPENVPN_S_START           3	/* ready to exchange keys */
#define OPENVPN_S_SENT_KEY        4	/* client does S_SENT_KEY ->
S_GOT_KEY */
#define OPENVPN_S_GOT_KEY         5	/* server does S_GOT_KEY ->
S_SENT_KEY */
#define OPENVPN_S_ACTIVE          6	/* ready to exchange data channel
packets */
#define OPENVPN_S_NORMAL          7	/* normal operations */

Instead of those that are currently in place, as S_NORMAL already exist =
as
an MFC #define.

2) And:
  fd =3D open (filename, O_CREAT | O_TRUNC | O_WRONLY
#ifndef _WINDOWS	=09
		, S_IRUSR | S_IWUSR
#endif
		);

Instead of what it is currently, as S_IRUSR and S_IWUSR do not exist, =
nor is
there a permission problem for file descriptors, if you request a =
O_WRONLY,
you will fail if you cannot write to it due to permission errors.

3) Also inside config-win32.h I did:
#ifndef _WINDOWS
#include <windows.h>
#endif

As windows.h is the console include, and when building an MFC =
environment it
is not needed.

4) And last but not least I created an MFC.h file to include all the =
things
I needed:
#ifndef MFC_H
#define MFC_H

#undef TIME_WITH_SYS_TIME
#undef HAVE_SYS_TIME_H
#undef HAVE_SYS_FILE_H
#undef HAVE_STDINT_H
#undef HAVE_UNISTD_H

#include <stdio.h>
#include <io.h>
#include <direct.h>
#include <openssl/err.h>

#define vsnprintf _vsnprintf
#define snwprintf _snwprintf=20

#ifdef _WINDOWS
 InternalMsg (flags, ...);
#endif

#endif

5) And replaced in error.h:
#ifdef _WINDOWS
	#define msg InternalMsg
#else
 #if defined(HAVE_CPP_VARARG_MACRO_ISO) && !defined(__LCLINT__)
 #define HAVE_VARARG_MACROS
 #define msg(flags, ...) do { if (MSG_TEST(flags)) x_msg((flags),
__VA_ARGS__); } while (false)
 #elif defined(HAVE_CPP_VARARG_MACRO_GCC) && !defined(__LCLINT__)
 #define HAVE_VARARG_MACROS
 #define msg(flags, args...) do { if (MSG_TEST(flags)) x_msg((flags), =
args);
} while (false)
 #else
 #warning this compiler appears to lack vararg macros which will cause a
significant degradation in efficiency (you can ignore this warning if =
you
are using LCLINT)
 #define msg x_msg
 #endif
#endif

As Visual C++ does not support any unnumbered variable in Macros
(InternalMsg is a wrapper). This is the only problem BTW, I cannot make =
the
InternalMsg behave correctly as the msg macro does, as I cannot properly
parse the values passes to the InternalMsg function.

The only solution that appears to be the valid one at the moment is
replacing the msg calls, with msg0, msg1, msg2, msg3, etc instead of a
single unnumber msg call (this is how Microsoft's Debugging functions =
work).

I also attached a short txt explaining how to compile.

Any help / comments  will be greatly appreciated.
Thanks
Noam Rathaus
CTO
Beyond Security Ltd.
http://www.securiteam.com=20

-----Original Message-----
From: James Yonan [mailto:ji...@yo...]=20
Sent: Sunday, October 19, 2003 20:51
To: Noam Rathaus
Subject: Re: OpenVPN and Windows


Noam,

I don't use Visual C++, but I've posted your message to the =
openvpn-devel
list.

James

Noam Rathaus <no...@be...> said:

> Hi,
>=20
> I am sorry for contacting you directly, but I tried posting to the=20
> Mailing
list multiple times, but I wasn't able to get through (even though I am =
able
to receive the mailing, so I am subscribed), this is the email I tried =
to
post into the list.
>=20
> =3D=3D=3D=3D=3D
>=20
> I have been trying for a few hours now to get my Visual C++ to compile =

> the
OpenVPN user mode client, but without any luck, I would be happy to hear
from someone who was able to, or has an idea how to do it.
>=20
> I have MinGW, MSYS, GCC, etc installed, but I want to create an Open=20
> Source
MFC GUI for the client, as opposed to the console one.
>=20
> =3D=3D=3D=3D=3D
>=20
> Thanks
> Noam Rathaus
> CTO
> Beyond Security Ltd.
> http://www.securiteam.com
>=20
>=20



--=20

Re: [Openvpn-devel] Visual C++ Compiling

[Stefano B. <st...@pr...>]

On Sun, Oct 19, 2003 at 02:31:55PM +0200, Noam Rathaus wrote:
> Hi,
> 
> I have been trying for a few hours now to get my Visual C++ to compile the OpenVPN user mode client, but without any luck, I would be happy to hear from someone who was able to, or has an idea how to do it.
> 
> I have MinGW, MSYS, GCC, etc installed, but I want to create an Open Source MFC GUI for the client, as opposed to the console one.

I can't help about Visual C++ because i don't use that, but why don't create a gui using free libs like gtk? Besides
we'll have a multiplatform interface ;)

Stefano

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

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

Peter Sandström <pe...@ph...> said:

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

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

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

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

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

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

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

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

James

Re: [Openvpn-devel] Re: unix - windows interop (shared secret whitespace problem)

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

Adam Laurie <ad...@al...> said:

> 
> >> this was just a quick note to request that you do some whitespace foo 
> >  > (in particular CR/LF stuff) for the openvpn generated secret files as 
> >  > this seems to cause pain when setting up keys generated by one or other 
> >  > platform and then transferring them (my test platform was win2k -> 
> >  > freebsd-4.8).
> >  
> >  Not sure what the problem is.
> >  
> >  If you generate a static key on Windows, you will get CR-LF line termination.
> >   If you generate on *nix, you will get LF-only (i.e. newline) termination. 
> >  Each platform generates interoperable keys.  The only strange behaviour I
> >  noticed is if you generate a key on Linux then try to edit it with a dumb
> >  editor on windows (such as Notepad), it doesn't "get" the line termination
> >  right.  But OpenVPN will still read the key correctly, as the key reader is
> >  mostly whitespace independent.
> 
> ok, then the problem is that it's not working as expected. in trhis case 
> the key was generated on the win2k side and placed on the bsd server. 
> tls-auth failed. after editing with vi and removing ^M characters from 
> end of each line, tls-auth passed.
> 
> btw, when i tested with win-xp and a key generated on the bsd side i had 
> no problem, so i have seen it working as described as well, but on a 
> different platform.

Right, tls-auth generates the key by taking the sha1sum of the file, so it
will definitely be influenced by whitespace and newline conventions.  When you
said "openvpn generated secret files" I was thinking you were talking about
--genkey and static keys, which are not whitespace dependent.

James

Re: [Openvpn-devel] Re: unix - windows interop (shared secret whitespace problem)

[Adam L. <ad...@al...>]

James Yonan wrote:
> Adam Laurie <ad...@al...> said:
> 
> 
>>>>this was just a quick note to request that you do some whitespace foo 
>>>
>>> > (in particular CR/LF stuff) for the openvpn generated secret files as 
>>> > this seems to cause pain when setting up keys generated by one or other 
>>> > platform and then transferring them (my test platform was win2k -> 
>>> > freebsd-4.8).
>>> 
>>> Not sure what the problem is.
>>> 
>>> If you generate a static key on Windows, you will get CR-LF line termination.
>>>  If you generate on *nix, you will get LF-only (i.e. newline) termination. 
>>> Each platform generates interoperable keys.  The only strange behaviour I
>>> noticed is if you generate a key on Linux then try to edit it with a dumb
>>> editor on windows (such as Notepad), it doesn't "get" the line termination
>>> right.  But OpenVPN will still read the key correctly, as the key reader is
>>> mostly whitespace independent.
>>
>>ok, then the problem is that it's not working as expected. in trhis case 
>>the key was generated on the win2k side and placed on the bsd server. 
>>tls-auth failed. after editing with vi and removing ^M characters from 
>>end of each line, tls-auth passed.
>>
>>btw, when i tested with win-xp and a key generated on the bsd side i had 
>>no problem, so i have seen it working as described as well, but on a 
>>different platform.
> 
> 
> Right, tls-auth generates the key by taking the sha1sum of the file, so it
> will definitely be influenced by whitespace and newline conventions.  When you
> said "openvpn generated secret files" I was thinking you were talking about
> --genkey and static keys, which are not whitespace dependent.

yes, i was... the file i'm specifying to tls-auth is the original 
--genkey file that i used as a shared secret for initial testing. i 
guess that it's really meant to be a one-liner then?

cheers,
Adam
-- 
Adam Laurie                   Tel: +44 (20) 8742 0755
A.L. Digital Ltd.             Fax: +44 (20) 8742 5995
The Stores                    http://www.thebunker.net
2 Bath Road                   http://www.aldigital.co.uk
London W4 1LT                 mailto:ad...@al...
UNITED KINGDOM                PGP key on keyservers

[Openvpn-devel] Re: unix - windows interop (shared secret whitespace problem)

[Adam L. <ad...@al...>]

>> this was just a quick note to request that you do some whitespace foo 
>  > (in particular CR/LF stuff) for the openvpn generated secret files as 
>  > this seems to cause pain when setting up keys generated by one or other 
>  > platform and then transferring them (my test platform was win2k -> 
>  > freebsd-4.8).
>  
>  Not sure what the problem is.
>  
>  If you generate a static key on Windows, you will get CR-LF line termination.
>   If you generate on *nix, you will get LF-only (i.e. newline) termination. 
>  Each platform generates interoperable keys.  The only strange behaviour I
>  noticed is if you generate a key on Linux then try to edit it with a dumb
>  editor on windows (such as Notepad), it doesn't "get" the line termination
>  right.  But OpenVPN will still read the key correctly, as the key reader is
>  mostly whitespace independent.

ok, then the problem is that it's not working as expected. in trhis case 
the key was generated on the win2k side and placed on the bsd server. 
tls-auth failed. after editing with vi and removing ^M characters from 
end of each line, tls-auth passed.

btw, when i tested with win-xp and a key generated on the bsd side i had 
no problem, so i have seen it working as described as well, but on a 
different platform.

cheers,
Adam
-- 
Adam Laurie                   Tel: +44 (20) 8742 0755
A.L. Digital Ltd.             Fax: +44 (20) 8742 5995
The Stores                    http://www.thebunker.net
2 Bath Road                   http://www.aldigital.co.uk
London W4 1LT                 mailto:ad...@al...
UNITED KINGDOM                PGP key on keyservers

Re: [Openvpn-devel] unix - windows interop (shared secret whitespace problem)

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

Adam Laurie <ad...@al...> said:

> hi,
> 
> first off, props for openvpn, and in particular for releasing the 
> windows version... you ended 3 weeks of windows - unix vpn misery that 
> was making my life hell! thanks a milion guys! :)

Cool.

> this was just a quick note to request that you do some whitespace foo 
> (in particular CR/LF stuff) for the openvpn generated secret files as 
> this seems to cause pain when setting up keys generated by one or other 
> platform and then transferring them (my test platform was win2k -> 
> freebsd-4.8).

Not sure what the problem is.

If you generate a static key on Windows, you will get CR-LF line termination.
 If you generate on *nix, you will get LF-only (i.e. newline) termination. 
Each platform generates interoperable keys.  The only strange behaviour I
noticed is if you generate a key on Linux then try to edit it with a dumb
editor on windows (such as Notepad), it doesn't "get" the line termination
right.  But OpenVPN will still read the key correctly, as the key reader is
mostly whitespace independent.

James

[Openvpn-devel] unix - windows interop (shared secret whitespace problem)

[Adam L. <ad...@al...>]

hi,

first off, props for openvpn, and in particular for releasing the 
windows version... you ended 3 weeks of windows - unix vpn misery that 
was making my life hell! thanks a milion guys! :)

this was just a quick note to request that you do some whitespace foo 
(in particular CR/LF stuff) for the openvpn generated secret files as 
this seems to cause pain when setting up keys generated by one or other 
platform and then transferring them (my test platform was win2k -> 
freebsd-4.8).

cheers,
Adam
-- 
Adam Laurie                   Tel: +44 (20) 8742 0755
A.L. Digital Ltd.             Fax: +44 (20) 8742 5995
The Stores                    http://www.thebunker.net
2 Bath Road                   http://www.aldigital.co.uk
London W4 1LT                 mailto:ad...@al...
UNITED KINGDOM                PGP key on keyservers

[Openvpn-devel] Fwd: OpenVPN and Windows

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

Forwarded From: Noam Rathaus <no...@be...>

> =====
> 
> I have been trying for a few hours now to get my Visual C++ to compile the
OpenVPN user mode client, but without any luck, I would be happy to hear from
someone who was able to, or has an idea how to do it.
> 
> I have MinGW, MSYS, GCC, etc installed, but I want to create an Open Source
MFC GUI for the client, as opposed to the console one.
> 
> =====
> 
> Thanks
> Noam Rathaus
> CTO
> Beyond Security Ltd.
> http://www.securiteam.com 

[Openvpn-devel] Visual C++ Compiling

[Noam R. <no...@be...>]

Hi,

I have been trying for a few hours now to get my Visual C++ to compile =
the OpenVPN user mode client, but without any luck, I would be happy to =
hear from someone who was able to, or has an idea how to do it.

I have MinGW, MSYS, GCC, etc installed, but I want to create an Open =
Source MFC GUI for the client, as opposed to the console one.

Thanks
Noam Rathaus
CTO
Beyond Security Ltd.
http://www.securiteam.com=20

Re: [Openvpn-devel] beta1.5_12 CRL

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

Stefano Bracalenti <ste...@pr...> said:

> If someone is interested, I wrote a little patch for check if a
> certificate is revoked using a crl in PEM format generated from ca.
> I added a --crl-verify "crl.pem" option to specify the crl filename.
> It works for me ;)
> 
> Regards Stefano.

Stefano,

Excellent work!

This feature has been requested several times, so I'm sure it will be
well-received.

James

[Openvpn-devel] beta1.5_12 CRL

[Stefano B. <ste...@pr...>]

If someone is interested, I wrote a little patch for check if a
certificate is revoked using a crl in PEM format generated from ca.
I added a --crl-verify "crl.pem" option to specify the crl filename.
It works for me ;)

Regards Stefano.

[Openvpn-devel] cipher final failed

[Ng S. H. <sh...@cs...>]

Hi all,
    I added one mode to openssl library, called AES-128-HECTR, where the
mode use 128 bits key, and 256 bits block size.
I managed to get it compiled, and run well with following command:

openssl aes-128-hectr -in a -out b -k test
and
openssl aes-128-hectr -d -in b -out c -k test

I have tried a few times, with big files (from 10Mb to 28Mb). and confirmed
that the output file c is identical to a. (using md5sum to verify)
So I should assumed that my implementation should be well.

Now I compiled openvpn with this new openssl library,
(I modified the file crypto.c at line 103, 297, 461 by adding the phase "||
mode==EVP_CIPH_HECTR_MODE")

I managed to start openvpn at both sides.
but when I ping B from A, (similarly ping A from B, A will get the error)
B will get following errors:

95: select returned 1
96: read from UDP returned 148
97: UDP READ from 1.0.0.1:5000:  DATA 34cab7ca f97a40ef c025c5e0 ddc799fc
a8a7fa15 36193882 04cadb4b bad35dc[more...]
98: IP Address OK from 1.0.0.1:5000
99: DECRYPT IV: 36193882 04cadb4b bad35dc0 1e3d8856 78f3b89b 7522e576
91f9d66b 3cdc5910
100: Authenticate/Decrypt packet error: cipher final failed

Appreciate if anyone can let me know what is wrong some where? What is the
possible places go wrong here?
Hope that anyone let me know, so that I can trace it out.

thanks and regards,
SH Ng