Linode Forum
https://forum.linode.com/

OpenVPN TLS error?
https://forum.linode.com/viewtopic.php?f=19&t=7102		 Page 1 of 1
Author:  ss1271 [ Tue May 10, 2011 11:28 am ]
Post subject:  OpenVPN TLS error?
Hi,

I've been successfully set up two OpenVPN server before, but this time I cannot figure out why the client keep saying:

(connect using Tunnelblick on Mac)
2011-05-10 15:49:13 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2011-05-10 15:49:13 TLS Error: TLS handshake failed
2011-05-10 15:49:13 TCP/UDP: Closing socket
2011-05-10 15:49:13 SIGUSR1[soft,tls-error] received, process restarting
2011-05-10 15:49:13 MANAGEMENT: >STATE:1305038953,RECONNECTING,tls-error,,


(on Windows)
Mon May 10 15:10:25 2011 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Mon May 10 15:10:27 2011 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Mon May 10 15:10:28 2011 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)

It's weird because the two different clients are telling totally different log.
I've tried change the port, restart the iptables, restart the OpenVPN server, re-generate a client key but still no go.

I could ensure that my VPS is running normally and my networking connectivity is good.

here's my IPTABLES, it's now been cleaned, but the OpenVPN connection still cannot go through.

Table: security
Chain INPUT (policy ACCEPT)
num target prot opt source destination

Chain FORWARD (policy ACCEPT)
num target prot opt source destination

Chain OUTPUT (policy ACCEPT)
num target prot opt source destination

Table: raw
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination

Chain OUTPUT (policy ACCEPT)
num target prot opt source destination

Table: nat
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination

Chain INPUT (policy ACCEPT)
num target prot opt source destination

Chain OUTPUT (policy ACCEPT)
num target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
num target prot opt source destination
1 MASQUERADE all -- 10.8.0.0/24 0.0.0.0/0
2 SNAT all -- 10.8.0.0/24 0.0.0.0/0 to:VPS
3 MASQUERADE all -- 192.168.10.0/24 0.0.0.0/0
4 MASQUERADE all -- 192.168.0.0/24 0.0.0.0/0

Table: mangle
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination

Chain INPUT (policy ACCEPT)
num target prot opt source destination

Chain FORWARD (policy ACCEPT)
num target prot opt source destination

Chain OUTPUT (policy ACCEPT)
num target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
num target prot opt source destination

Table: filter
Chain INPUT (policy ACCEPT)
num target prot opt source destination

Chain FORWARD (policy ACCEPT)
num target prot opt source destination

Chain OUTPUT (policy ACCEPT)
num target prot opt source destination

I'm new to debugging the OpenVPN and Linux server, Could you guys help me with that?

Thanks a lot!!!
Author:  hoopycat [ Tue May 10, 2011 3:18 pm ]
Post subject: 
Is anything interesting showing up in the server's log? It sounds network-related, whatever it is.

Try using tcpdump to see what is going over the network on each end:

Code:
server$ tcpdump -i eth0 -n port 3306
client$ tcpdump -i eth0 -n port 3306


For Windows, take a look at Wireshark, which does the same thing but more pretty. Also, change port 3306 to whatever you've configured OpenVPN to use and eth0 to whichever interface the traffic should be traversing (e.g. wlan0, ppp0...).

Start tcpdumping, then try to bring up openvpn on the client and see what happens. You should see the same thing on both ends -- each side will send packets to the other side -- although the timestamps will be a bit different thanks to the speed of light. If you notice one end is sending packets and they aren't received by the other end, there's probably your problem.
Author:  ss1271 [ Tue May 10, 2011 3:55 pm ]
Post subject: 
Hey Hoopycat,
Thx for your reply.

And, I think I've some problem in logging.
I've add the

log-append openvpn.log
status openvpn-status.log

onto the server.conf, but none of these files exists...that's a little bit different with what I've deal before, so that's the problem no.1.

As for the problem No.2, I followed your instructions, and got these results.


On Server's side:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
03:45:05.780432 IP Client's IP.49263 > Server's IP.11940: UDP, length 14
03:45:08.071843 IP Client's IP.49263 > Server's IP.11940: UDP, length 14
03:45:11.340620 IP Client's IP.49263 > Server's IP.11940: UDP, length 14


On Client's Side:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
20:45:05.712080 IP 192.168.1.97.51181 > Server's IP.11940: UDP, length 14
20:45:07.931013 IP 192.168.1.97.51181 > Server's IP.11940: UDP, length 14
20:45:11.257140 IP 192.168.1.97.51181 > Server's IP.11940: UDP, length 14
20:45:19.427502 IP 192.168.1.97.51181 > Server's IP.11940: UDP, length 14
20:45:35.796022 IP 192.168.1.97.51181 > Server's IP.11940: UDP, length 14
20:46:06.044289 IP 192.168.1.97.62862 > Server's IP.11940: UDP, length 14
20:46:08.182319 IP 192.168.1.97.62862 > Server's IP.11940: UDP, length 14
20:46:12.456474 IP 192.168.1.97.62862 > Server's IP.11940: UDP, length 14
20:46:20.149239 IP 192.168.1.97.62862 > Server's IP.11940: UDP, length 14
20:46:36.959088 IP 192.168.1.97.62862 > Server's IP.11940: UDP, length 14
20:47:06.708537 IP 192.168.1.97.53994 > Server's IP.11940: UDP, length 14
20:47:08.983370 IP 192.168.1.97.53994 > Server's IP.11940: UDP, length 14
20:47:12.394614 IP 192.168.1.97.53994 > Server's IP.11940: UDP, length 14

___

the openvpn log on the client side is almost the same as I've posted before, and initially, the server received the client's request, but some how the client's followed up requests was not appeared on the server, why's that?


Thanks for helping me!
Author:  db3l [ Tue May 10, 2011 4:03 pm ]
Post subject: 
ss1271 wrote:
Hey Hoopycat,
Thx for your reply.

And, I think I've some problem in logging.
I've add the

log-append openvpn.log
status openvpn-status.log

onto the server.conf, but none of these files exists...that's a little bit different with what I've deal before, so that's the problem no.1.

Yeah, I'd try to solve the logging first. It could be as simple as a verification error for the certificates, which would force the server to terminate the connection (and from the client side just looks like a continuous negotiation).

By default OpenVPN's logging will go to syslog (e.g., if you leave the above disabled), so you may in fact already have logs available. Try checking your system log files for logs from "ovpn-XXX" where XXX is your config. On my Ubuntu systems they end up in daemon.log by default.

-- David
Author:  ss1271 [ Tue May 10, 2011 4:38 pm ]
Post subject: 
Hey thx for helping me.

I wonder why it returned me "openvpn service not start" when checking the status of openvpn.



[root openvpn]# /etc/init.d/openvpn start
Starting openvpn: [ OK ]
[root openvpn]# /etc/init.d/openvpn status
openvpn: service not started


I think this is where the problem lies. But why and how to solve it?

Thanks!
Author:  db3l [ Tue May 10, 2011 4:53 pm ]
Post subject: 
ss1271 wrote:
Hey thx for helping me.

I wonder why it returned me "openvpn service not start" when checking the status of openvpn.

Maybe you don't have any server configuration files in the configuration directory? I'm on an older distribution but in my case when I start openvpn it shows which VPNs it is starting. But I don't think a lack of any configuration files would be considered an error.

Or, if you're on a distribution with /etc/default/openvpn, could it have been configured to limit what VPNs are started?

-- David
Author:  ss1271 [ Tue May 10, 2011 6:59 pm ]
Post subject: 
Thx everyone who offered me help.

And the "log" problem solved (Thx to you, db3l)
It was me to forgot to put the server.conf to /etc/openvpn ...

And at this time, the server side could receive the packets sent by the client.

On the server side, the OpenVPN is running now, and its logging the log, but on the client side, it still got the TLS handshake error.

Here's the log of the client's side:

2011-05-10 23:28:26 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
2011-05-10 23:28:26 Socket Buffers: R=[42080->65536] S=[9216->65536]
2011-05-10 23:28:26 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
2011-05-10 23:28:26 Local Options hash (VER=V4): '41690919'
2011-05-10 23:28:26 Expected Remote Options hash (VER=V4): '530fdded'
2011-05-10 23:28:26 UDPv4 link local: [undef]
2011-05-10 23:28:26 UDPv4 link remote: Server's IP:11940
2011-05-10 23:28:26 MANAGEMENT: >STATE:1305066506,WAIT,,,
2011-05-10 23:28:28 MANAGEMENT: >STATE:1305066508,AUTH,,,
2011-05-10 23:28:28 TLS: Initial packet from Server's IP:11940, sid=e28dc6ed 0671ee96
2011-05-10 23:28:29 VERIFY OK: depth=1, /C=xx/ST=xx/L=xx/O=xx/CN=server/emailAddress=xx@xx.com
2011-05-10 23:28:29 VERIFY OK: depth=0, /C=xx/ST=xx/L=xx/O=xx/CN=server/emailAddress=xx@xx.com
2011-05-10 23:29:27 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2011-05-10 23:29:27 TLS Error: TLåS handshake failed
2011-05-10 23:29:27 TCP/UDP: Closing socket
2011-05-10 23:29:27 SIGUSR1[soft,tls-error] received, process restarting
2011-05-10 23:29:27 MANAGEMENT: >STATE:1305066567,RECONNECTING,tls-error,,


And it was weird because when the connection is failed and trying to reconnect via client, the log on the client side is different from above,
it kept showing
2011-05-10 23:52:22 MANAGEMENT: >STATE:1305067942,WAIT,,,
and then TLS Error.

But when I directly type /etc/init.d/openvpn start, and then use client to connect, the client could receive the TLS initial packet, but then handshake error like the log I pasted.

It seemed the openvpn is up for a while and then somehow been shutdown.

Could you help me with this new situation?

Thanks a lot!!!
Author:  db3l [ Tue May 10, 2011 7:13 pm ]
Post subject: 
ss1271 wrote:
On the server side, the OpenVPN is running now, and its logging the log, but on the client side, it still got the TLS handshake error.

Ok, so same question as before - what's your server log show for this connection? This sort of client log is indicative of the server rejecting or refusing to negotiate, so the most likely place for the smoking gun information to be is on the server side logs.

Pair up the server and client logs for the same attempted connection and you should have enough information to deduce what is going wrong.

-- David
Author:  ss1271 [ Tue May 10, 2011 7:25 pm ]
Post subject: 
db3l wrote:
Pair up the server and client logs for the same attempted connection and you should have enough information to deduce what is going wrong.

-- David



I failed, because it only logged the openvpn-status.log which is definitely not the openvpn log but logging the client connection...

I put the log (openvpn.log and openvpn-status.log) at the same directory, but what I can see is only the status log...
Author:  db3l [ Tue May 10, 2011 9:31 pm ]
Post subject: 
ss1271 wrote:
I put the log (openvpn.log and openvpn-status.log) at the same directory, but what I can see is only the status log...

Not sure what else to suggest until you get the server logging working. Personally, I'd leave the log config file commands commented out and just let it default to using syslog, then check those log files.

But you really need server side logging to see what might be going on.

Worst case, shut the service down and then manually run openvpn (as root) against your config file (e.g., openvpn --config xxxx) in non-daemon mode and watch the logging on stdout.

-- David
Author:  ss1271 [ Wed May 11, 2011 9:03 am ]
Post subject: 
Thanks everyone for offering me help

Specially thanx to Hoopycat and db3l.

I managed to get the OpenVPN work properly.

Here's the Problem I met:

1. forgot to put the .conf configuration file to /etc/openvpn/
2. forgot the log is putting at /etc/openvpn/
3. dnsmasq is working, but forgot to configure it
4. wrongly write push "redirect-gateway def1 bypass-dhcp" in the configuration file of server, so the server's DNS service was bypassed by the client, and the client could not finish the DNS request.


Though I did this spending a whole nighter, learnt a lot of stuff, thx again for your generous help.
Author:  hoopycat [ Wed May 11, 2011 10:11 am ]
Post subject: 
ss1271 wrote:
Though I did this spending a whole nighter, learnt a lot of stuff, thx again for your generous help.


This is the important part. :-) Yay! (I mean, the learning-of-lots-of-stuff... the all-nighter, probably not so important.)

The intersection of sysadmin stuff and networking stuff is always an interesting one... problem is that I always think "something is broken with the network" instead of "the config file doesn't exist in the right place," so props to db3l for remembering that end of it!
Author:  ss1271 [ Wed May 11, 2011 10:20 am ]
Post subject: 
hoopycat wrote:
ss1271 wrote:
Though I did this spending a whole nighter, learnt a lot of stuff, thx again for your generous help.


This is the important part. :-) Yay! (I mean, the learning-of-lots-of-stuff... the all-nighter, probably not so important.)

The intersection of sysadmin stuff and networking stuff is always an interesting one... problem is that I always think "something is broken with the network" instead of "the config file doesn't exist in the right place," so props to db3l for remembering that end of it!


lol, cuz that "configure file" problem is really noob mistake XD
Author:  db3l [ Wed May 11, 2011 4:10 pm ]
Post subject: 
ss1271 wrote:
lol, cuz that "configure file" problem is really noob mistake XD

Well, you debug and troubleshoot stuff for long enough and you find it's always a good idea to try to ask the "Is it plugged in?" sort of questions too :-)

-- David
Page 1 of 1 All times are UTC-04:00
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/