380.65_2 openvpn client not working with 2.3 server but 64_2 does

[manuelreinaldo]

Hi, I have a dd_wrt router with a openvpn 2.3 server and merlin 380.64_2 openvpn client. It works.

I upgraded to version 380.65_2 (with openvpn client version 2.4) and it stopped working.
It connects (according to the log) but I have not connection to the remote subnets. Both logs look very similar in fact.

These are the server and client setups as well as the logs from the Merlin 64_2 and 65_2 versions.

64_2 logs (version that works)
Mar 22 13:35:28 openvpn[927]: OpenVPN 2.3.14 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jan 7 2017
Mar 22 13:35:28 openvpn[927]: library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.08
Mar 22 13:35:28 openvpn[929]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Mar 22 13:35:28 openvpn[929]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 22 13:35:28 openvpn[929]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Mar 22 13:35:29 openvpn[929]: UDPv4 link local: [undef]
Mar 22 13:35:29 openvpn[929]: UDPv4 link remote: [AF_INET]xx
Mar 22 13:35:29 openvpn[929]: TLS: Initial packet from [AF_INET]xx, sid=xx
Mar 22 13:35:29 openvpn[929]: VERIFY OK: depth=1, C=XX, ST=XX, L=XXXX, O=XXX, OU=XXX, CN=XXX, name=XXX, emailAddress=xxx
Mar 22 13:35:29 openvpn[929]: VERIFY OK: depth=0, C=XX, ST=XX, L=XX, O=XX, OU=XX, CN=XX, name=XX, emailAddress=XX
Mar 22 13:35:30 openvpn[929]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mar 22 13:35:30 openvpn[929]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mar 22 13:35:30 openvpn[929]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 22 13:35:30 openvpn[929]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mar 22 13:35:30 openvpn[929]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mar 22 13:35:30 openvpn[929]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 22 13:35:30 openvpn[929]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Mar 22 13:35:30 openvpn[929]: [XX] Peer Connection Initiated with [AF_INET]XX.
Mar 22 13:35:33 openvpn[929]: SENT CONTROL [XX]: 'PUSH_REQUEST' (status=1)
Mar 22 13:35:33 openvpn[929]: PUSH: Received control message: 'PUSH_REPLY,route 192.168.5.0 255.255.255.0,dhcp-option DNS 192.168.5.1,sndbuf 393216,rcvbuf 393216,route-gateway 192.168.6.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.6.10 255.255.255.0'
Mar 22 13:35:33 openvpn[929]: Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS])
Mar 22 13:35:33 openvpn[929]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Mar 22 13:35:33 openvpn[929]: OPTIONS IMPORT: timers and/or timeouts modified
Mar 22 13:35:33 openvpn[929]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Mar 22 13:35:33 openvpn[929]: Socket Buffers: R=[122880->245760] S=[122880->245760]
Mar 22 13:35:33 openvpn[929]: OPTIONS IMPORT: --ifconfig/up options modified
Mar 22 13:35:33 openvpn[929]: OPTIONS IMPORT: route-related options modified
Mar 22 13:35:33 openvpn[929]: TUN/TAP device tun11 opened
Mar 22 13:35:33 openvpn[929]: TUN/TAP TX queue length set to 100
Mar 22 13:35:33 openvpn[929]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mar 22 13:35:33 openvpn[929]: /usr/sbin/ip link set dev tun11 up mtu 1500
Mar 22 13:35:33 openvpn[929]: /usr/sbin/ip addr add dev tun11 192.168.6.10/24 broadcast 192.168.6.255
Mar 22 13:35:35 openvpn[929]: /usr/sbin/ip route add 192.168.5.0/24 metric 1 via 192.168.6.1
Mar 22 13:35:35 openvpn[929]: /usr/sbin/ip route add 192.168.3.0/24 metric 1 via 192.168.6.1
Mar 22 13:35:35 openvpn-routing: Skipping, client 1 not in routing policy mode
Mar 22 13:35:35 openvpn[929]: Initialization Sequence Complete

65_2 logs (version that doesn't works)

Mar 22 13:22:19 openvpn[3360]: OpenVPN 2.4.0 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 10 2017
Mar 22 13:22:19 openvpn[3360]: library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.08
Mar 22 13:22:19 openvpn[3361]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Mar 22 13:22:19 openvpn[3361]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 22 13:22:19 openvpn[3361]: TCP/UDP: Preserving recently used remote address: [AF_INET]xx
Mar 22 13:22:19 openvpn[3361]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Mar 22 13:22:19 openvpn[3361]: UDP link local: (not bound)
Mar 22 13:22:19 openvpn[3361]: UDP link remote: [AF_INET]XX
Mar 22 13:22:19 openvpn[3361]: TLS: Initial packet from [AF_INET]XX, sid=xx
Mar 22 13:22:20 openvpn[3361]: VERIFY OK: depth=1, C=XX, ST=XX, L=XX, O=XX, OU=xx, CN=xx, name=xx, emailAddress=XX
Mar 22 13:22:20 openvpn[3361]: VERIFY OK: depth=0, C=xx, ST=xx, L=xx, O=xx, OU=xx, CN=xx, name=xx, emailAddress=xx
Mar 22 13:22:21 openvpn[3361]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Mar 22 13:22:21 openvpn[3361]: [xx] Peer Connection Initiated with [AF_INET]xx
Mar 22 13:22:22 openvpn[3361]: SENT CONTROL [xx]: 'PUSH_REQUEST' (status=1)
Mar 22 13:22:22 openvpn[3361]: PUSH: Received control message: 'PUSH_REPLY,route 192.168.5.0 255.255.255.0,dhcp-option DNS 192.168.5.1,sndbuf 393216,rcvbuf 393216,route-gateway 192.168.6.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.6.10 255.255.255.0'
Mar 22 13:22:22 openvpn[3361]: Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS])
Mar 22 13:22:22 openvpn[3361]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Mar 22 13:22:22 openvpn[3361]: OPTIONS IMPORT: timers and/or timeouts modified
Mar 22 13:22:22 openvpn[3361]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Mar 22 13:22:22 openvpn[3361]: Socket Buffers: R=[122880->245760] S=[122880->245760]
Mar 22 13:22:22 openvpn[3361]: OPTIONS IMPORT: --ifconfig/up options modified
Mar 22 13:22:22 openvpn[3361]: OPTIONS IMPORT: route-related options modified
Mar 22 13:22:22 openvpn[3361]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mar 22 13:22:22 openvpn[3361]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mar 22 13:22:22 openvpn[3361]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 22 13:22:22 openvpn[3361]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mar 22 13:22:22 openvpn[3361]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mar 22 13:22:22 openvpn[3361]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 22 13:22:22 openvpn[3361]: WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Mar 22 13:22:22 openvpn[3361]: TUN/TAP device tun11 opened
Mar 22 13:22:22 openvpn[3361]: TUN/TAP TX queue length set to 100
Mar 22 13:22:22 openvpn[3361]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mar 22 13:22:22 openvpn[3361]: /usr/sbin/ip link set dev tun11 up mtu 1500
Mar 22 13:22:22 openvpn[3361]: /usr/sbin/ip addr add dev tun11 192.168.6.10/24 broadcast 192.168.6.255
Mar 22 13:22:24 openvpn[3361]: /usr/sbin/ip route add 192.168.5.0/24 metric 1 via 192.168.6.1
Mar 22 13:22:24 openvpn[3361]: /usr/sbin/ip route add 192.168.3.0/24 metric 1 via 192.168.6.1
Mar 22 13:22:25 openvpn-routing: Skipping, client 1 not in routing policy mode
Mar 22 13:22:25 openvpn[3361]: Initialization Sequence Completed


The server configuration is:
daemon
server 192.168.6.0 255.255.255.0
proto udp
port 1194
dev tun
keepalive 10 120
verb 4
push "route 192.168.5.0 255.255.255.0"
route 192.168.4.0 255.255.255.0 192.168.6.10
duplicate-cn
push "dhcp-option DNS 192.168.5.1"
client-to-client
tun-mtu 1500
mssfix 1460
topology subnet
mute 5
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
client-config-dir /tmp/openvpn/ccd
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
dh /tmp/openvpn/dh.pem
comp-lzo

The client configuration (in both cases, 64_2 and 65_2)
proto udp
remote XX
route-nopull
route 192.168.5.0 255.255.255.0
route 192.168.3.0 255.255.255.0
port 1194
tun-mtu 1500
mssfix 1460
nobind
resolv-retry infinite
route-metric 1
float
verb 3


And also, in the client I have the option to redirect all internet traffic set to "no" and I have the option to accept DNS configuration as no.

With this, when I try to connect to any ip in 192.168.5.x or 192.168.3.x with the new firmware it doesn't work.

I reverted back to 380.64_2 and it works again.

Thanks for the help

 

[Xentrk]

Welcome to the "Used to work in OpenVPN 2.3 but does not work in OpenVPN 2.4 club"

Check out my OpenVPN client config example here and let me know that helps you. I use TorGuard but the settings have also helped some PIA customers.

https://www.snbforums.com/threads/h...oviders-10-15-fixed.30851/page-16#post-314475

With VPN Server settings on your router, I found the setting "None" no longer worked for compression. I had to choose Disabled, LZ4 or LZ0 for it to work and export a new opvn config file to my client.

 

[Martineau]

Check out my OpenVPN client config example here and let me know that helps you..

Probably me having a numpty moment , but a quick clarification if I may?

Q. Why are you promoting explicit use of the 'dhcp-option DNS' directive?

From the OpenVPN 2.4 manual:

--dhcp-option type [parm]
Set extended TAP-Win32 TCP/IP properties, must be used with --ip-win32 dynamic or --ip-win32 adaptive. This option can be used to set additional TCP/IP properties on the TAP-Win32 adapter, and is particularly useful for configuring an OpenVPN client to access a Samba server across the VPN.

Note that if --dhcp-option is pushed via --push to a non-windows client, the option will be saved in the client's environment before the up script is called, under the name "foreign_option_{n}".

Now my VPN provider supplies a dynamic DNS, which is ultimately defined/configured in the -t nat DNSVPN1 chain, so there is no point in me attempting to hard-code an unknown I/P addresses in the GUI.

Furthermore, in Syslog, my VPN server provider seems to always push the 'dhcp-option DNS xxx.xxx.xxx.xxx' directive, although it is clearly confusing when the Client states the '--ip-win32 and/or --dhcp-option options modified' ???

openvpn[23744]: OpenVPN 2.4.0 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar  6 2017
openvpn[23745]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.200.194.1
openvpn[23745]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

 

[manuelreinaldo]

Hi, thanks a lot!! it works now.
It was the compression option.
I added the comp-lzo option to the Asus client and set the compression to LZO and now both, the old, and new VPN clients work with the same setup. Also the rest of the clients still work without changing the setup.

Thanks also for the dns option. I need to do a clean-up. I removed it already. I did thousands of trials 2 years ago when I set it up and I left things that don't need to be there. I tried also tcp instead of udp. Also I connect to the dd-wrt with other devices, not only with the Asus. Some clients are very demanding as they use realtime HDTV I went crazy before it worked, for one of the clients I needed 3MB/s bandwidth with my dd-wrt router from 2012 while other clients are just iOS devices which I use for browsing.

Anyway, thanks a lot

 

[Xentrk]

Probably me having a numpty moment , but a quick clarification if I may?

Q. Why are you promoting explicit use of the 'dhcp-option DNS' directive?

From the OpenVPN 2.4 manual:

--dhcp-option type [parm]
Set extended TAP-Win32 TCP/IP properties, must be used with --ip-win32 dynamic or --ip-win32 adaptive. This option can be used to set additional TCP/IP properties on the TAP-Win32 adapter, and is particularly useful for configuring an OpenVPN client to access a Samba server across the VPN.

Note that if --dhcp-option is pushed via --push to a non-windows client, the option will be saved in the client's environment before the up script is called, under the name "foreign_option_{n}".

Now my VPN provider supplies a dynamic DNS, which is ultimately defined/configured in the -t nat DNSVPN1 chain, so there is no point in me attempting to hard-code an unknown I/P addresses in the GUI.

Furthermore, in Syslog, my VPN server provider seems to always push the 'dhcp-option DNS xxx.xxx.xxx.xxx' directive, although it is clearly confusing when the Client states the '--ip-win32 and/or --dhcp-option options modified' ???

openvpn[23744]: OpenVPN 2.4.0 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar  6 2017
openvpn[23745]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.200.194.1
openvpn[23745]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

After upgrading to OpenVPN 2.4 with the 380.65 and 380.65_2 release, I started having issues with Policy rules that I did not have before.

1. In prior OpenVPN releases, I always used the setting of “None” for Compression. This setting no longer works for me in OpenVPN 2.4. As a result, I use the default LZO Adaptive, which is the recommended setting of TorGuard.
2. I had Accept DNS Cofiguration set to “Exclusive” in prior releases. I have the VPN providers DNS servers specified on the WAN configuration tab. I use AB-Solution 3.6.5 on all my routers. I discovered that ad blocking only worked for devices connected to the WAN and not for devices connected to the VPN tunnel when Accept DNS Configuration was set to “Exclusive”. Changing Accept DNS Configuration to “Strict” solved this problem. Ad blocking now works for the WAN and VPN tunnel. I found this very strange.
3. As mentioned above, I use AB-Solution 3.6.5 on all of my routers. A few days after upgrading to 380.65, I attempted to update AB-Solution on the router with Policy Rules. I was unable to connect to the AB-Solution server to perform the update and unable to ping the server. I could on my other router though. This is a symptom of a routing issue. The other item that no longer worked was the email function built into AB-Solution. My AB-Solution email settings are the same on the router with Redirect Internet traffic set to ALL, and on the router with Redirect Internet traffic set to Policy Rules. Having the dhcp-option DNS setting in the Custom Configuration section resolved these two issues. I shared this with a PIA customer and he sent me a very thankful PM. He had struggled in getting his set up to work and this fixed the problem for him. He also shared it with PIA support and they said many others are contacting them with this issue as well.

On my pfSense appliance, I also had to specify the DNS servers of Torguard in the Additional Configuration section to get it to work. And that is still OpenVPN 2.3. Never had to do that on the ASUS routers before. I don't have to specify this on the AC88U router I have set for All Traffic running OpenVPN 2.4.

I am open to any and all recommendations. I struggled to get this working right and found the settings above fixed the issues for me. I am finalizing a guide based on what I have found as I have see many posts the past few weeks with others trying to get it to work. Would you be open to reviewing it? If so, I'll send you a link to the pdf on my dropbox account. Best Regards!

 

[Xentrk]

Hi, thanks a lot!! it works now.
It was the compression option.
I added the comp-lzo option to the Asus client and set the compression to LZO and now both, the old, and new VPN clients work with the same setup. Also the rest of the clients still work without changing the setup.

Thanks also for the dns option. I need to do a clean-up. I removed it already. I did thousands of trials 2 years ago when I set it up and I left things that don't need to be there. I tried also tcp instead of udp. Also I connect to the dd-wrt with other devices, not only with the Asus. Some clients are very demanding as they use realtime HDTV I went crazy before it worked, for one of the clients I needed 3MB/s bandwidth with my dd-wrt router from 2012 while other clients are just iOS devices which I use for browsing.

Anyway, thanks a lot

You're Welcome! Glad it worked for you and thank you for the feedback. Funny how one setting can make it work or not work.