What's new

OpenVPN Can't Connect from LAN

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

KrisS

Occasional Visitor
I need to leave VPN enabled from WAN to LAN. WAN works fine, LAN does not. It works with the OEM firmware, but it looks like WRT-Merlin has some issue with LAN. On LAN fail, the client log shows:

2019-12-28 10:42:03 ----- OpenVPN Start ----- OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28
2019-12-28 10:42:03 OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28
2019-12-28 10:42:03 Frame=512/2048/512 mssfix-ctrl=1250
2019-12-28 10:42:03 UNUSED OPTIONS
5 [ncp-ciphers] [AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC]
15 [resolv-retry] [infinite]
16 [nobind]
2019-12-28 10:42:03 EVENT: RESOLVE
2019-12-28 10:42:03 Contacting [router wan address removed]:1300/UDP via UDP
2019-12-28 10:42:03 EVENT: WAIT
2019-12-28 10:42:03 Connecting to [ddnsremoved]:1300 (router wan address removed) via UDPv4
2019-12-28 10:42:13 Server poll timeout, trying next remote entry...
2019-12-28 10:42:13 EVENT: RECONNECTING
2019-12-28 10:42:13 EVENT: RESOLVE
2019-12-28 10:42:13 Contacting [router wan address removed]:1300/UDP via UDP
2019-12-28 10:42:13 EVENT: WAIT
2019-12-28 10:42:13 Connecting to [ddnsremoved]:1300 (router wan address removed) via UDPv4

The router log shows:
Dec 28 10:55:30 ovpn-server1[13681]: MULTI: multi_create_instance called
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 Re-using SSL/TLS context
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server'
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 UDPv4 READ [14] from [AF_INET]192.168.0.143:52687: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 TLS: Initial packet from [AF_INET]192.168.0.143:52687, sid=3829896b cdce2f1e
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 UDPv4 WRITE [26] to [AF_INET]192.168.0.143:52687: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Dec 28 10:55:31 ovpn-server1[13681]: 192.168.0.143:52687 UDPv4 READ [14] from [AF_INET]192.168.0.143:52687: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Dec 28 10:55:31 ovpn-server1[13681]: 192.168.0.143:52687 UDPv4 WRITE [22] to [AF_INET]192.168.0.143:52687: P_ACK_V1 kid=0 [ 0 ]
Dec 28 10:55:32 ovpn-server1[13681]: 192.168.0.143:52687 UDPv4 READ [14] from [AF_INET]192.168.0.143:52687: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Read/Write, Hard Reset received many times.


Any input is appreciated.
 

Attachments

  • upload_2019-12-28_10-51-37.png
    upload_2019-12-28_10-51-37.png
    49.9 KB · Views: 403
Last edited:
2019-12-28 10:42:03 ----- OpenVPN Start ----- OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28
2019-12-28 10:42:03 OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28

Retest with released code. OpenVPN 3.x is very early alpha code, and is missing many features from the 2.x release branch.
 
I see, thanks. My router is an AX88U, and I am using firmware 384.14. I see the change log shows - UPDATED: OpenVPN 2.4.8. Thus the version concern is with the IOS client? The same client works with the OEM firmware anyway. I'll check the app history and see if there is an way I can downgrade, but confidence is not great.
 
Last edited:
Thus the version concern is with the IOS client?

That's correct. I'm surprised someone ship a production application with alpha-level code. So, I would eliminate that variable first.

Also check what kind of restrictions iOS might impose on custom routes. I know it works fine with Android, but I have no idea about iOS.
 
I need to leave VPN enabled from WAN to LAN. WAN works fine, LAN does not. It works with the OEM firmware, but it looks like WRT-Merlin has some issue with LAN. On LAN fail, the client log shows:

2019-12-28 10:42:03 ----- OpenVPN Start ----- OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28
2019-12-28 10:42:03 OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28
2019-12-28 10:42:03 Frame=512/2048/512 mssfix-ctrl=1250
2019-12-28 10:42:03 UNUSED OPTIONS
5 [ncp-ciphers] [AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC]
15 [resolv-retry] [infinite]
16 [nobind]
2019-12-28 10:42:03 EVENT: RESOLVE
2019-12-28 10:42:03 Contacting [router wan address removed]:1300/UDP via UDP
2019-12-28 10:42:03 EVENT: WAIT
2019-12-28 10:42:03 Connecting to [ddnsremoved]:1300 (router wan address removed) via UDPv4
2019-12-28 10:42:13 Server poll timeout, trying next remote entry...
2019-12-28 10:42:13 EVENT: RECONNECTING
2019-12-28 10:42:13 EVENT: RESOLVE
2019-12-28 10:42:13 Contacting [router wan address removed]:1300/UDP via UDP
2019-12-28 10:42:13 EVENT: WAIT
2019-12-28 10:42:13 Connecting to [ddnsremoved]:1300 (router wan address removed) via UDPv4

The router log shows:
Dec 28 10:55:30 ovpn-server1[13681]: MULTI: multi_create_instance called
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 Re-using SSL/TLS context
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server'
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 UDPv4 READ [14] from [AF_INET]192.168.0.143:52687: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 TLS: Initial packet from [AF_INET]192.168.0.143:52687, sid=3829896b cdce2f1e
Dec 28 10:55:30 ovpn-server1[13681]: 192.168.0.143:52687 UDPv4 WRITE [26] to [AF_INET]192.168.0.143:52687: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Dec 28 10:55:31 ovpn-server1[13681]: 192.168.0.143:52687 UDPv4 READ [14] from [AF_INET]192.168.0.143:52687: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Dec 28 10:55:31 ovpn-server1[13681]: 192.168.0.143:52687 UDPv4 WRITE [22] to [AF_INET]192.168.0.143:52687: P_ACK_V1 kid=0 [ 0 ]
Dec 28 10:55:32 ovpn-server1[13681]: 192.168.0.143:52687 UDPv4 READ [14] from [AF_INET]192.168.0.143:52687: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Read/Write, Hard Reset received many times.


Any input is appreciated.
Not sure if this is your problem, but in my openvpn configuration for my clients, I always ensure 'float' isn't specified (i.e. is commented out) - the float option "allows authenticated packets from any address, not only the address specified by remote". So if I connect from inside my LAN, it first connects to the router WAN address, then it tries to switch to the LAN address for the router, so it fails. What happens if you add the float option to your iOS client configuration?

It's a shot in the dark, maybe ASUS' firmware OpenVPN doesn't try to switch to the LAN address and @RMerlin's does???
 
I deleted the float entry, but got the same result unfortunately. Thank-you though. I also tried an .ovpn file from the Merlin firmware (former was from the Asus firmware), and got the same result.

I also tried the Passepartout IOS client, but got the same result as follows:
11:35:46 - Starting tunnel...
11:35:46 - App version: Passepartout 1.10.1 (2263)
11:35:46 - Protocols: [UDP:1300]
11:35:46 - Cipher: AES-256-CBC
11:35:46 - Digest: HMAC-SHA512
11:35:46 - Compression framing: disabled
11:35:46 - Compression algorithm: disabled
11:35:46 - Client verification: enabled
11:35:46 - TLS wrapping: disabled
11:35:46 - TLS security level: 0
11:35:46 - Keep-alive interval: never
11:35:46 - Keep-alive timeout: never
11:35:46 - Renegotiation: never
11:35:46 - Server EKU verification: disabled
11:35:46 - Gateway: not configured
11:35:46 - DNS: not configured
11:35:46 - MTU: 1250
11:35:46 - Debug: true
11:35:46 - Masks private data: true
11:35:46 - Creating link session
11:35:46 - DNS resolve hostname: <masked>
11:35:47 - DNS resolved addresses: ["<masked>"]
11:35:47 - Will connect to <masked>:1300
11:35:47 - Socket type is NEUDPSocket
11:35:47 - Socket state is ready (endpoint: <masked> -> <masked>)
11:35:47 - Starting VPN session
11:35:47 - Send hard reset
11:35:47 - Negotiation key index is 0
11:35:47 - Control: Enqueued 1 packet [0]
11:35:47 - Control: Write control packet {HARD_RESET_CLIENT_V2 | 0, sid: 57da280c023a086d, pid: 0, [0 bytes]}
11:35:47 - Send control packet (14 bytes): 3857da280c023a086d0000000000
11:35:47 - Control: Write control packet {HARD_RESET_CLIENT_V2 | 0, sid: 57da280c023a086d, pid: 0, [0 bytes]}
11:35:47 - Send control packet (14 bytes): 3857da280c023a086d0000000000

I noted: HARD_RESET_CLIENT_V2. I don't know if that means its code is based on OpenVPN v2 code.

I had this same issue when I used Merlin on my former AC5300 router. That was likely before the v3 alpha in the IOS client. I posed the issue on the OpenVPN forum, and received a reply that the issue may be because hair-pinning is likely supported/configured on the OEM firmware, but not the present firmware. I Googled, but a means of configuring such was elusive.

I don't know if it is at all relevant, but I found this old reference on a site "Fortunately Merlin had recently added a build for the AC86u, which I downloaded and tried out. It didn't do NAT reflection either. I found out that the "Asus NAT Loopback" function had done it, but had been removed because the firewall rules were getting too complex and it wasn't working reliably."

I love the Merlin code (and support) otherwise, though it looks like all roads may be leading to Rome for this particular challenge.
 
Last edited:
I deleted the float entry, but got the same result unfortunately. Thank-you though. I also tried an .ovpn file from the Merlin firmware (former was from the Asus firmware), and got the same result.

I also tried the Passepartout IOS client, but got the same result as follows:
11:35:46 - Starting tunnel...
11:35:46 - App version: Passepartout 1.10.1 (2263)
11:35:46 - Protocols: [UDP:1300]
11:35:46 - Cipher: AES-256-CBC
11:35:46 - Digest: HMAC-SHA512
11:35:46 - Compression framing: disabled
11:35:46 - Compression algorithm: disabled
11:35:46 - Client verification: enabled
11:35:46 - TLS wrapping: disabled
11:35:46 - TLS security level: 0
11:35:46 - Keep-alive interval: never
11:35:46 - Keep-alive timeout: never
11:35:46 - Renegotiation: never
11:35:46 - Server EKU verification: disabled
11:35:46 - Gateway: not configured
11:35:46 - DNS: not configured
11:35:46 - MTU: 1250
11:35:46 - Debug: true
11:35:46 - Masks private data: true
11:35:46 - Creating link session
11:35:46 - DNS resolve hostname: <masked>
11:35:47 - DNS resolved addresses: ["<masked>"]
11:35:47 - Will connect to <masked>:1300
11:35:47 - Socket type is NEUDPSocket
11:35:47 - Socket state is ready (endpoint: <masked> -> <masked>)
11:35:47 - Starting VPN session
11:35:47 - Send hard reset
11:35:47 - Negotiation key index is 0
11:35:47 - Control: Enqueued 1 packet [0]
11:35:47 - Control: Write control packet {HARD_RESET_CLIENT_V2 | 0, sid: 57da280c023a086d, pid: 0, [0 bytes]}
11:35:47 - Send control packet (14 bytes): 3857da280c023a086d0000000000
11:35:47 - Control: Write control packet {HARD_RESET_CLIENT_V2 | 0, sid: 57da280c023a086d, pid: 0, [0 bytes]}
11:35:47 - Send control packet (14 bytes): 3857da280c023a086d0000000000

I noted: HARD_RESET_CLIENT_V2. I don't know if that means its code is based on OpenVPN v2 code.

I had this same issue when I used Merlin on my former AC5300 router. That was likely before the v3 alpha in the IOS client. I posed the issue on the OpenVPN forum, and received a reply that the issue may be because hair-pinning is likely supported/configured on the OEM firmware, but not the present firmware. I Googled, but a means of configuring such was elusive.

I don't know if it is at all relevant, but I found this old reference on a site "Fortunately Merlin had recently added a build for the AC86u, which I downloaded and tried out. It didn't do NAT reflection either. I found out that the "Asus NAT Loopback" function had done it, but had been removed because the firewall rules were getting too complex and it wasn't working reliably."

I love the Merlin code (and support) otherwise, though it looks like all roads may be leading to Rome for this particular challenge.
Sorry, I worded my response very poorly. You need to ensure you have "float" enabled when the address of the VPN server will change during the session. You already did apparently, so that wasn't the issue (as you found out).
 
DonnyJohnny nailed it, thanks!

I made the simple custom configuration DDNS entry: local (ddns name) and it works from LAN now too.

The CPU utilization is clearly higher with Core 2 now hitting 100% vs. <30% working on OEM, but that artifact is not terribly concerning. I don't understand why it is so high even if I turn off AI and firewall, but anyway... With OpenVPN I am still hitting 130M throughput with AI off, and about 75M with AI on (at ~50' from the router). Not bad.
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top