Asus OpenVPN server security

[LeoBloom]

Hello all,

Recently discovered that my RT-N66U has OpenVPN capability built in. I decided I would like to be able to tunnel all my traffic in public WiFi through my home router as well as access folder shares.

I have never worked with VPNs before and wanted to check about your thoughts for security
- Is the Asus OpenVPN implementation safe to use, or do you guys use any additional security features?
- Should I change the default port from 1194 to avoid port scanners?
- I noticed that 'admin' is a user on the OpenVPN that I cannot get rid of - does this mean I should change the router admin password to something only a password manager would remember? Or does the admin user not actually log onto the VPN

Thanks in advance

 

[RMerlin]

Asus's OpenVPN implementation should be fairly safe. It's not running the latest version of it, but I don't remember any critical vulnerabilities being fixed in recent years.

Changing port to a different one is indeed a good idea to reduce the amount of port scanning, which might fill up your logs.

The admin user is indeed "hardcoded" and cannot be disabled. Using a fairly secure password or at the very least changing the default username to something different should be safe enough.

 

[David B]

Asus's OpenVPN implementation should be fairly safe. It's not running the latest version of it, but I don't remember any critical vulnerabilities being fixed in recent years.

I am not sure what version of OpenVPN is currently in use on the stock Asus firmware, but hopefully it's been updated to account for this vulnerability from June of 2017.

 

[RMerlin]

I am not sure what version of OpenVPN is currently in use on the stock Asus firmware, but hopefully it's been updated to account for this vulnerability from June of 2017.

The remote code execution is unlikely to be an issue.

The problem can only be triggered for configurations that use the
--x509-alt-username option with an x509 extension (i.e. the option
parameter starts with "ext:").

Asuswrt doesn't use that feature.

 

[sfx2000]

Asus OVPN is relatively secure - and RMerlin's fork does improve upon things.

Much better than some of the other OEM's (yes, Linksys, I'm looking at you with the fixed configurations and no means to revoke client certs)

 

[LeoBloom]

Thank you all for your help - does this configuration look good?

Running Merlin version

Everything so far has been working as intended on the VPN

 

[RMerlin]

Looks good to me.

 

[David B]

It might be a good idea to use something stronger than SHA1 for the "Auth digest" setting.

https://www.theverge.com/2017/2/23/14712118/google-sha1-collision-broken-web-encryption-shattered
https://www.theregister.co.uk/2017/02/23/google_first_sha1_collision/

 

[RMerlin]

It might be a good idea to use something stronger than SHA1 for the "Auth digest" setting.

When used for HMAC (as OpenVPN does), the SHA1 collision risks don't apply - SHA1 is still fine to use for that.

 

[sfx2000]

It might be a good idea to use something stronger than SHA1 for the "Auth digest" setting.

Depends on the CPU features and board support packages - no crypto accelerators, just core, Cortex-A53 @ 1.2GHz

gnutls-cli --benchmark-ciphers
Checking cipher-MAC combinations, payload size: 16384
AES-128-GCM 11.81 MB/sec
AES-128-CBC-SHA1 15.15 MB/sec
AES-128-CBC-SHA256 13.63 MB/sec

AES-128-GCM is the future - runs well enough already, but on some chips, runs much better... and OpenSSL does even better in some use cases than gnutls, mostly due to vendor contributions.

In the interim - like @RMerlin suggests - SHA1 is good enough for most...

 

[David B]

When used for HMAC (as OpenVPN does), the SHA1 collision risks don't apply - SHA1 is still fine to use for that.

I'm not sure what HMAC is, and Google hasn't been very helpful with figuring it out.

 

[RMerlin]

I'm not sure what HMAC is, and Google hasn't been very helpful with figuring it out.

It's used to authenticate the packets and ensure they weren't tempered with.

https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure

 

[LeoBloom]

So I have been very happy with the openvpn set-up on the Merlin firmware. Couple of follow-up questions

- I have a pop-up that a new firmware is available -- will this update to the new Merlin firmware or will it break the router by trying to update to an Asus firmware?

- If it updates to the Merlin firmware, is the OpenVPN version updated as well? I recently got a message from tunnelblick that a certain aspect of the OpenVPN configuration I am using will not be supported in future versions (but I can't remember the wording exactly and it hasn't popped up since)

Thanks

 

[sfx2000]

I recently got a message from tunnelblick that a certain aspect of the OpenVPN configuration I am using will not be supported in future versions (but I can't remember the wording exactly and it hasn't popped up since)

There's certain configs that are deprecated, and will not be supported in some future version of OpenVPN - Tunnelblick is being proactive to nudge folks forward...

 

[RMerlin]

I have a pop-up that a new firmware is available -- will this update to the new Merlin firmware or will it break the router by trying to update to an Asus firmware?

New update notifications from my firmware are specific to my firmware, it doesn't check for updates from Asus.

- If it updates to the Merlin firmware, is the OpenVPN version updated as well? I recently got a message from tunnelblick that a certain aspect of the OpenVPN configuration I am using will not be supported in future versions (but I can't remember the wording exactly and it hasn't popped up since)

That notification talks about a version that doesn't exist yet. They are simply warning you that you should adjust your configuration in preparation to that future update, which is most likely years away from now.

I'm already using the latest OpenVPN version available.

 

[LeoBloom]

New update notifications from my firmware are specific to my firmware, it doesn't check for updates from Asus.



That notification talks about a version that doesn't exist yet. They are simply warning you that you should adjust your configuration in preparation to that future update, which is most likely years away from now.

I'm already using the latest OpenVPN version available.

Great - thank you very much for the answers!

 

[John35]

BTW (slightly belatedly) my RT-AC87U, which is currently on the Asus 382 code, was locked up this morning.
The log had regular sets of these:

Jul 7 13:04:44 ntp: start NTP update
Jul 7 20:46:59 vpnserver1[12641]: 185.200.118.66:58646 TLS: Initial packet from [AF_INET]185.200.118.66:58646 (via [AF_INET]86.148.182.140%ppp0), sid=12121212 12121212
Jul 7 20:47:59 vpnserver1[12641]: 185.200.118.66:58646 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jul 7 20:47:59 vpnserver1[12641]: 185.200.118.66:58646 TLS Error: TLS handshake failed
Jul 7 20:47:59 vpnserver1[12641]: 185.200.118.66:58646 SIGUSR1[soft,tls-error] received, client-instance restarting

...and the IP isn't a "good" one...
https://www.abuseipdb.com/check/185.200.118.54
"This IP was reported 50 times. Confidence of Abuse is 85%"
"VPNserver exploit attempts on consumer routers"

I assume they didn't get in and the lock-up might or might not be related. I just turned off the OpenVPN server to be on the safe side. It started on June 1st. Does anyone know if there are currently any VPN exploits in the ASUS 382 code that are fixed in RMerlin's code?

 

[RMerlin]

I assume they didn't get in and the lock-up might or might not be related. I just turned off the OpenVPN server to be on the safe side. It started on June 1st. Does anyone know if there are currently any VPN exploits in the ASUS 382 code that are fixed in RMerlin's code?

You'd have to review the OpenVPN changelog. Asus uses 2.3.2 which dates back from 2013, while I use 2.4.6 which is currently the latest release.

 

[David B]

I am not sure when this flaw was introduced, but there was an RCE vulnerability found around this time last year in OpenVPN. You may be vulnerable to that: https://threatpost.com/openvpn-patches-critical-remote-code-execution-vulnerability/126425/

 

[John35]

Thank you both, most appreciated. Although I hope the non-x86 CPU might have thwarted their efforts...