OpenVPN

Hello!

> Thu Sep 16 16:28:53 2004 PUSH: Received control message:
> 'PUSH_REPLY,route-method exe,route 128.100.0.0 255.255.0.0,route
> 142.151.0.0 255.255.0.0,route 142.150.0.0 255.255.0.0,route
> 128.100.56.140 255.255.255.255 net_gateway,inactive 120,route
> 142.150.248.1,ifconfig 142.150.248.6 142.150.248.5'
> Thu Sep 16 16:28:53 2004 Options error: Unrecognized option or missing
> parameter(s) in [PUSH-OPTIONS]:1: route-method

> Any ideas?

Something's wrong with your route options. On both plattforms. Just that
on the Linux system OpenVPN goes on whereas it stops on OpenBSD. 
Could you show the config-file of the server?


Jean-Pierre
-- 
Powered by Linux From Scratch - http://schwicky.net/
PGP Key ID: 0xEE6F49B4 - AIM/Jabber: Schwicky - ICQ: 4690141

Nothing is impossible... Everything is relative!

On Thu, 16 Sep 2004, Matt Wilks wrote:

> One other question that comes to mind is how the Windows service can be
> used to successfully open a VPN connection by Joe User (given that he
> has been given the correct permissions), but using one of the GUIs or
> right clicking a config file requires Administrative privileges.

Running OpenVPN does require administrative privs yes.

OpenVPN GUI (http://www.nilings.se/openvpn) can be used to control the 
openvpn service. It will not make the service work better, but it will 
ease starting/stopping the service. (You have to enable this feature by 
changing a registry value, see the homepage for more info.)

I also got the following tips posted on my web forum that might be useful:

Temporarly I've solved creating a shortcut on my non admin user desktop to 
openvpngui select "advanced/use alternative credential".
So I can launch openvpngui after typing the administrato password.
I know about a sofware called Auto-It that can create a launcher that runs 
other programs under a different user without the need to enter the 
password. It encrypts the password in the launcher.

-- 
_________________________________________________________
Mathias Sundman              (^)   ASCII Ribbon Campaign
NILINGS AB                    X    NO HTML/RTF in e-mail
Tel: +46-(0)8-666 32 28      / \   NO Word docs in e-mail

Jens Krause wrote:

>I have a openvpn server at Linux (openvpn-beta11) and openvpn clients with
>beta11 win32. I´m using the tls-auth option on booth sides with a created
>dev/urandam File. When I connect with my window client to the linux, he
>couldnt connect and in the syslog stands follow error:
>
>ovpn-server[2633]: Authenticate/Decrypt packet error: packet HMAC
>authentication failed
>ovpn-server[2633]: TLS Error: incoming packet authentication failed from
>xxx.xxx.xxx:64885
>  
>
try tap  + tcp instead of tun/udp

tony

On Thu, 16 Sep 2004, Jens Krause wrote:

> I have a openvpn server at Linux (openvpn-beta11) and openvpn clients wit=
h
> beta11 win32. I=B4m using the tls-auth option on booth sides with a creat=
ed
> dev/urandam File. When I connect with my window client to the linux, he
> couldnt connect and in the syslog stands follow error:
>=20
> ovpn-server[2633]: Authenticate/Decrypt packet error: packet HMAC
> authentication failed
> ovpn-server[2633]: TLS Error: incoming packet authentication failed from
> xxx.xxx.xxx:64885
> ovpn-server[2633]: Authenticate/Decrypt packet error: packet HMAC
> authentication failed
> ovpn-server[2633]: TLS Error: incoming packet authentication failed from
> xxx.xxx.xxx:64885
> ovpn-server[2633]: Authenticate/Decrypt packet error: packet HMAC
> authentication failed
> and so on
>=20
> But when I use a OpenVPN Linux Client it works! Is this a Bug at the
> openvpn beta11 Windows Version?

It's best to use an OpenVPN static key file as the tls-auth key, rather=20
than creating it directly from /dev/*random.  The advantage of this is=20
that it sidesteps some issues with <CR><LF> interpretation on linux vs.=20
windows and it also allows you to use the tls-auth direction parameter for=
=20
bidirectional security.

You can generate the key file ("key") like this:

  openvpn --genkey --secret key

Make sure to use the same key file on the server and all clients.

James

Jens,

Probably not.  I was having the same problem, then I opened the key with =

a text editor to find out that I had different keys.  Check that they 
are the same key.  I created the tls-auth file using openvpn --genkey 
--secret static.key

And, then used the same key on both ends.

Doug


Jens Krause wrote:

>I have a openvpn server at Linux (openvpn-beta11) and openvpn clients wi=
th
>beta11 win32. I=B4m using the tls-auth option on booth sides with a crea=
ted
>dev/urandam File. When I connect with my window client to the linux, he
>couldnt connect and in the syslog stands follow error:
>
>ovpn-server[2633]: Authenticate/Decrypt packet error: packet HMAC
>authentication failed
>ovpn-server[2633]: TLS Error: incoming packet authentication failed from=

>xxx.xxx.xxx:64885
>ovpn-server[2633]: Authenticate/Decrypt packet error: packet HMAC
>authentication failed
>
>  
>

I'm not 100 percent positive, but it sound like you are blocking
everything to the Ethernet address.    You need to open up the
Ethernet address enough to allow OpenVPN to create the tunnel (usually
UDP 5000).  Without this open the tunnel will never initialize a
tunnel as the physical interface has to be available to bring the
virtual OpenVPN interface up.


On Thu, 16 Sep 2004 14:13:40 +1200, Jason Haar <jason.haar@...> wrote:
> On Tue, Sep 14, 2004 at 08:33:29AM -0600, James Yonan wrote:
> > Try the "untrusted_ip" environmental variable to get the client's IP
> > address within the tls-verify script.
> 
> But that's the "Internet" address - the firewall config on the client will
> block that...
> 
> What I'm wanting is to be able to connect to the TUN interfaces - but it
> appears something in OpenVPN specifically disables connecting to them? (from
> server to client)
> 
> My VPN client machines have netfilters to protect "eth+", but have "tun+"
> wide open. Unfortunately I can't get to TUN interfaces via OpenVPN by the
> looks of it :-(
> 
> --
> Cheers
> 
> Jason Haar
> Information Security Manager, Trimble Navigation Ltd.
> Phone: +64 3 9635 377 Fax: +64 3 9635 417
> PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 



-- 
Leonard Isham, CISSP 
Ostendo non ostento.

> On Tue, Sep 14, 2004 at 08:33:29AM -0600, James Yonan wrote:
> > Try the "untrusted_ip" environmental variable to get the client's IP
> > 
> > address within the tls-verify script.
> 
> But that's the "Internet" address - the firewall config on the client
> will block that...
> 
> What I'm wanting is to be able to connect to the TUN interfaces - but
> it appears something in OpenVPN specifically disables connecting to
> them? (from server to client)

If you want to do that, then the tunnel needs to be up already. But what
you want (from what I understood) is to use the connection back to the
client to authorize the connecting client to even build the tunnel. This
can't work. You certainly can use the ./up script to connect through the
tunnel back to the client, but then the tunnel will be up. And a given
user which should not be authorized could simply drop the packets back
to its ssh-daemon and use this time until the timeout to do malicious
stuff. Or even worse, use port-forwarding to forward your
ssh-session to another machine and make you believe his machine has the
good version of the OS.




Jean-Pierre

-- 
Powered by Linux From Scratch - http://schwicky.net/
PGP Key ID: 0xEE6F49B4 - AIM/Jabber: Schwicky - ICQ: 4690141

Nothing is impossible... Everything is relative!

On Thu, Sep 16, 2004 at 11:44:52AM +0200, Jean-Pierre Schwickerath wrote:
> If you want to do that, then the tunnel needs to be up already. But what
> you want (from what I understood) is to use the connection back to the
> client to authorize the connecting client to even build the tunnel. This
> can't work. You certainly can use the ./up script to connect through the
> tunnel back to the client, but then the tunnel will be up. And a given

Actually that doesn't seem to work either. I am typing this over a OpeNVPN
tunnel now, and yet (from the server) I cannot ping the IP address assigned
to the client's TUN interface.

Is that meant to be?


> user which should not be authorized could simply drop the packets back
> to its ssh-daemon and use this time until the timeout to do malicious
> stuff. Or even worse, use port-forwarding to forward your
> ssh-session to another machine and make you believe his machine has the
> good version of the OS.

Well that's why there's a market for closed-source VPN, isn't it? "The
hacker doesn't know how to work around the controls" (yeah, right ;-). The
trouble with any Open Source version of this is that the client could work
around it. I'm not concerned about it - I'm doing this for the excercise -
I'm not looking at protecting a bank with it or anything! :-)

Anyway, if a hacker could manage to get a successful tunnel up (and that
includes knowing the password protecting the cert), then it almost
invariably means they control the PC - so they don't need to "fake" anything
- the machine they're on is going to be valid anayway...

The hard part would be getting a working OpenVPN tunnel up - not faking OSes.

I see Network Admission Control as primarily a quality assurance method. It
sets the bar for PCs to be above before being able to connect. As far as
being authorised - well - that was OpenVPN's job...

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

On Thu, 16 Sep 2004, Jean-Pierre Schwickerath wrote:

> 
> > On Tue, Sep 14, 2004 at 08:33:29AM -0600, James Yonan wrote:
> > > Try the "untrusted_ip" environmental variable to get the client's IP
> > > 
> > > address within the tls-verify script.
> > 
> > But that's the "Internet" address - the firewall config on the client
> > will block that...
> > 
> > What I'm wanting is to be able to connect to the TUN interfaces - but
> > it appears something in OpenVPN specifically disables connecting to
> > them? (from server to client)
> 
> If you want to do that, then the tunnel needs to be up already. But what
> you want (from what I understood) is to use the connection back to the
> client to authorize the connecting client to even build the tunnel. This
> can't work. You certainly can use the ./up script to connect through the
> tunnel back to the client, but then the tunnel will be up. And a given
> user which should not be authorized could simply drop the packets back
> to its ssh-daemon and use this time until the timeout to do malicious
> stuff. Or even worse, use port-forwarding to forward your
> ssh-session to another machine and make you believe his machine has the
> good version of the OS.

The only point where a custom script can veto the TLS authentication 
process is in the tls-verify script.  And by definition, when this script 
runs, authentication hasn't occurred yet.  So if you want to probe the 
connecting machine from the tls-verify script, it needs to be done over a 
non-OpenVPN channel.

James

On Thu, 16 Sep 2004, Vinayak Royadu wrote:

> Hi,
> Does OpenVPN supports windows 98/NT clients?
> Has anybody implemented it?

No, and it probably never will because the TAP driver would have to be 
rewritten significantly. Search the list archive for more info on this 
issue.

-- 
_________________________________________________________
Mathias Sundman              (^)   ASCII Ribbon Campaign
NILINGS AB                    X    NO HTML/RTF in e-mail
Tel: +46-(0)8-666 32 28      / \   NO Word docs in e-mail

On 16/09/2004 14:49, Mathias Sundman wrote:
> On Thu, 16 Sep 2004, Vinayak Royadu wrote:
> > Hi,
> > Does OpenVPN supports windows 98/NT clients?
> > Has anybody implemented it?
>
> No, and it probably never will because the TAP driver would have to be
> rewritten significantly. Search the list archive for more info on this
> issue.

On this topic, are there any PDA (SybianOS) or WindowsCE clients available? If 
not what is the likelyhood of there ever being?

Paulo

On Wed, 15 Sep 2004, Bradley Alexander wrote:

> On Tuesday 14 September 2004 10:29, James Yonan wrote:
> > It does sound like a classic MTU problem.
> >
> > Try something like this on both sides of the connection:
> >
> >   tun-mtu 1500
> >   tun-mtu-extra 32
> >   mssfix 1450
> >
> > I am assuming you are using 1.x.  If you are using 2.0, the above settings
> > are the default.  If you are still having difficulties, try reducing the
> > mssfix value.
> 
> I tried this today, and got the same result. The connection within the tunnel 
> still hangs, for instance, I tried an ls -l of my home directory (600+ 
> items), and got something similar to:
> 
> [storm@... ~]$ ls -l
> total 545266
> -rw-------   1 storm storm   815254 Aug 24 17:19 100_0030.JPG
> -rw-r--r--   1 storm storm    62866 Jan  6  2002 10_ckpit.dat
> -rw-r--r--   1 storm storm    45
> 
> And then the session hung. I was sshed through the tunnel. I also tried 
> dropping the mssfix and fragment values to 1400. Unfortunately, I only had 
> limited time to play with this today, since I had a meeting in downtown DC. 
> I'm going to make sure time is synced and run tcpdumps across the 
> tunnel...One at the firewall, one on the laptop and one on the target 
> machine. Not sure how much its going to show me, especially on the firewall, 
> since the traffic will be encrypted, but it may show me which direction is 
> getting hung.
> 
> Are there changes in the 2.0 betas that might address this problem? Should I 
> try that on both tunnel ends?

It's worth a try.  I would also try using a smaller mssfix value.  Try 
something low like 1200.
 
James