OpenVPN TLS error?

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:

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.

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!

@ss1271:

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

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!

@ss1271:

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

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!!!

@ss1271:

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

@db3l:

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…

@ss1271:

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

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.

@ss1271:

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!

@hoopycat:

@ss1271:

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

@ss1271:

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