Migration OpenVPN RT N66U -> Rt AC86U, connection problems, running MERLIN firmware

[bobby]

Until last week, we had a company router RT-N66U running the latest Merlin firmware. On this router we ran an OpenVPN server, connecting two off-site devices:

· 1 x RT N66U running merlin firmware, connecting as a client

· 1 x Yealink phone T21P, connecting as a client.

We migrated our company router from a RT N66U to a RT AC86U. I installed the latest Merlin firmware on this router (384.5) I exported the settings from the RT-N66U to the RT-AC86U. Everything worked fine, both OpenVPN clients connected again after the upgrade.

However, there was one problem. There was no traffic between the phone and the new router. I could not reach the web interface of the phone from the new router. The phone did not connect to our PBX behind the new router.

Strange thing is that the off-site RT-N66U connects fine to the new RT-AC86U. I can reach the Web Interface through the VPN, and also all devices behind that router without any problems.

It is just the phone that is the problem.

Settings on the RT-AC86U are as follows:

Interface type: TAP
Protocol: UTP
Server port 1194
Authorization mode: TLS
Username/password: no
TLS control channel security: disable
HMAC Authorization: default
Allocate from DHCP: no
Clien pool address: 192.168.1.200 192.168.1.240
Advertise DNS to clients: yes
Cipher Negotiation: Enable with fallback
Negotiable Ciphers: AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
Legacy/fallback cipher: BF-CBC
Compression LZO
Log verbosity 3
Manage client-Specific Options yes
Allow client-client yes
Allow only specified clients no

Custom configuration
keepalive 1 180
duplicate-cn
----------------------------------end of OpenVPN Server Settings---------------------


IP Address RT-N66U /client: 5.x.x.96 (received IP address 192.168.1.201, as shown below)
IP address Yealink phone /client: 86.x.x.20 (received IP address 192.168.1.202, as shown below)

This is the most recent log file of the RT-AC86U for both client devices:

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 TLS: Initial packet from [AF_INET]5.x.x.96:42532, sid=405b7669 f773c715

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=ASUS, CN=RT-N66U, emailAddress=me@myhost.mydomain

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, CN=client, emailAddress=me@myhost.mydomain

Jun 30 16:53:23 ovpn-server1[28225]: client/158.181.97.120:1029 MULTI: Learn: 00:ff:e5:c1:24:23 -> client/158.181.97.120:1029

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 peer info: IV_VER=2.4.3

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 peer info: IV_PLAT=linux

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 peer info: IV_PROTO=2

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 peer info: IV_NCP=2

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 peer info: IV_LZ4=1

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 peer info: IV_LZ4v2=1

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 peer info: IV_LZO=1

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 peer info: IV_COMP_STUB=1

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 peer info: IV_COMP_STUBv2=1

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 peer info: IV_TCPNL=1

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA

Jun 30 16:53:23 ovpn-server1[28225]: 5.x.x.96:42532 [client] Peer Connection Initiated with [AF_INET]5.x.x.96:42532

Jun 30 16:53:23 ovpn-server1[28225]: client/5.x.x.96:42532 MULTI_sva: pool returned IPv4=192.168.1.201, IPv6=(Not enabled)

Jun 30 16:53:24 ovpn-server1[28225]: client/5.x.x.96:42532 PUSH: Received control message: 'PUSH_REQUEST'

Jun 30 16:53:24 ovpn-server1[28225]: client/5.x.x.96:42532 SENT CONTROL [client]: 'PUSH_REPLY,dhcp-option DNS 192.168.1.1,route-gateway 192.168.1.1,ping 1,ping-restart 180,ifconfig 192.168.1.201 255.255.255.0,peer-id 2,cipher AES-128-GCM' (status=1)

Jun 30 16:53:24 ovpn-server1[28225]: client/5.x.x.96:42532 Data Channel: using negotiated cipher 'AES-128-GCM'

Jun 30 16:53:24 ovpn-server1[28225]: client/5.x.x.96:42532 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key

Jun 30 16:53:24 ovpn-server1[28225]: client/5.x.x.96:42532 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key

Jun 30 16:53:26 ovpn-server1[28225]: client/5.x.x.96:42532 MULTI: Learn: e0:3f:49:6a:e0:c0 -> client/5.x.x.96:42532

Jun 30 16:53:26 ovpn-server1[28225]: client/5.x.x.96:42532 MULTI: Learn: 00:ff:51:e6:bb:c8 -> client/5.x.x.96:42532

Jun 30 16:53:26 ovpn-server1[28225]: client/5.x.x.96:42532 MULTI: Learn: 00:0e:08:dd:ea:65 -> client/5.x.x.96:42532

Jun 30 16:53:31 ovpn-server1[28225]: 86.x.x.20:1030 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=ASUS, CN=RT-N66U, emailAddress=me@myhost.mydomain

Jun 30 16:53:31 ovpn-server1[28225]: 86.x.x.20:1030 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, CN=client, emailAddress=me@myhost.mydomain

Jun 30 16:53:31 ovpn-server1[28225]: 86.x.x.20:1030 Outgoing Data Channel: Cipher 'BF-CBC' initialized with 128 bit key

Jun 30 16:53:31 ovpn-server1[28225]: 86.x.x.20:1030 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).

Jun 30 16:53:31 ovpn-server1[28225]: 86.x.x.20:1030 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication

Jun 30 16:53:31 ovpn-server1[28225]: 86.x.x.20:1030 Incoming Data Channel: Cipher 'BF-CBC' initialized with 128 bit key

Jun 30 16:53:31 ovpn-server1[28225]: 86.x.x.20:1030 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).

Jun 30 16:53:31 ovpn-server1[28225]: 86.x.x.20:1030 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication

Jun 30 16:53:31 ovpn-server1[28225]: 86.x.x.20:1030 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.

Jun 30 16:53:31 ovpn-server1[28225]: 86.x.x.20:1030 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

Jun 30 16:53:31 ovpn-server1[28225]: 86.x.x.20:1030 [client] Peer Connection Initiated with [AF_INET]86.x.x.20:1030

Jun 30 16:53:31 ovpn-server1[28225]: client/86.x.x.20:1030 MULTI_sva: pool returned IPv4=192.168.1.202, IPv6=(Not enabled)

Jun 30 16:53:33 ovpn-server1[28225]: client/86.x.x.20:1030 PUSH: Received control message: 'PUSH_REQUEST'

Jun 30 16:53:33 ovpn-server1[28225]: client/86.x.x.20:1030 SENT CONTROL [client]: 'PUSH_REPLY,dhcp-option DNS 192.168.1.1,route-gateway 192.168.1.1,ping 1,ping-restart 180,ifconfig 192.168.1.202 255.255.255.0' (status=1)

Jun 30 16:53:34 ovpn-server1[28225]: client/86.x.x.20:1030 MULTI: Learn: 00:ff:68:f9:93:24 -> client/86.x.x.20:1030

------------end of log file--------------------------

Note: I realize that the Yealink uses an old encryption method that can be hacked with the SWEET32 method. However, the phone does not support SHA256, and from what I understand a hacker can decipher text as a “man in the middle”. This is just audio traffic so nothing secret. It is the plan to replace the phones at one point, but not now.

Question: why does the Yealink phone log on properly, is assigned an IP address but there is no traffic?

Thanks in advance!!

 

[bobby]

New information:

I just found out that the IP phone client gets 2 ip addresses from the new RT-AC86U router:

192.168.1.6 + 192.168.1.201

As written above, the VPN server is supposed to use 192.168.1.200-192.168.1.220

Why does the router assign a second IP address outside the range? Could this be the reason that there is no traffic?

 

[kfp]

I just found out that the IP phone client gets 2 ip addresses from the new RT-AC86U router:

192.168.1.6 + 192.168.1.201

As written above, the VPN server is supposed to use 192.168.1.200-192.168.1.220

Why does the router assign a second IP address outside the range? Could this be the reason that there is no traffic?

192.168.1.6 is probably given to it by the router it is connected to for the Internet connection in the first place?

By using the same subnet the phone is probably just not routing any traffic through the VPN tunnel at all. Try using a different subnet for OpenVPN?

 

[ColinTaylor]

By using the same subnet the phone is probably just not routing any traffic through the VPN tunnel at all. Try using a different subnet for OpenVPN?

He's using a TAP interface so it's bridged not routed. But yes, it's seems likely that the 192.168.1.6 address was picked up from whatever the phone was connected to prior to the VPN.

 

[bobby]

Hi Collin & kpf,
thanks very much for your response.

it sounds like the fact that the new router shows "2 clients are connecting to the AC86U through this device" is nothing alarming, in your opinion.

So I need to look further. Is there any log file or something, that could help me find the problem?

Shall I set up a second VPN Server with the exact same keys and certificates, on the same router for testing purposes?
This VPN Server was set up with a settings transfer from a N66U.
Perhaps a fresh install will make a difference? Some settings did not transfer, perhaps?
I tried to read the cfg file that I used to transfer the settings to the new router, but it it is a binary file, so nothing to see there.

 

[ColinTaylor]

This VPN Server was set up with a settings transfer from a N66U.
Perhaps a fresh install will make a difference? Some settings did not transfer, perhaps?
I tried to read the cfg file that I used to transfer the settings to the new router, but it it is a binary file, so nothing to see there.

How did you transfer your settings from the old router? Are you talking about just the VPN settings or the "Save Settings" file for the whole router (Administration - Restore/Save/Upload Setting)? You must never use the later to transfer settings to a different router, not even a router of the same model.

 

[kfp]

it sounds like the fact that the new router shows "2 clients are connecting to the AC86U through this device" is nothing alarming, in your opinion.

So I need to look further. Is there any log file or something, that could help me find the problem?

Are you connecting both N66 and IP phone as clients to the 86U VPN server? That might be a problem and it’s not necessary (for your usecase I think).

Also as I’ve said before, use a different subnet for OpenVPN (something other than 192.168.1.x).

 

[ColinTaylor]

Also as I’ve said before, use a different subnet for OpenVPN (something other than 192.168.1.x).

Why? He can't do that without changing the subnets at both ends. As I mentioned in post #4, he's not using routed connection.

 

[kfp]

Why? He can't do that without changing the subnets at both ends. As I mentioned in post #4, he's not using routed connection.

Of course, you’re right. Saw your comment but didn’t fully understand it since most of my experiences were with TUN. Schooled.

 

[bobby]

I must admit that I used "Save Settings" file for the whole router (Administration - Restore/Save/Upload Setting) to transfer the settings.

I first tried to set up the router manually, but could not get the VPN server to work. Then, when I used the above mentioned method, it actually worked for at least one client. The other client connected although there was no traffic. All other things worked properly!

Shall I set it up manually again, with full wipe & fresh install of the router?
Do you know how to transfer VPN server settings from a N66U to a AC86U?