Ovpn on Asus routers only connects via LAN

[wolfpack]

Hi, I have an ASUS AX86U running Merlin, with OVPN server enabled. My Android phone connects fine remotely.

I just gave an older AC68U running dd-wrt to an uncle who is traveling and would benefit from being able to tunnel through my home connection, so I set it up as a client and verified it worked (from within my house, therefore hairpinning from my own LAN) before handing it off to him.

Now when he plugs it in to his remote connection (currently an airbnb, either using or, I think, bypassing that location's router), it connects most of the way but fails at the "TLS key negotiation" stage, which from what I can tell from copious threads, is typically a server-side problem. This is surprising because (a) it works for my phone and (b) the server router is direct on my home fiber connection, there's no firewall in front and it doesn't seem like I need to manually forward ports to itself. Could it be a client-side problem, like he's actually going through another router there that could block it at this step?

Any suggestions? I'd really like to solve this on my server-side only if possible, so I don't have to walk my uncle through connecting to the client's router config page and making changes.

Thanks!

Spoiler: logs

Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 TLS: Initial packet from [AF_INET]aaa.bbb.ccc.ddd:33540 (via [AF_INET]w.x.y.z%eth0), sid=75891fcb d3044d1b
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=RT-AX86U, emailAddress=me@asusrouter.lan
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=client, emailAddress=me@asusrouter.lan
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 peer info: IV_VER=2.5.7
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 peer info: IV_PLAT=linux
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 peer info: IV_PROTO=6
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 peer info: IV_NCP=2
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 peer info: IV_LZ4=1
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 peer info: IV_LZ4v2=1
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 peer info: IV_LZO=1
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 peer info: IV_COMP_STUB=1
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 peer info: IV_COMP_STUBv2=1
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 peer info: IV_TCPNL=1
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 TLS: Username/Password authentication succeeded for username 'Remote'
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1601', remote='link-mtu 1549'
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]'
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 1024 bit RSA, signature: RSA-SHA1
Jul  1 20:17:46 ovpn-server1[14651]: aaa.bbb.ccc.ddd:33540 [client] Peer Connection Initiated with [AF_INET]aaa.bbb.ccc.ddd:33540 (via [AF_INET]w.x.y.z%eth0)
Jul  1 20:17:46 ovpn-server1[14651]: client/aaa.bbb.ccc.ddd:33540 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Jul  1 20:17:46 ovpn-server1[14651]: client/aaa.bbb.ccc.ddd:33540 MULTI: Learn: 10.8.0.2 -> client/aaa.bbb.ccc.ddd:33540
Jul  1 20:17:46 ovpn-server1[14651]: client/aaa.bbb.ccc.ddd:33540 MULTI: primary virtual IP for client/aaa.bbb.ccc.ddd:33540: 10.8.0.2
Jul  1 20:17:46 ovpn-server1[14651]: client/aaa.bbb.ccc.ddd:33540 Data Channel: using negotiated cipher 'AES-256-GCM'
Jul  1 20:17:46 ovpn-server1[14651]: client/aaa.bbb.ccc.ddd:33540 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jul  1 20:17:46 ovpn-server1[14651]: client/aaa.bbb.ccc.ddd:33540 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jul  1 20:17:46 ovpn-server1[14651]: client/aaa.bbb.ccc.ddd:33540 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0 vpn_gateway 500,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 15,ping-restart 60,ifconfig 10.8.0.2 255.255.255.0,peer-id 1,cipher AES-256-GCM' (status=1)
Jul  1 20:18:43 ovpn-server1[14651]: aaa.bbb.ccc.ddd:41782 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jul  1 20:18:43 ovpn-server1[14651]: aaa.bbb.ccc.ddd:41782 TLS Error: TLS handshake failed

 

[eibgrad]

Hairpinning (aka, nat loopback) doesn't prove much of anything. When an OpenVPN server is accessed from inside the LAN on which it's running, depending on exactly how you tested it, it may either bypass the VPN, or worse, hang. The *only* valid test is when the OpenVPN client is actually outside your WAN, such as using a smartphone on the cellular network. If you don't, then you risk ending up w/ your current situation. I realize that's somewhat problematic given the OpenVPN client is married to a router. But nonetheless, you need to find a way.

Since the syslog at least shows the attempt is being made, we know it's NOT a failure to reach the server. I can see the negotiated options being push'd to the client, but the client never responds further.

It might help to see the client's syslog. And yes, even the dd-wrt configuration, in case there's a mismatch of some kind. That's particularly easy to do w/ dd-wrt since it doesn't have an import feature for the client config. You have to configure BY HAND, which is error prone.

 

[eibgrad]

P.S. The dd-wrt syslog can be had from the following command (filtered for openvpn specific messages).

grep openvpn //var//log//messages

I had to use // instead of / to get past the forum filters. Either works.

 

[wolfpack]

Thanks, I'll probably have to put off this investigation for a future time (or maybe his next airbnb will just work). His main client device motivating this is an appleTV, and while he has an ipad with him, I don't think he'll be up for troubleshooting. In hindsight this would have been a reasonable case to allow external management access, since I can see his IP.

I get you about testing externally, it's always worked with my phone, and I did have to work through dd-wrt client settings tweaks to negotiate crypto until finally I saw traffic flowing over the tunnel, so I hoped I was in the clear. This had just come up with an hour to try to work something out as he passed through town so no opportunity to go elsewhere, (and I wasn't up for trying to have the client router get online via cell hotspot, when the cellLTE is itself hosted by a femtocell tunneling through my same router! 9"hey, why is MTU = 1?" ;-)