| View previous topic :: View next topic |
| Author |
Message |
mariourk
l33t
Joined: 11 Jul 2003
Posts: 807
Location: Urk, Netherlands
|
 Posted: Mon Jan 09, 2006 10:11 am Post subject: [OpenVPN 2.0] client gets IP but can't connect. [SOLVED!] |
 |
|
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:
| Code: |
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:
| Code: |
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:
| Code: |
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:
| Code: |
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? 
_________________
If there is one thing to learn from history, it's that we usualy don't learn anything from it, at all.
Last edited by mariourk on Wed Jan 11, 2006 3:30 pm; edited 1 time in total |
|
| Back to top |
|
 |
tuxmin
l33t
Joined: 24 Apr 2004
Posts: 838
Location: Heidelberg
|
| Posted: Mon Jan 09, 2006 10:30 am Post subject: |
|
|
The answer lies in your log:
| Code: |
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!!!
_________________
ALT-F4 |
|
| Back to top |
|
|
mariourk
l33t
Joined: 11 Jul 2003
Posts: 807
Location: Urk, Netherlands
|
| Posted: Mon Jan 09, 2006 10:38 am Post subject: |
|
|
Oic, I missed that... 
Thanks a lot for your tip! Now I can get on with this 
_________________
If there is one thing to learn from history, it's that we usualy don't learn anything from it, at all. |
|
| Back to top |
|
|
mariourk
l33t
Joined: 11 Jul 2003
Posts: 807
Location: Urk, Netherlands
|
| Posted: Mon Jan 09, 2006 10:56 am Post subject: |
|
|
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?
_________________
If there is one thing to learn from history, it's that we usualy don't learn anything from it, at all. |
|
| Back to top |
|
|
tuxmin
l33t
Joined: 24 Apr 2004
Posts: 838
Location: Heidelberg
|
| Posted: Mon Jan 09, 2006 11:36 am Post subject: |
|
|
Maybe a routing problem. You probably need something like this in your server.conf
| Code: |
push "route 192.168.10.0 255.255.255.0"
|
Tell me more about your setup...
_________________
ALT-F4 |
|
| Back to top |
|
|
mariourk
l33t
Joined: 11 Jul 2003
Posts: 807
Location: Urk, Netherlands
|
| Posted: Mon Jan 09, 2006 1:24 pm Post subject: |
|
|
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.
_________________
If there is one thing to learn from history, it's that we usualy don't learn anything from it, at all. |
|
| Back to top |
|
|
tuxmin
l33t
Joined: 24 Apr 2004
Posts: 838
Location: Heidelberg
|
| Posted: Mon Jan 09, 2006 2:02 pm Post subject: |
|
|
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!!
_________________
ALT-F4 |
|
| Back to top |
|
|
tuxmin
l33t
Joined: 24 Apr 2004
Posts: 838
Location: Heidelberg
|
| Posted: Mon Jan 09, 2006 2:11 pm Post subject: |
|
|
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?
| Code: |
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.
|
_________________
ALT-F4 |
|
| Back to top |
|
|
mariourk
l33t
Joined: 11 Jul 2003
Posts: 807
Location: Urk, Netherlands
|
| Posted: Wed Jan 11, 2006 8:55 am Post subject: |
|
|
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
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.
I really hope I can get this working with some help...  
_________________
If there is one thing to learn from history, it's that we usualy don't learn anything from it, at all.
Last edited by mariourk on Wed Jan 11, 2006 2:36 pm; edited 1 time in total |
|
| Back to top |
|
|
mariourk
l33t
Joined: 11 Jul 2003
Posts: 807
Location: Urk, Netherlands
|
| Posted: Wed Jan 11, 2006 1:58 pm Post subject: |
|
|
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:
| Code: |
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:
| Code: |
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
_________________
If there is one thing to learn from history, it's that we usualy don't learn anything from it, at all. |
|
| Back to top |
|
|
mariourk
l33t
Joined: 11 Jul 2003
Posts: 807
Location: Urk, Netherlands
|
| Posted: Wed Jan 11, 2006 3:27 pm Post subject: |
|
|
I *finally* managed to solve the problem!
Instead of just using
in /etc/openvpn/openvpn.conf
I should use
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
I got the idea from this thread. 2nd post, last line.
_________________
If there is one thing to learn from history, it's that we usualy don't learn anything from it, at all. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
