OpenVPN Support Forum

Could some one help me with this failure

I am connecting a Windows 7 PC to openvpn running on a Debian linux box, using the 2.2 beta windows client
It connects quite happily - I get a connected notification on the Windows 7 box - but almost immediately the connection drops, and on the linux box the server exits. Has to be restarted
Config and log files follow:

Log file (the log on the windows box looks similar)

Wed Feb 23 12:17:47 2011 OpenVPN 2.1_rc11 powerpc-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Sep 18 2008
Wed Feb 23 12:17:47 2011 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Wed Feb 23 12:17:47 2011 WARNING: file 'keys/sloth/serverkey.key' is group or others accessible
Wed Feb 23 12:17:47 2011 /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted>
Wed Feb 23 12:17:48 2011 WARNING: file 'servers/LinuxServer/ta.key' is group or others accessible
Wed Feb 23 12:17:48 2011 Control Channel Authentication: using 'servers/LinuxServer/ta.key' as a OpenVPN static key file
Wed Feb 23 12:17:48 2011 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Feb 23 12:17:48 2011 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Feb 23 12:17:48 2011 TLS-Auth MTU parms [ L:1539 D:166 EF:66 EB:0 ET:0 EL:0 ]
Wed Feb 23 12:17:48 2011 TUN/TAP device tun0 opened
Wed Feb 23 12:17:48 2011 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Wed Feb 23 12:17:48 2011 Data Channel MTU parms [ L:1539 D:1450 EF:39 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Feb 23 12:17:48 2011 GID set to nogroup
Wed Feb 23 12:17:48 2011 UID set to nobody
Wed Feb 23 12:17:48 2011 UDPv4 link local (bound): [undef]:1194
Wed Feb 23 12:17:48 2011 UDPv4 link remote: [undef]
Wed Feb 23 12:17:48 2011 Initialization Sequence Completed
Wed Feb 23 12:20:11 2011 109.181.121.74:57937 Re-using SSL/TLS context
Wed Feb 23 12:20:11 2011 109.181.121.74:57937 LZO compression initialized
Wed Feb 23 12:20:11 2011 109.181.121.74:57937 Control Channel MTU parms [ L:1539 D:166 EF:66 EB:0 ET:0 EL:0 ]
Wed Feb 23 12:20:11 2011 109.181.121.74:57937 Data Channel MTU parms [ L:1539 D:1450 EF:39 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Feb 23 12:20:11 2011 109.181.121.74:57937 Local Options hash (VER=V4): '2cc7a368'
Wed Feb 23 12:20:11 2011 109.181.121.74:57937 Expected Remote Options hash (VER=V4): 'f8941acb'
Wed Feb 23 12:20:16 2011 109.181.121.74:57937 CRL CHECK OK: /C=UK/ST=England/L=London/O=sloth/emailAddress=server@localhost
Wed Feb 23 12:20:16 2011 109.181.121.74:57937 VERIFY OK: depth=1, /C=UK/ST=England/L=London/O=sloth/emailAddress=server@localhost
Wed Feb 23 12:20:16 2011 109.181.121.74:57937 CRL CHECK OK: /C=UK/ST=England/L=London/O=sloth/OU=Vaio_Notebook/CN=notebook/emailAddress=server@localhost
Wed Feb 23 12:20:16 2011 109.181.121.74:57937 VERIFY OK: depth=0, /C=UK/ST=England/L=London/O=sloth/OU=Vaio_Notebook/CN=notebook/emailAddress=server@localhost
Wed Feb 23 12:20:17 2011 109.181.121.74:57937 Data Channel Encrypt: Cipher 'DES-CFB' initialized with 64 bit key
Wed Feb 23 12:20:17 2011 109.181.121.74:57937 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Feb 23 12:20:17 2011 109.181.121.74:57937 Data Channel Decrypt: Cipher 'DES-CFB' initialized with 64 bit key
Wed Feb 23 12:20:17 2011 109.181.121.74:57937 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Feb 23 12:20:17 2011 109.181.121.74:57937 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Feb 23 12:20:17 2011 109.181.121.74:57937 [notebook] Peer Connection Initiated with 109.181.121.74:57937
Wed Feb 23 12:20:29 2011 notebook/109.181.121.74:57937 Assertion failed at crypto.c:162
Wed Feb 23 12:20:29 2011 notebook/109.181.121.74:57937 Exiting

Server configuration:
port 1194
proto udp
dev tun0
ca keys/sloth/ca.crt
cert keys/sloth/serverkey.crt
key keys/sloth/serverkey.key
dh keys/sloth/dh1024.pem
server 10.8.0.0 255.255.255.0
crl-verify keys/sloth/crl.pem
ifconfig-pool-persist servers/LinuxServer/logs/ipp.txt
tls-auth servers/LinuxServer/ta.key 0
cipher DES-CFB
user nobody
group nogroup
status servers/LinuxServer/logs/openvpn-status.log
log-append servers/LinuxServer/logs/openvpn.log
verb 2
mute 20
max-clients 2
keepalive 10 120
client-config-dir /etc/openvpn/servers/LinuxServer/ccd
tls-server
comp-lzo
persist-key
persist-tun
ccd-exclusive
push "route 192.168.1.0 255.255.255.0"

client configuration (from the linux box)
client
proto udp
dev tun
ca ca.crt
dh dh1024.pem
cert notebook.crt
key notebook.key
remote hoj.dyndns.org 1194
tls-auth ta.key 1
cipher DES-CFB
user nobody
group nogroup
verb 2
mute 20
keepalive 10 120
comp-lzo
persist-key
persist-tun
float
resolv-retry infinite
nobind

you're using a pretty non-standard cipher (DES-CFB). Try using something else, e.g.
AES-256-CBC. OpenVPN works best with Block Ciphers (*-CBC).

You can test whether a cipher works correctly using

Thanks

The trouble seems to be more basic

When I try the test you suggest all I get is "Cannot open file key file 'secret.key': No such file or directory (errno=2)"
Tried any number of ciphers and this is all I get

Can you suggest what to do now; is this the installation or something wrong with the setup of the server (which I did with webmin)?

Steve Hodge

hi there,


as janjust suggested simply edit your server/client config and edit the cipher directive..
then try again..

i guess there is no secret.key file in your config..

cheers,

michael.

sorry, the 'secret.key' was inserted by me because you need *some* sort of secret key in order to run the --test-crypto command.
can you try The 'ta.key' file is listed in your server config so it should be present on the system.

Thanks, that worked. Got a connection now according to the client and the server logs, although it isn't much good. Client can't see the machines on the server's network. Must be something to be do with those 'additional configurations' I guess

hi there,

you need to setup routing on your clients.
let me explain,
you can use the openvpn server as the default gateway..

did you enabled ip forwarding on the vpn linux server?
are you using firewall on the vpn linux server?if yes do you configure it?

cheers,

michael.

Note sure how to go about this.
My server configuration file is quoted below
The open vpn client connects nicely, and I can access the machine that openvpn is running on over the link but nothing else on the network

Do I need to do things on the client machine or the server machine or both??
And what is the significance of the line "server 10.8.0.0 255.255.255.0" I found that if I change this to an address on the servers own subnet everything goes pear shaped, and the server loses all connectivity to its normal subnet

Can anyone point me towards a child's guide to all this

Server config file
port 1194
proto udp
dev tun0
ca keys/sloth/ca.crt
cert keys/sloth/highgateclose.crt
key keys/sloth/highgateclose.key
dh keys/sloth/dh1024.pem
server 10.8.0.0 255.255.255.0
crl-verify keys/sloth/crl.pem
ifconfig-pool-persist servers/HomeVPN/logs/ipp.txt
tls-auth servers/HomeVPN/ta.key 0
cipher AES-256-CBC
user nobody
group nogroup
status servers/HomeVPN/logs/openvpn-status.log
log-append servers/HomeVPN/logs/openvpn.log
verb 2
mute 20
max-clients 2
keepalive 10 120
client-config-dir /etc/openvpn/servers/HomeVPN/ccd
tls-server
comp-lzo
persist-key
persist-tun
ccd-exclusive
push "route 192.168.0.200 255.255.255.0"
push "redirect-gateway"
push "dhcp-option DNS 192.168.254.254"

hi there,

>Do I need to do things on the client machine or the server machine or both??

if you want your client to access your internal lan,only server changes required.

>And what is the significance of the line "server 10.8.0.0 255.255.255.0"

which the above statement you tell openvpn to start a tun interface with ip 10.8.0.1
also openvpn automatically configures your routing table (thats why if you use your lan
address everything is messed up)

so,
if you are using linux on your server you must enable ip forwarding first (this is to tell your os to act as a router)

in redhat/centos/ubuntu you cat do that by changing a value inside /etc/sysctl.conf file from this

net.ipv4.ip_forward = 0

to this

net.ipv4.ip_forward = 1

then you type sysctl -p to activate the changes..
also if you have firewall on ,you have to configure it too..

finally you must setup your lan pcs to route 10.8.0.0/24 subnet through your
openvpn lan ip (using a static route or setting the default gateway on them pointing to your vpn server)


cheers,

michael.

Thanks Michael

Did all this (I think). Debian linux seems to have the same syntax as you describe

The routes on the PCs on the lan should, I guess, point to the IP address of the vpn server (ie 192.168.0.1) not the 10.8.0.1 address for it which openvpn seems to create

But I can still only ping the vpn server itself from the client, not anything else on the LAN

Tried a tracert from the client to a machine on the rest of the LAN. It stopped at the vpn machine having used the 10.8.0.1 address. Tracert to the vpn machine works fine, of course

Can you tell what is wrong from all this??

hi there,

if you enabled ip forwarding and there is no filtering rules on vpn server
it should worked..

try this

goto a pc inside your lan and try to ping first the openvpn server ip (not the lan)

if it answers then your routing (from clients perspective) its ok.
try also to ping from your lan one vpn client ,if also responds then
definitely routing is ok..

have you disabled (if any) firewall on your pcs inside your lan?

cheers,

michael.

Many thanks Michael

I think the problem is mainly firewalls, as you suggest

By switching off all firewalls I can ping the client from the PCs on my LAN, although I have to put a static route into their routing tables;and I can, of course ping the machine which is running openvpn

On one occasion I managed to ping a LAN PC from the client, and indeed run remote desktop on it from the client. I haven't been able to repeat that success though and am not sure how I did it!

The client is a windows 7 machine, and I think it must be something to do the complications of windows 7.
Can't help feeling that it something to do with the routes in the client (Windows 7) machine or perhaps DNS troubles, but the fact that it worked once means that it must be possible!

Steve Hodge