Asus Merlin VPN issues since updating to 386.1_2 and 386.2

[michaels2408]

Good day all,
I recently updated my Asus RT-AC3100 to the 386.1 --> 386.1_2 then again to the 386.2 firmware. In each case I flashed, then factory reset and rentered the settings from scratch. The only backup setting utilized would be Lan IP assignments using YazDHCP. At first, post install 386.2, my open VPN server would hang on reboot. This has since resolved, however, the VPN server hangs randomly after about 24hrs up and has to be restarted. This behavior is new as I never had an issue with the openVPN server in the prior firmware. I will also say I didn't have this issue with 386.1 . Seems to have started plaguing my router with the 386.1_2 when OpenVPN was updated to 2.5.1 .
Has anyone else experienced this? It's frustrating to get to work and have no VPN access.
I looked for openvpn.log - does not exist. Checked other system logs and did not see any reference to openvpn servers.

Thanks,
Mike

 

[MvW]

OpenVPN logs by default, assuming you didn't install syslog-ng and (ui)Scribe, to the default system log in /opt/var/log/messages (which is a symlink to /tmp/syslog.log). If you open the WebUI and scroll down, you'll find at the left column, near the end, a menu item called System Log. If you select that, on the right your system log appears. Search for clues which start with openvpn-client or openvpn, to find out what's happening. Although I'm using a different model, I don't experience issues with my VPN.

 

[kernol]

OpenVPN logs by default, assuming you didn't install syslog-ng and (ui)Scribe, to the default system log in /opt/var/log/messages (which is a symlink to /tmp/syslog.log). If you open the WebUI and scroll down, you'll find at the left column, near the end, a menu item called System Log. If you select that, on the right your system log appears. Search for clues which start with openvpn-client or openvpn, to find out what's happening. Although I'm using a different model, I don't experience issues with my VPN.

View attachment 33233

@MvW - off topic - just curious - how did you produce that blurred area in your image?? Care to share?

 

[MvW]

@MvW - off topic - just curious - how did you produce that blurred area in your image?? Care to share?

It's a secret.

But because no one is watching I'll let you in on it...

Well, you take a piece of fine sandpaper and a monitor...

No, just kidding. I use good ol' Irvanview as my image viewer on my laptop, it has a boatload of plugins and effects. By default you can use the cursor to select a rectangular piece of the image and if you hit CTRL-E (which brings up the effect browser) and select 'Gaussian Blur' you can use it to hide sensitive info. Make sure you download the 32 bit version of the program and the 32-bit pluging pack, as not every plugin is and will be available for 64 bit. Unless you want to work with huge files, but then you can even install them both in seperate folders.

Cheers,
Marco

 

[kernol]

It's a secret.

But because no one is watching I'll let you in on it...

Well, you take a piece of fine sandpaper and a monitor...

No, just kidding. I use good ol' Irvanview as my image viewer on my laptop, it has a boatload of plugins and effects. By default you can use the cursor to select a rectangular piece of the image and if you hit CTRL-E (which brings up the effect browser) and select 'Gaussian Blur' you can use it to hide sensitive info. Make sure you download the 32 bit version of the program and the 32-bit pluging pack, as not every plugin is and will be available for 64 bit. Unless you want to work with huge files, but then you can even install them both in seperate folders.

Cheers,
Marco

Many thanks - got it and donated ... always enjoy supporting coders who make such stuff.

 

[RMerlin]

I use Greenshot here. It has a built-in editor, allowing you to cut, highlight, or blur as needed.

 

[michaels2408]

The issue happened again today. Router up since Sunday 4/18/21 @ 0630am (weekly reboot). Tonight @ 9pm saw this.

Only reference to VPN is the log was today April 19th 15:58
Apr 19 15:58:49 router ovpn-server1[5752]: 139.177.207.13:46894 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Apr 19 15:58:49 router ovpn-server1[5752]: 139.177.207.13:46894 TLS Error: TLS handshake failed
Apr 19 15:58:49 router ovpn-server1[5752]: 139.177.207.13:46894 SIGUSR1[soft,tls-error] received, client-instance restarting

I will say that 139.177.207.13 has no business trying to connect to my VPN.

 

[eibgrad]

The issue happened again today. Router up since Sunday 4/18/21 @ 0630am (weekly reboot). Tonight @ 9pm saw this.
View attachment 33310
View attachment 33311
Only reference to VPN is the log was today April 19th 15:58
Apr 19 15:58:49 router ovpn-server1[5752]: 139.177.207.13:46894 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Apr 19 15:58:49 router ovpn-server1[5752]: 139.177.207.13:46894 TLS Error: TLS handshake failed
Apr 19 15:58:49 router ovpn-server1[5752]: 139.177.207.13:46894 SIGUSR1[soft,tls-error] received, client-instance restarting

I will say that 139.177.207.13 has no business trying to connect to my VPN.

How is this the same as your original issue? This simply appears to be someone trying to gain access, apparently unsuccessfully. Not uncommon if you choose the well-known port of 1194 (and why it's NOT recommended).

As far as your hanging OpenVPN server, are you perhaps also running an OpenVPN client at the same time? Sometimes the tunnel IP networks conflict (e.g., 10.8.0.0/24).

 

[RMerlin]

Only reference to VPN is the log was today April 19th 15:58
Apr 19 15:58:49 router ovpn-server1[5752]: 139.177.207.13:46894 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Apr 19 15:58:49 router ovpn-server1[5752]: 139.177.207.13:46894 TLS Error: TLS handshake failed
Apr 19 15:58:49 router ovpn-server1[5752]: 139.177.207.13:46894 SIGUSR1[soft,tls-error] received, client-instance restarting

That was the missing key to this old issue of the server reporting a client TLS error message. The OpenVPN error handling that deals with remote clients failing their TLS handshake seem to be the same as if it was the local OpenVPN that was running as a client, that's how the server ends up with the bogus "Still initializing" state.

You can just ignore the "still initializing" message, or if you want to clear it, just restart your OpenVPN server instance (and moving to a less popular port than 1194 will also help reducing these port scans that are hitting it and triggering the bogus error message).

 

[JohnD5000]

That was the missing key to this old issue of the server reporting a client TLS error message. The OpenVPN error handling that deals with remote clients failing their TLS handshake seem to be the same as if it was the local OpenVPN that was running as a client, that's how the server ends up with the bogus "Still initializing" state.

You can just ignore the "still initializing" message, or if you want to clear it, just restart your OpenVPN server instance (and moving to a less popular port than 1194 will also help reducing these port scans that are hitting it and triggering the bogus error message).

Is there a recommended port to use instead of default 1194? Or is there a OK range to use?

 

[RMerlin]

Is there a recommended port to use instead of default 1194? Or is there a OK range to use?

Usually, it's best to use a high numbered port, as these are not reserved for specific services, and therefore are rarely likely to get scanned. Can be 51194 for instance, if you want something easy to remember (you just added a "5" in front of the standard 1194).

Valid ports are between 1024 and 65535.

The bogus error report has been fixed on my end, and will be included in a future release.

 

[JohnD5000]

Usually, it's best to use a high numbered port, as these are not reserved for specific services, and therefore are rarely likely to get scanned. Can be 51194 for instance, if you want something easy to remember (you just added a "5" in front of the standard 1194).

Valid ports are between 1024 and 65535.

The bogus error report has been fixed on my end, and will be included in a future release.

Thanks

 

[CaptainSTX]

You can just ignore the "still initializing" message, or if you want to clear it, just restart your OpenVPN server instance (and moving to a less popular port than 1194 will also help reducing these port scans that are hitting it and triggering the bogus error message).

I run two VPN clients and one VPN server. For the last several versions of your firmware I persistently have the spinning wheel and the still intializing message. It is a minor irritation as the VPN server works just fine.

One of the VPN clients was using Port 1194 so I moved my VPN server to a Port other than 1194 and it didn't change anything. After a day or two the wheel still starts spinning.

I just mention it to let you know that changing the port may not be the solution for everyone.

 

[eibgrad]

I run two VPN clients and one VPN server. For the last several versions of your firmware I persistently have the spinning wheel and the still intializing message. It is a minor irritation as the VPN server works just fine.

One of the VPN clients was using Port 1194 so I moved my VPN server to a Port other than 1194 and it didn't change anything. After a day or two the wheel still starts spinning.

I just mention it to let you know that changing the port may not be the solution for everyone.

I don't know if this is related, but in case it is, whenever I hear of more than one OpenVPN client and/or server, you always have to consider the possibility of IP conflicts among the various tunnels (esp. the ones you don't control). A lot of ppl overlook this small detail. But it can lead to unexpected problems. It may even *seem* things are working when in fact they are NOT, because when the OS is confronted w/ multiple network interfaces that qualify equally as potential paths, it's unpredictable which of those paths it will choose.

Again, I don't know if this is related, but it's something to be aware of as a potential problem, even if it isn't related to the current situation.

 

[CaptainSTX]

Everything works just fine. There don't seem to be any conflicts. I don't see any IP conflicts, no DNS leaks VPN client tunnels are up and stay up with no issues.

Only thing I can think of is even though I'm not using Port 1194 for my VPN server any longer I still get the same number ( 2-4 daily) of door knockers daily on that port as when I was using that port so it could be the cause of the "problem" since one VPN client uses that Port.

In any case both my VPN clients and server work so I am not going to loose any sleep over trying to fix something that really isn't broken.

 

[RMerlin]

One of the VPN clients was using Port 1194 so I moved my VPN server to a Port other than 1194 and it didn't change anything. After a day or two the wheel still starts spinning.

Then you probably got something else port scanning you and hitting that port as well.

Anyways as I said, the issue has already been fixed.

 

[kernol]

It's a secret.

But because no one is watching I'll let you in on it...

Well, you take a piece of fine sandpaper and a monitor...

No, just kidding. I use good ol' Irvanview as my image viewer on my laptop, it has a boatload of plugins and effects. By default you can use the cursor to select a rectangular piece of the image and if you hit CTRL-E (which brings up the effect browser) and select 'Gaussian Blur' you can use it to hide sensitive info. Make sure you download the 32 bit version of the program and the 32-bit pluging pack, as not every plugin is and will be available for 64 bit. Unless you want to work with huge files, but then you can even install them both in seperate folders.

Cheers,
Marco

This may be a false positive ... but thought you would be interested in this apparent Security Vulnerability with IrfanView version 4.57 ...
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27362

 

[michaels2408]

Then you probably got something else port scanning you and hitting that port as well.

Anyways as I said, the issue has already been fixed.

Thanks for your response to this issue, and I am glad the logs help point out the culprit.
Also, thanks for the firmware revision in 386.2.4 that corrected the problem. Works like a charm.
Finally, thank you thank you thank you for the development of the Asus Merlin Router firmware.

Cheers