[Closed] TLS Handshake blocked

peterm

Hello OpenVPN community,

first off, great work on this project!

I have read the FAQs and I have searched the forum for this particular problem, but could only find 3 reportings of this error, stemming from a different error, which cannot be the cause of my problems.

Problem:
I've been trying to get OpenVPN Client to work for the past week on my work computer to no avail, getting a TLS handshake error.

I have 2 OpenVPN Servers. 1 VPS and my home Router. Both use different keys and different configurations, but proto is UDP in both cases. I receive the OVPN file from them. Now i can use these two configurations on my MAC OS X Laptop and my Android phone and connect to BOTH these servers without touching the configuration at all via WLAN at work without a problem.

Using any of the two configuraion on Ubuntu 12.04 LAN machine fails, not managing to establish a TLS connection with any of my two server. Using a fresh USB Ubuntu 12.04 or 14.04 daily (16.03.14), the same problem occurs.

I asked my IT guys, if the firewall is blocking any outgoing VPN, but they assured me that whatever i do on the WLAN should be possible on the LAN.

I have access to the OpenVPN 2.3.2 log on my home router, where i can verify that the initial packet is indeed received, but TLS handshake fails afterwards.

is there anything left i could rule out as a factor? My IT guys are wrong aren't they? ...

Thanks for any input in advance.

peterm

I am sorry

@ServerConfigs: As i mentioned in my post, i cannot provide server configuration files.
@Clientconfigs: see below
@Log: The server log is 2 lines long, both of which i have mentioned in my post A) Initial packet is received B) TLS handshake fails.

Goal:
Can i get a more verbose output for the TLS handshake, so i can see why it fails exactly?

client config server1 vps-machine
client
tls-client
remote X 1194
redirect-gateway def1
dhcp-option DNS 8.8.8.8
dhcp-option DNS 8.8.4.4
route X 255.255.255.255 net_gateway
proto udp
dev tun
resole-retry infinite
nobind
persist-key
persist-tun
<ca>X</ca>
auth-user-pass
ns-cert-type server
comp-lzo

client config server2 (asuswrt-merlin default config)
client
dev tun
proto udp
remote X 1194
float
comp-lzo adaptive
keepalive 15 60
auth-user-pass
<ca>X</ca>
<cert>X</cert>
<key>X</key>
ns-cert-type server
resolv-retry infinite
nobind

peterm

As explained, these configs are of no consequence, which becomes apparent if you'd follow my train of thought. But I undertand that following logic concatenation is hard for some people, so by all means, please delete this thread.

I was not looking for advice on configuration, but rather on advice on verifying if my work firewall blocks TLS handshakes. I will look for an answer to this problem in a more fitting forum. Thank you for your time debbie10t.

peterm

And your obvious disregard for professionals you work with:

That was quite a harsh thing to imply. I value my collegues very much, they do amazing work and I do not lightly "disregard" their input. It's just that they told me that they had no knowledge of any rules that would hinder VPN and I wasn't going to waste company ressources on a private matter.

peterm

debbie10t wrote And with the understanding that the network you are trying to work with, over which you want to create a VPN, is no doubt much more complex than my simple point-to-point test network, where I constructed the quiz is, here is a clue to the quiz solution that I will leave in this thread for you to apply.

There is one directive which is not used wisely and guess what, it is in the server side config, somewhere ...

I can assure you, that your knowledge concerning OpenVPN and Network Configurations is vastly superior to mine, even without me jumping trough hoops. But it looks very well crafted.

peterm

debbie10t wrotePlease see the Forum rules (top of page)
If your logic is so impeccable perhaps you can furnish us with an answer to the Quiz.

Connection over TCP established. UDP does not work on LAN here, only WLAN as hypothesized.
Regarding (http://sites.inka.de/~bigred/devel/tcp-tcp.html), since i canot avoid it TCP in this case, i will have to stick with it. No other configuration parameters were changed. Problem is thusly solved and can be closed. I thank you for your input.