# [OpenVPN 2.0] client gets IP but can't connect. [SOLVED!]

## mariourk

I'm trying to get an OpenVPN connection running. So far I have the server running.

On the server I have an ethernet-bridge the contains eth0 and tap0. eth0 and tap0

don't have any IP. The bridge has 192.168.1.254 as IP. This works fine since I can

do anything I normally do in this machine. Things like internet, email, ssh, etc.

When I start the client, I do get a responce from the server and the client even

gets an IP assigned from the servers pool. But after that I don't have any connection.

This is what the server-log shows:

```

Mon Jan  9 10:47:10 2006 MULTI: multi_create_instance called

Mon Jan  9 10:47:10 2006 Re-using SSL/TLS context

Mon Jan  9 10:47:10 2006 Control Channel MTU parms [ L:1575 D:140 EF:40 EB:0 ET:0 EL:0 ]

Mon Jan  9 10:47:10 2006 Data Channel MTU parms [ L:1575 D:1450 EF:43 EB:4 ET:32 EL:0 ]

Mon Jan  9 10:47:10 2006 Local Options hash (VER=V4): 'a917298a'

Mon Jan  9 10:47:10 2006 Expected Remote Options hash (VER=V4): '10f35004'

Mon Jan  9 10:47:10 2006 TCP connection established with 81.68.215.80:54835

Mon Jan  9 10:47:10 2006 TCPv4_SERVER link local: [undef]

Mon Jan  9 10:47:10 2006 TCPv4_SERVER link remote: 81.68.215.80:54835

Mon Jan  9 10:47:10 2006 81.68.215.80:54835 TLS: Initial packet from 81.68.215.80:54835, sid=0ee8f2ca 8e61b3c6

Mon Jan  9 10:47:11 2006 81.68.215.80:54835 VERIFY OK: depth=1, /C=NL/ST=FL/L=Urk/O=GBU/CN=GBU_CA/emailAddress=mtennapel@gbugroep.nl

Mon Jan  9 10:47:11 2006 81.68.215.80:54835 VERIFY OK: depth=0, /C=NL/ST=FL/L=Urk/O=GBU/CN=client-mario/emailAddress=mtennapel@gbugroep.nl

Mon Jan  9 10:47:11 2006 81.68.215.80:54835 WARNING: 'dev-type' is used inconsistently, local='dev-type tap', remote='dev-type tun'

Mon Jan  9 10:47:11 2006 81.68.215.80:54835 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1575', remote='link-mtu 1543'

Mon Jan  9 10:47:11 2006 81.68.215.80:54835 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'

Mon Jan  9 10:47:11 2006 81.68.215.80:54835 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

Mon Jan  9 10:47:11 2006 81.68.215.80:54835 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Mon Jan  9 10:47:11 2006 81.68.215.80:54835 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

Mon Jan  9 10:47:11 2006 81.68.215.80:54835 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Mon Jan  9 10:47:11 2006 81.68.215.80:54835 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

Mon Jan  9 10:47:11 2006 81.68.215.80:54835 [client-mario] Peer Connection Initiated with 81.68.215.80:54835

Mon Jan  9 10:47:12 2006 client-mario/81.68.215.80:54835 PUSH: Received control message: 'PUSH_REQUEST'

Mon Jan  9 10:47:12 2006 client-mario/81.68.215.80:54835 SENT CONTROL [client-mario]: 'PUSH_REPLY,route-gateway 192.168.1.254,ping 10,ping-restart 120,ifconfig 192.168.1.235 255.255.255.0' (status=1)

Mon Jan  9 10:47:12 2006 client-mario/81.68.215.80:54835 Connection reset, restarting [0]

Mon Jan  9 10:47:12 2006 client-mario/81.68.215.80:54835 SIGUSR1[soft,connection-reset] received, client-instance restarting

Mon Jan  9 10:47:12 2006 TCP/UDP: Closing socket

```

This is what the client log shows:

```

Mon Jan  9 11:06:11 2006 OpenVPN 2.0.5 x86_64-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Dec 21 2005

Mon Jan  9 11:06:11 2006 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.

Mon Jan  9 11:06:11 2006 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.

Mon Jan  9 11:06:11 2006 Control Channel MTU parms [ L:1543 D:140 EF:40 EB:0 ET:0 EL:0 ]

Mon Jan  9 11:06:11 2006 Data Channel MTU parms [ L:1543 D:1450 EF:43 EB:4 ET:0 EL:0 ]

Mon Jan  9 11:06:11 2006 Local Options hash (VER=V4): 'db02a8f8'

Mon Jan  9 11:06:11 2006 Expected Remote Options hash (VER=V4): '7e068940'

Mon Jan  9 11:06:11 2006 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay

Mon Jan  9 11:06:11 2006 Attempting to establish TCP connection with 81.68.251.97:1194

Mon Jan  9 11:06:11 2006 TCP connection established with 81.68.251.97:1194

Mon Jan  9 11:06:11 2006 TCPv4_CLIENT link local: [undef]

Mon Jan  9 11:06:11 2006 TCPv4_CLIENT link remote: 81.68.251.97:1194

Mon Jan  9 11:06:11 2006 TLS: Initial packet from 81.68.251.97:1194, sid=fdd7972a 7797f104

Mon Jan  9 11:06:12 2006 VERIFY OK: depth=1, /C=NL/ST=FL/L=Urk/O=GBU/CN=GBU_CA/emailAddress=mtennapel@gbugroep.nl

Mon Jan  9 11:06:12 2006 VERIFY OK: depth=0, /C=NL/ST=FL/L=Urk/O=GBU/CN=server/emailAddress=mtennapel@gbugroep.nl

Mon Jan  9 11:06:13 2006 WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'

Mon Jan  9 11:06:13 2006 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1543', remote='link-mtu 1575'

Mon Jan  9 11:06:13 2006 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'

Mon Jan  9 11:06:13 2006 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

Mon Jan  9 11:06:13 2006 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Mon Jan  9 11:06:13 2006 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

Mon Jan  9 11:06:13 2006 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Mon Jan  9 11:06:13 2006 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

Mon Jan  9 11:06:13 2006 [server] Peer Connection Initiated with 81.68.251.97:1194

Mon Jan  9 11:06:14 2006 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)

Mon Jan  9 11:06:14 2006 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.1.254,ping 10,ping-restart 120,ifconfig 192.168.1.235 255.255.255.0'

Mon Jan  9 11:06:14 2006 OPTIONS IMPORT: timers and/or timeouts modified

Mon Jan  9 11:06:14 2006 OPTIONS IMPORT: --ifconfig/up options modified

Mon Jan  9 11:06:14 2006 OPTIONS IMPORT: route options modified

Mon Jan  9 11:06:14 2006 WARNING: Since you are using --dev tun, the second argument to --ifconfig must be an IP address.  You are using something (255.255.255.0) that looks more like a netmask. (silence this warning with --ifconfig-nowarn)

Mon Jan  9 11:06:14 2006 TUN/TAP device tun0 opened

Mon Jan  9 11:06:14 2006 /sbin/ifconfig tun0 192.168.1.235 pointopoint 255.255.255.0 mtu 1500

SIOCSIFDSTADDR: Invalid argument

Mon Jan  9 11:06:14 2006 Linux ifconfig failed: shell command exited with error status: 1

Mon Jan  9 11:06:14 2006 Exiting

```

here's my server-config:

```

port 1194

proto tcp

dev tap

ca ca.crt

cert server.crt

key server.key  # This file should be kept secret

dh dh1024.pem

ifconfig-pool-persist ipp.txt

server-bridge 192.168.1.254 255.255.255.0 192.168.1.235 192.168.1.250

client-to-client

keepalive 10 120

#tls-auth ta.key 0 # This file is secret

max-clients 15

user openvpn

group openvpn

persist-key

persist-tun

status openvpn-status.log

log         /var/log/openvpn.log

log-append  /var/log/openvpn.log

verb 3

```

and here's the client-config:

```

client

dev tun0

proto tcp

remote mail.gbugroep.nl 1194

resolv-retry infinite

nobind

user nobody

group nobody

persist-key

persist-tun

ca ca.crt

cert client.crt

key client.key

#comp-lzo

log         /var/log/openvpn.log

log-append  /var/log/openvpn.log

# Set log file verbosity.

verb 3

# Silence repeating messages

;mute 20

```

Does anyone know what's wrong?   :Confused: 

----------

## tuxmin

The answer lies in your log:

```

Mon Jan  9 11:06:13 2006 WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'

Mon Jan  9 11:06:13 2006 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1543', remote='link-mtu 1575'

Mon Jan  9 11:06:13 2006 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532' 

```

You can't mix tun/tap mode...

Hth, Alex!!!

----------

## mariourk

Oic, I missed that...   :Embarassed:   :Embarassed:   :Embarassed: 

Thanks a lot for your tip! Now I can get on with this   :Very Happy: 

----------

## mariourk

Your suggestion was indeed helpfull. I can connect to the server without any errors.

However, I still can't connect to the client/server/other pc's in the network over the

OpenVPN-tunnel.

The logs show no errors and I'm pretty sure it's no firewall issue (since on neither the

client nor the server runs any firewall) I have ip_forward enabled on the server.

Any suggestions?

----------

## tuxmin

Maybe a routing problem. You probably need something like this in your server.conf

```

push "route 192.168.10.0 255.255.255.0"

```

Tell me more about your setup...

----------

## mariourk

No, I chose the bridging solution to avoid routing.

The server, client and the server-LAN are all in the same range.

server = 192.168.1.254

client = 192.168.1.235

server-LAN = 192.168.1.x

so routing shouldn't be the problem.

----------

## tuxmin

I see... in that case a packet sniffer could shed some light on this if you say it's not a firewall issue.

Run ethereal or tcpdump on the tap interface on the server and try pinging some IP on the brigde from the client. If you don't see any traffic check on the tap interface on the client and maybe the real interface.

Btw, it is better to use UDP as tunnel protocol. TCP may fail miserably. It is merely meant for connections over http proxies.

Alex!!

----------

## tuxmin

Second thoughts... I run my server in tun mode, which I find much easier to setup... did you setup a bridge device on your server?

```

              To  configure  ethernet  bridging,  you must first use your OS's

              bridging capability to bridge the TAP interface with the  ether-

              net  NIC interface.  For example, on Linux this is done with the

              brctl tool, and with Windows XP it is done in the  Network  Con-

              nections  Panel  by  selecting the ethernet and TAP adapters and

              right-clicking on "Bridge Connections"

              Next you you must manually set the IP/netmask on the bridge  in-

              terface.   The gateway and netmask parameters to --server-bridge

              can be set to either the IP/netmask of the bridge interface,  or

              the IP/netmask of the default gateway/router on the bridged sub-

              net.

              Finally, set aside a IP range in the bridged subnet, denoted  by

              pool-start-IP  and  pool-end-IP, for OpenVPN to allocate to con-

              necting clients.

```

----------

## mariourk

Yes, I have setup a network-bridge wich holds eth0 and tap0. OpenVPN is configured

to use this bridge and that seems to work fine. That means, OpenVPN has no complains

about it in the logs and seems to be able to communicate to the client since it can handout

an IP-adres. The only problem is that the fun stops there since I can't do anything after that   :Confused: 

I tried the UPD-protocol instead of the TCP-protocol. When I do that, I run into another problem.

The server says something about handing out an IP but the client doesn't recieve that. That means

tap0 is not coming up, wich was the case when I used TCP. After starting OpenVPN it would

automaticly start tap0 and use the give IP it recieved from the server. Such it not the case

when I use UDP. In fact, when I use UDP, tap0 refuses to come up.   :Confused: 

I really hope I can get this working with some help...   :Rolling Eyes:   :Wink: 

----------

## mariourk

If I'm monitoring the tap-devices with tcpdump, this is what

I get when I try to ssh from the client to the server.

client-sided:

```

14:51:28.718748 arp who-has 192.168.1.254 tell 192.168.1.235

14:51:29.718789 arp who-has 192.168.1.254 tell 192.168.1.235

14:51:30.718851 arp who-has 192.168.1.254 tell 192.168.1.235

14:51:54.776365 arp who-has 192.168.1.254 tell 192.168.1.235

14:51:55.776417 arp who-has 192.168.1.254 tell 192.168.1.235

14:51:56.776480 arp who-has 192.168.1.254 tell 192.168.1.235

14:52:23.810176 arp who-has 192.168.1.254 tell 192.168.1.235

14:52:24.810232 arp who-has 192.168.1.254 tell 192.168.1.235

14:52:25.810294 arp who-has 192.168.1.254 tell 192.168.1.235

```

Server-sided:

```

14:52:22.815335 802.1d config 8000.00:05:1a:09:e0:60.8018 root 8000.00:05:1a:09:e0:60 pathcost 0 age 0 max 20 hello 2 fdelay 15

```

If I do it the other way around (from the server to the client) tcpdump on

the server will give the same output but the client nothing at all.

Maybe this is helpfull to determine the problem and find a solution?

It doens't mean much to me though   :Confused: 

----------

## mariourk

I *finally* managed to solve the problem!   :Very Happy: 

Instead of just using

```

dev tap

```

in /etc/openvpn/openvpn.conf

I should use

```

dev tap0

```

After changing this in /etc/openvpn/openvpn.conf for both the client

and the server it worked fine. I could reach the server and any other

pc's in the server's LAN.

I'm so happy it works now. Hopefully the will be usefully for someone else.

I know first hand how frustrating it can be if you just can get it working   :Very Happy: 

I got the idea from this thread. 2nd post, last line.

----------

