OpenVPN Support Forum

I'm using a tun/UDP server/client configuration both with dynamic IPs. I have port forwarding properly configured on my router, and a No-IP updater installed on the server with the correct public IP address identified.

If I use the server's local IP address in my client's remote statement (i.e. remote #.#.#.#), the client connects to the server flawlessly every time. However, if I use the DDNS address in the client's remote statement (i.e. remote myServer.no-ip.org), then the first time I try to connect the client to the server it will fail, regardless of whether I place the client on the local network or a remote network.

I then have to either disconnect and reconnect, or wait for the client to attempt to reconnect automatically. After that everything works fine.

This is the relevant part of my client config file:

dev tun
proto udp
tun-mtu 1500
comp-lzo
client
port XXXX
remote myServer.no-ip.org XXXX #server's local IP works fine if client is on same subnet
float
keepalive 10 300
resolv-retry infinite
auth SHA
cipher BF-CBC
tls-cipher EXP-DES-CBC-SHA
tls-auth "ta.key" 1
tls-client

... and the relevant part of the server config:

dev tun
dev-node ServerTAP
proto udp
tun-mtu 1500
comp-lzo
server 10.10.10.0 255.255.255.248
port XXXX
ifconfig-pool-persist "ipp.txt"
float
keepalive 10 300
auth SHA
cipher BF-CBC
tls-cipher EXP-DES-CBC-SHA
tls-auth "ta.key" 0
tls-server

This is a portion of the client log file at the point the failed connection occurs:

Fri Feb 18 05:11:47 2011 LZO compression initialized
Fri Feb 18 05:11:48 2011 UDPv4 link local (bound): [undef]:XXXX
Fri Feb 18 05:11:48 2011 UDPv4 link remote: X.X.X.X:XXXX
Fri Feb 18 05:12:48 2011 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Feb 18 05:12:48 2011 TLS Error: TLS handshake failed
Fri Feb 18 05:12:48 2011 SIGUSR1[soft,tls-error] received, process restarting

and this is from the server log:

Fri Feb 18 05:10:58 2011 Sleeping for 10 seconds...
Fri Feb 18 05:11:08 2011 Successful ARP Flush on interface [262149] {58F8A3ED-D779-454C-AF11-3E22C63FC399}
Fri Feb 18 05:11:08 2011 UDPv4 link local (bound): [undef]:XXXX
Fri Feb 18 05:11:08 2011 UDPv4 link remote: [undef]
Fri Feb 18 05:11:08 2011 Initialization Sequence Completed
Fri Feb 18 05:11:42 2011 X.X.X.X:XXXX Re-using SSL/TLS context
Fri Feb 18 05:11:42 2011 X.X.X.X:XXXX LZO compression initialized
Fri Feb 18 05:12:42 2011 X.X.X.X:XXXX TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Feb 18 05:12:42 2011 X.X.X.X:XXXX TLS Error: TLS handshake failed
Fri Feb 18 05:12:45 2011 Y.Y.Y.Y:YYYY Re-using SSL/TLS context
Fri Feb 18 05:12:45 2011 Y.Y.Y.Y:YYYY LZO compression initialized
Fri Feb 18 05:12:47 2011 Y.Y.Y.Y:YYYY [VPN-Client] Peer Connection Initiated with Y.Y.Y.Y:YYYY

I've changed my actual IPs and ports to X's and Y's, but the X's represent the public IP address of the server, and the Y's represent the IP address of the client.

This happens regardless of whether the client is physically located inside the local network or outside on another network. Subsequent reconnects succeed without any problems. It's a minor annoyance, but I'd like to resolve it if possible.

the errors you are seeing are caused by firewalls in most cases.

two questions:
1) is the X.X.X.X indeed the correctly resolve noIP address?
2) can you test it without the
auth
cipher
tls-cipher
tls-auth
part just to see if that has any influence (it should not, but I just want to make sure).

BTW: if you specify 'keepalive' on the server then there is no need to specify it on the client: the server directive overrules whatever you specify on the client using a "push" message.

HTH,

JJK

Thanks again for your help!

Yes, the X.X.X.X IP is the public IP address assigned to the server's gateway router, which No-IP is correctly resolving. I have that router configured to forward all UDP traffic for port 19799 (the port I'm using for OpenVPN) to the local IP address of the server. I also configured static DHCP on the router to ensure the local address of the OpenVPN server/host is always the same, and I enabled OpenVPN in the anti-virus/firewall on the server computer, which in this case is G Data Internet Security 2011.

I think you're right about this being a firewall issue. I'll run the test you suggested without the auth/cipher etc. parts in the config. I'm also going to try connecting from the local library's wifi using the public IP address instead of the domain name. I'll post the results.

OK, I'm pretty sure this has nothing to do with DDNS now. I haven't had a chance to do another test outside my local network, but I did run the test you suggested, and I got the same result. I then put the auth/tls statements back into the config and tried to get the client to connect directly to the public IP address without the domain name, and the result was the same.

The server log looked like this:

Sat Feb 19 12:22:44 2011 us=531000 X.X.X.X:XXXX Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sat Feb 19 12:22:44 2011 us=531000 X.X.X.X:XXXX Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sat Feb 19 12:22:44 2011 us=531000 X.X.X.X:XXXX Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA,keysize 128,tls-auth,key-method 2,tls-server'
Sat Feb 19 12:22:44 2011 us=531000 X.X.X.X:XXXX Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher BF-CBC,auth SHA,keysize 128,tls-auth,key-method 2,tls-client'
Sat Feb 19 12:22:44 2011 us=531000 X.X.X.X:XXXX Local Options hash (VER=V4): '614f4fde'
Sat Feb 19 12:22:44 2011 us=531000 X.X.X.X:XXXX Expected Remote Options hash (VER=V4): 'e964ec13'
Sat Feb 19 12:22:44 2011 us=531000 X.X.X.X:XXXX TLS: Initial packet from X.X.X.X:XXXX, sid=1617646e e2fa4504
Sat Feb 19 12:23:44 2011 us=687000 X.X.X.X:XXXX TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Feb 19 12:23:44 2011 us=687000 X.X.X.X:XXXX TLS Error: TLS handshake failed
Sat Feb 19 12:23:44 2011 us=687000 X.X.X.X:XXXX SIGUSR1[soft,tls-error] received, client-instance restarting
Sat Feb 19 12:23:46 2011 us=609000 MULTI: multi_create_instance called
Sat Feb 19 12:23:46 2011 us=609000 Y.Y.Y.Y:YYYY Re-using SSL/TLS context

and the client log:

Sat Feb 19 12:22:52 2011 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sat Feb 19 12:22:52 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sat Feb 19 12:22:52 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sat Feb 19 12:22:52 2011 Local Options hash (VER=V4): 'e964ec13'
Sat Feb 19 12:22:52 2011 Expected Remote Options hash (VER=V4): '614f4fde'
Sat Feb 19 12:22:52 2011 UDPv4 link local (bound): [undef]:XXXX
Sat Feb 19 12:22:52 2011 UDPv4 link remote: X.X.X.X:XXXX
Sat Feb 19 12:22:52 2011 TLS: Initial packet from X.X.X.X:XXXX, sid=dcf8a22f 4a834eed
Sat Feb 19 12:23:52 2011 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Feb 19 12:23:52 2011 TLS Error: TLS handshake failed

The interesting part is that the two logs show the same IP address and port for the lines highlighted in red. That IP address is the public address assigned to my router, which is forwarding UDP traffic for that port to the server/host machine. I'm not sure if my interpretation of these logs is correct, but it looks to me like a port-forwarding issue and changing the client port number might fix the problem...

Nope... still doesn't work. It won't connect until it resolves the private IP addresses of the client and server computers on the local network. Whether they use the same port number or not seems to be irrelevant.

I'm pretty convinced this has something to do with my specific router. I found the following link which provides some interesting information:

http://readlist.com/lists/lists.sourcef ... /8545.html

This is one for the FAQ's.

If you can not seem to get a D-Link dgl4100 router to
accept UDP packets from a remote Open VPN client, it is
dues to an undocumented (in their user manual) feature
called: NAT Endpoint Filtering.

The dlg4100 will not accept UDP packets of "State = NEW"
(iptables jargon) unless you have "UDP NAT Endpoint Filtering"
set to "Endpoint Independent".

You can find "NAT Endpoint Filtering" in
--> "Advanced"
--> "Firewall"
--> "UDP Endpoint Filtering"
--> "Endpoint Independent"


I hope this saves someone else from tearing their
hair out!

--T

While I don't have that particular model, I do have a D-Link router (DI-524). Unfortunately, the setting he/she is referring to doesn't exit in my interface.

I tried switching to TCP, but it suffers from the same problem: won't connect on initial try, connects successfully on reconnection. It doesn't seem to matter what my NAT/PAT settings are or any of my firewall rules (I've tried every combination I can think of). I even tried putting the server in the DMZ temporarily.

This has now become my white whale. I'd love to figure it out even though the VPN is still usable at the moment.

I can find numerous posts via Google of people having problems to get NAT to work properly using a DI-524 ; there's very little OpenVPN can do about that, although I did expect that TCP would work.

Check the D-Link userguide to set up a new port mapping for your OpenVPN setup:
http://support.dlink.com/emulators/di524/help_adv.html

Perhaps that helps.

Thanks. It's really helpful to get confirmation from someone more experienced in this area.

After disabling SPI without success and placing the server in the DMZ without success, I'm also convinced it's my router. And if it's not my router, then it's possibly my ISP. (I found one post suggesting they might be doing some sort of packet filtering. Though I'm not sure why they would.)

I'm actually impressed by OpenVPN's resilience and wonder if I'd even be able to connect a PPTP or IPSec client outside of my local network. Luckily, I can still connect with an OpenVPN client outside the local network as long as it goes through the initial timeout/reconnect process.

And with any luck, I won't run into this in a production environment. The DI-524 is a decent SOHO router, but it's long been discontinued. I guess I'll just move on to the next phase of this project...

Thanks again