Connection Problems

Nettlerash

I have been trying to set up OpenVPN for about 4 days, without full success. One of my clients successfully connects from its 'inner' network; another will only connect when using the same ADSL as the server. The network configurations are:

Test 1 - Works OK
Client1 (192.168.0.x) -- Netgear Router -- Newnet ADSL (80.175.x.x) -- Netgear Router -- Server (192.168.0.7)

Test 2 - Works OK
Client2 (192.168.2.x) -- TPLink Router (192.168.0.2) -- Server (192.168.0.7)

Test 3 - Fails
Client1 (192.168.1.x) -- BT Router -- BT ADSL (31.50.x.x) -- Newnet ADSL (80.175.x.x) -- Netgear Router -- Server (192.168.0.7)

Test 3 is the one which really describes the scenario that needs to work because the BT ADSL can be viewed as a 'Home' network and the Newnet ADSL an 'Office' network.

Note that the same client (1) was used in both tests 1 and 3 so I know the client - server configuration is OK from a cryptographic perspective.

In Test 3 the error I'm getting on the client is a handshake timeout: TLS Error: TLS key negotiation failed to occur within 60 seconds.

I've followed all recommended procedures to sort this out:

Is port forwarding enabled correctly?
Yes, because it works OK in Test 1. Here I used the same client but gave it the public IP address of the Newnet ADSL. I could see the packets being forwarded correctly in the Netgear router and the negotiation works fine in Test 1.

Have you enabled firewall rules?
Yes, using ufw and iptables and in the end by completely disabling iptables on the server; all to no effect so it's not a firewall issue.

Are packets reaching the server?
tcpdump on the server shows in all test cases that packets are being received, e.g.

Test 1
192.168.0.2.2817 > 192.168.0.7.openvpn : UDP, length 42

Test 3
31.50.x.x.36967 > 192.168.0.7.openvpn : UDP, length 42

The only difference in these two cases is that in Test 1 I get an immediate response from the openvpn server. in Test 3 I get no response.

Looking at the logs (level 5) there is nothing showing in the logs for Test 3 (server).

So, to sum it all up, I have the first connection packets arrving at the server but are seemingly not being picked up by openvpn.

Any clues anyone?

Nettlerash

Here are my config files:

Server:
=====
port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh2048.pem
server 10.16.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.16.0.0 255.255.255.0"
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 5

Client:
====
client
dev tun
proto udp
remote 80.175.x.x
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/<clientName>.crt
key /etc/openvpn/keys/<clientName>.key
ns-cert-type server
tls-auth /etc/openvpn/keys/ta.key 1
comp-lzo
verb 5

The server log after openvpn starts completes with "Initialisation Sequence Completed". In Test 3 where packets arrive at the server but are seemingly dropped there are no other logs on the server.

I'll grab the client log for Test 3 and post it after this.

Nettlerash

Here's the log from the client when it fails:

May 23 12:26:07 mark-1005PE ovpn-client[2691]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
May 23 12:26:07 mark-1005PE ovpn-client[2691]: Re-using SSL/TLS context
May 23 12:26:07 mark-1005PE ovpn-client[2691]: LZO compression initialized
May 23 12:26:07 mark-1005PE ovpn-client[2691]: Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
May 23 12:26:07 mark-1005PE ovpn-client[2691]: Socket Buffers: R=[163840->131072] S=[163840->131072]
May 23 12:26:07 mark-1005PE ovpn-client[2691]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
May 23 12:26:07 mark-1005PE ovpn-client[2691]: Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
May 23 12:26:07 mark-1005PE ovpn-client[2691]: Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
May 23 12:26:07 mark-1005PE ovpn-client[2691]: Local Options hash (VER=V4): '504e774e'
May 23 12:26:07 mark-1005PE ovpn-client[2691]: Expected Remote Options hash (VER=V4): '14168603'
May 23 12:26:07 mark-1005PE ovpn-client[2691]: UDPv4 link local: [undef]
May 23 12:26:07 mark-1005PE ovpn-client[2691]: UDPv4 link remote: [AF_INET]80.175.x.x:1194
May 23 12:27:07 mark-1005PE ovpn-client[2691]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
May 23 12:27:07 mark-1005PE ovpn-client[2691]: TLS Error: TLS handshake failed
May 23 12:27:07 mark-1005PE ovpn-client[2691]: TCP/UDP: Closing socket
May 23 12:27:07 mark-1005PE ovpn-client[2691]: SIGUSR1[soft,tls-error] received, process restarting
May 23 12:27:07 mark-1005PE ovpn-client[2691]: Restart pause, 2 second(s)
May 23 12:27:09 mark-1005PE ovpn-client[2691]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
May 23 12:27:09 mark-1005PE ovpn-client[2691]: Re-using SSL/TLS context
May 23 12:27:09 mark-1005PE ovpn-client[2691]: LZO compression initialized
May 23 12:27:09 mark-1005PE ovpn-client[2691]: Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
May 23 12:27:09 mark-1005PE ovpn-client[2691]: Socket Buffers: R=[163840->131072] S=[163840->131072]
May 23 12:27:09 mark-1005PE ovpn-client[2691]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
May 23 12:27:09 mark-1005PE ovpn-client[2691]: Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
May 23 12:27:09 mark-1005PE ovpn-client[2691]: Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
May 23 12:27:09 mark-1005PE ovpn-client[2691]: Local Options hash (VER=V4): '504e774e'
May 23 12:27:09 mark-1005PE ovpn-client[2691]: Expected Remote Options hash (VER=V4): '14168603'
May 23 12:27:09 mark-1005PE ovpn-client[2691]: UDPv4 link local: [undef]
May 23 12:27:09 mark-1005PE ovpn-client[2691]: UDPv4 link remote: [AF_INET]80.175.x.x:1194

Nettlerash

Thanks for the response.

Re. verification that packets in Test 3 are arriving, I've checked the logs on the Netgear firewall and I can see the packets being forwarded to the correct address. I'm also using tcpdump on the openvpn server:

Test 1
192.168.0.2.2817 > 192.168.0.7.openvpn : UDP, length 42
[a response packet immediately follows]

Test 3
31.50.x.x.36967 > 192.168.0.7.openvpn : UDP, length 42
[no response is made]

I have checked all the FAQ guidance and have enabled 1194 using ufw on the openvpn server. Since it defintely looks like the packet is being dropped before OpenVPN accesses it, I also disabled iptables completely. None of this has had any effect.

Nettlerash

I dearly hope you've found the cause of the problem but I'm afraid I don't follow your explanation.

On my ADSL router (Netgear DG834) I've enabled port forwarding of 1194 -> the openvpn server (192.168.0.7)

What I see in the ADSL logs is, for example:
Fri, 2014-05-23 11:42:41 - UDP Packet - Source:31.50.x.x,36967 Destination:80.175.x.x,1194 - [OpenVPN rule match]

and on the server's tcpdump:

31.50.x.x.36967 > 192.168.0.7.openvpn : UDP, length 42

So this (at least in my mind) says that the port forwarding rule on the Netgear router is correctly routing inbound packets destined for 80.175.x.x,1194 (my static IP) to the server address, i.e. 31.50.x.x,36967 > 80.175.x.x,1194 becomes 31.50.x.x.36967 > 192.168.0.7.1194 as shown in the tcpdump.

What I would then expect to see is a response from the openvpn server: 192.168.0.7.1194 > 31.50.x.x.36967 which would obviously route out through the Netgear ADSL router to the external destination (31.50.x.x.36967) which is a NAT'd address of the client's ADSL.

Is my understanding incorrect?

Nettlerash

That's a shame, Debbie. I was truly hoping you were going to tell me I had done something really stupid with the port forwarding!

I agree that it certainly looks like a firewall on the server is blocking the traffic. However, I've set ufw to full logging and it doesn't report anything being blocked. I've obviously also enabled in / out 1194 rules in ufw. I've even tried completely disabling both ufw and iptables but I still just see the same inbound packets and no response.

If the port forwarding wasn't working correctly (e.g. not correctly translating the packet port / destination) then my Test 1 - with the client inside the Netgear ADSL but using its external IP to force the connection through the port-forwarding rule - should also have failed but this works OK.

I think the only thing I can do next is completely disect the inbound packets seen on the server's ethernet interface. Maybe this will show some anomaly.

In the meantime, if anyone else has any ideas, feel free to suggest them. I'll consider any reasonable suggestion of what might be wrong or a test to carry out.