OpenVPN Server settings, Connection very slow

[cowboy]

I have RT-AC87U (380.65), my connection speed is between 100Mbit/s and 200 Mbit/s. I set up the OpenVPN Server on my Router and use OpenVPN for Android App on my Smartphone. I tested to connect from a local McDonalds Wlan to my OpenVPN and the connection was successfully established, but it was so slow (with OpenVPN) that I could not open any website at all.

I live in Germany and use DNS-O-Matic and afraid.org. I would like to know how can I set the OpenVPN on my router so that I have a good security but also a good performance. I would like to use OpenVPN when I want to check my banking account from some public wlan area.


Here are my settings:

Here are the logs from my router and my android phone when I connect from my phone from my house with the OpenVPN for Android App:

Router Log (I get some TLS Handshake Errors):

Mar 12 13:38:41 openvpn[1226]: 192.168.1.115 TLS: Initial packet from [AF_INET6]::ffff:192.168.1.115:50848, sid=b49cfb5b 6dfb71cd
Mar 12 13:38:50 openvpn[1226]: 192.168.1.115 TLS: Initial packet from [AF_INET6]::ffff:192.168.1.115:59321, sid=28e7aa78 21dc5eaa
Mar 12 13:39:00 openvpn[1226]: 192.168.1.115 TLS: Initial packet from [AF_INET6]::ffff:192.168.1.115:42408, sid=bfc54da9 889368a0
Mar 12 13:39:35 openvpn[1226]: 192.168.1.115 TLS: Initial packet from [AF_INET6]::ffff:192.168.1.115:56218, sid=49f08c68 0e39b643
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=ASUS, CN=RT-AC87U, emailAddress=me@myhost.mydomain
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, CN=client, emailAddress=me@myhost.mydomain
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_VER=2.5_master
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_PLAT=android
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_PROTO=2
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_NCP=2
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_LZ4=1
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_LZ4v2=1
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_LZO=1
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_COMP_STUB=1
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_COMP_STUBv2=1
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_TCPNL=1
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_SSL=OpenSSL_1.0.2k__26_Jan_2017
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_GUI_VER=de.blinkt.openvpn_0.6.65
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 peer info: IV_PLAT_VER=24_7.0_arm64-v8a_Sony_msm8994_E5823
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 TLS: Username/Password authentication succeeded for username 'Devid'
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Mar 12 13:39:36 openvpn[1226]: 192.168.1.115 [client] Peer Connection Initiated with [AF_INET6]::ffff:192.168.1.115:56218
Mar 12 13:39:36 openvpn[1226]: client/192.168.1.115 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Mar 12 13:39:36 openvpn[1226]: client/192.168.1.115 MULTI: Learn: 10.8.0.2 -> client/192.168.1.115
Mar 12 13:39:36 openvpn[1226]: client/192.168.1.115 MULTI: primary virtual IP for client/192.168.1.115: 10.8.0.2
Mar 12 13:39:37 openvpn[1226]: client/192.168.1.115 PUSH: Received control message: 'PUSH_REQUEST'
Mar 12 13:39:37 openvpn[1226]: client/192.168.1.115 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.1,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 15,ping-restart 60,ifconfig 10.8.0.2 255.255.255.0,peer-id 3,cipher AES-128-GCM' (status=1)
Mar 12 13:39:37 openvpn[1226]: client/192.168.1.115 Data Channel Encrypt: Cipher 'AES-128-GCM' initialized with 128 bit key
Mar 12 13:39:37 openvpn[1226]: client/192.168.1.115 Data Channel Decrypt: Cipher 'AES-128-GCM' initialized with 128 bit key
Mar 12 13:39:41 openvpn[1226]: 192.168.1.115 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mar 12 13:39:41 openvpn[1226]: 192.168.1.115 TLS Error: TLS handshake failed
Mar 12 13:39:41 openvpn[1226]: 192.168.1.115 SIGUSR1[soft,tls-error] received, client-instance restarting
Mar 12 13:39:50 openvpn[1226]: 192.168.1.115 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mar 12 13:39:50 openvpn[1226]: 192.168.1.115 TLS Error: TLS handshake failed
Mar 12 13:39:50 openvpn[1226]: 192.168.1.115 SIGUSR1[soft,tls-error] received, client-instance restarting
Mar 12 13:40:00 openvpn[1226]: 192.168.1.115 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mar 12 13:40:00 openvpn[1226]: 192.168.1.115 TLS Error: TLS handshake failed
Mar 12 13:40:00 openvpn[1226]: 192.168.1.115 SIGUSR1[soft,tls-error] received, client-instance restarting

Here is the OpenVPN log file from my Android.

 

[Zirescu]

Did you perform a speed test at McD's before making your connection back to your router? Is your upload also 100-200?

 

[octopus]

Here in my country McDonall block openvpn, at least when I tested a couple days ago.

 

[cowboy]

Did you perform a speed test at McD's before making your connection back to your router? Is your upload also 100-200?

No I did not test. But the connection at McD's is pretty much above 15Mbit/s. But I will test it the next time. But still if it was slow I think after some time the site should open.

Here in my country McDonall block openvpn, at least when I tested a couple days ago.

I established the connection, so I think they don't block it, but who knows maybe they have some other restrictions.

 

[Zirescu]

Could be a problem with it not resolving the DNS settings correctly.

 

[netware5]

Remove LZO compression. This will improve your speed. You should do this on both sides - client and server. Also if you main concern is speed - stay with 128 bit ciphers and don't use 256.

In any case I do not expect that you could reach more than 30-40 Mbits using OpenVPN tunnel with your router. This is a hardware limitation. Crypto tasks are big challenge for weak CPUs of consumer-grade routers.

Just an example: with my overclocked (662Mhz) RT-N66U I am reaching 14 Mbits with AES-256 cipher and no compression.

 

[cowboy]

Remove LZO compression. This will improve your speed. You should do this on both sides - client and server. Also if you main concern is speed - stay with 128 bit ciphers and don't use 256.

In any case I do not expect that you could reach more than 30-40 Mbits using OpenVPN tunnel with your router. This is a hardware limitation. Crypto tasks are big challenge for weak CPUs of consumer-grade routers.

Just an example: with my overclocked (662Mhz) RT-N66U I am reaching 14 Mbits with AES-256 cipher and no compression.

Thanks I will try this.

 

[Observation]

I was not pleased with performance of VPN streams going through my RT-AC66 at over 4-8 Mbps. Streams got a bit choppy. Would have been OK for moving simple file chunks at higher rates I think or any purpose where surges and sags in data delivery were not an issue (e.g. surfing simple webpages without embedded streams). I do have a seldom used USB drive attached which might be dragging things down with pointless overhead. But still I can believe others who said 10Mbps was often a practical max depending on other running router applications and of course firewall rules interacting with ISP network (e.g. cable might have a lot of local traffic and attacks to filter out).

In fact McDonalds open WiFi probably has lots of attacks for router firewall to fight off (CPU loading other than VPN). Won't get inside VPN tunnel but probably can still follow connection and attack unencrypted WAN outside the VPN tunnel by snooping destination IPs. I would have to really think about that so I leave that to the experts to comment upon futher. Might want to check router logs for CPU loading at the exact times of connection attempts.

But could the slow connection issue be partially on laptop? The laptop itself certainly still has an exposed attack surface to McDonald LAN even if using VPN as its preferred Internet connection. All the inbound scans and connections it has to reject in favor of VPN. So have you checked laptop CPU loading? Again not an expert but I have noticed that Windows default configurations seem to limit % CPU available to PC firewall such that network connections can be swamped by DoS etc without whole machine locking up by firewall overload. I suspect there is some tuning to that can be done to MS firewall or better yet a substitute 3rd party firewall for Windows that you can get to be much more efficient. Your familarity with configuration of a particular brand of firewall can mean a lot to tuning it too.

Also router CPU with AES instructions would greatly ease VPN encryption workload even on consumer router if the encryption API to use those instructions was working. I know the CPUs exist BCM5801/BCM5805/BCM5820 using Security Processor BCM5365 | AES (up to 256-bit CTR and CBC modes) BCM5365P | AES (up to 256-bit CTR and CBC modes). But do not know which routers might use those CPUs or have API to use special encryption instructions. OpenWrt talks a bit about that https://wiki.openwrt.org/doc/hardware/cryptographic.hardware.accelerators.
I mention Broadcom specifically because I gather that is the area of specialization for many open firmware upgrade programs for consumer routers.

But if you wander away from consumer router hardware into pfsense then atom processor based machines or even PC motherboard based machines might solve your CPU power issues with both raw general power or AES instructions. Pfsense is able to use AES encryption hardware instructions. A relatively new J3355B based system running pfsense looks like it might be cheap, low powered, and small enough to replace consumer router while adding very high speed VPN. There is certain other firewall-router software for AES enable CPUs https://en.wikipedia.org/wiki/AES_instruction_set

By the way is that location in your router log fake? Because going through Taiwan would probably make for a really slow connection from EU or US.

 

[Observation]

Remove LZO compression. This will improve your speed. You should do this on both sides - client and server. Also if you main concern is speed - stay with 128 bit ciphers and don't use 256.

In any case I do not expect that you could reach more than 30-40 Mbits using OpenVPN tunnel with your router. This is a hardware limitation. Crypto tasks are big challenge for weak CPUs of consumer-grade routers.

Just an example: with my overclocked (662Mhz) RT-N66U I am reaching 14 Mbits with AES-256 cipher and no compression.

Not sure but my initial impression is that AES encryption of data for VPN tunnel is significantly more complex than LZO compression of data before that encryption. At least without AES hardware assistance. So while I can easily see increases in raw bits sent without LZO compression ( additional CPU freed up for encryption process) -- isn't the net data passed going to be less? That is on average compression likely means 30-50% less bits needed to encrypted and sent (application dependent but web pages without streams ought to yield good compression).

Explain please.

 

[netware5]

Not sure but my initial impression is that AES encryption of data for VPN tunnel is significantly more complex than LZO compression of data before that encryption. At least without AES hardware assistance. So while I can easily see increases in raw bits sent without LZO compression ( additional CPU freed up for encryption process) -- isn't the net data passed going to be less? That is on average compression likely means 30-50% less bits needed to encrypted and sent (application dependent but web pages without streams ought to yield good compression).

Explain please.

When I started using OpenVPN server on my router (it was in 2013) I had the same initial impression. But when discovered that my tunnel speed is max 8 Mbits with default settings I decided to disable the LZO compression. The result was very visible - 12 Mbits then increased to 14 Mbits after CPU overclocking. So my advice was based solely on my practice. If you do google "LZO compression OpenVPN performance" you may find a lot of information regarding the benefit to disable LZO. Some other users in this forum also share this opinion. You may check these posts https://www.snbforums.com/threads/very-slow-openvpn.37883/#post-311883 and https://www.snbforums.com/threads/very-slow-openvpn.37883/#post-311957

*EDIT* I'd also discovered much higher router CPU loads (up to 100%) with LZO compression enabled.

 

[cowboy]

Remove LZO compression. This will improve your speed. You should do this on both sides - client and server. Also if you main concern is speed - stay with 128 bit ciphers and don't use 256.

Thanks, I removed the LZO compression. I think it does not make much sense for me as it can not compress HTTPS sites. How can I change the ciphers to 128 bit ?

I set the TLS control channel to Encryption and tested everything from home with my Android device (OpenVPN for Android App). I reached 30 Mbit/s. In the next weeks I will test from some other open networks I find and again from McDonalds Wlan and report back the results.

ps. What do Auth digest, Respond to DNS and Advertise DNS to clients fields do ? And what does Direct clients to redirect internet traffic do ?

I was not pleased with performance of VPN streams going through my RT-AC66 at over 4-8 Mbps. Streams got a bit choppy. Would have been OK for moving simple file chunks at higher rates I think or any purpose where surges and sags in data delivery were not an issue (e.g. surfing simple webpages without embedded streams). I do have a seldom used USB drive attached which might be dragging things down with pointless overhead. But still I can believe others who said 10Mbps was often a practical max depending on other running router applications and of course firewall rules interacting with ISP network (e.g. cable might have a lot of local traffic and attacks to filter out).

My problem was not that much the speed, although the faster the better of course. My problem was that the speed is so bad that I can't even open www.google.com.

In fact McDonalds open WiFi probably has lots of attacks for router firewall to fight off (CPU loading other than VPN). Won't get inside VPN tunnel but probably can still follow connection and attack unencrypted WAN outside the VPN tunnel by snooping destination IPs. I would have to really think about that so I leave that to the experts to comment upon futher. Might want to check router logs for CPU loading at the exact times of connection attempts.

But could the slow connection issue be partially on laptop? The laptop itself certainly still has an exposed attack surface to McDonald LAN even if using VPN as its preferred Internet connection. All the inbound scans and connections it has to reject in favor of VPN. So have you checked laptop CPU loading? Again not an expert but I have noticed that Windows default configurations seem to limit % CPU available to PC firewall such that network connections can be swamped by DoS etc without whole machine locking up by firewall overload. I suspect there is some tuning to that can be done to MS firewall or better yet a substitute 3rd party firewall for Windows that you can get to be much more efficient. Your familarity with configuration of a particular brand of firewall can mean a lot to tuning it too.

I don't use a laptop as a client but my Android Smartphone (Sony Xperia Z5). But yes maybe McDonalds has some kind of rule or restriction. I don't know. I will do more testing in the next weeks to find out.

By the way is that location in your router log fake? Because going through Taiwan would probably make for a really slow connection from EU or US.

The log files are from my router, I just changed the names. So the location should not be fake. I am not aware of this, can you point me to how did you find out it is Taiwan ? Is it the public IP address ?
Thanks

 

[netware5]

@cowboy,

Could you check the speed with VPN and without VPN using your mobile phone from two different public WLANs? One in McDonalds and one in some other public place?

 

[cowboy]

@cowboy,

Could you check the speed with VPN and without VPN using your mobile phone from two different public WLANs? One in McDonalds and one in some other public place?

Ok I will, next week after work I will visit some places. with public Wlans and post the result here.

 

[primitivo]

Remove LZO compression. This will improve your speed. You should do this on both sides - client and server. Also if you main concern is speed - stay with 128 bit ciphers and don't use 256.

In any case I do not expect that you could reach more than 30-40 Mbits using OpenVPN tunnel with your router. This is a hardware limitation. Crypto tasks are big challenge for weak CPUs of consumer-grade routers.

Just an example: with my overclocked (662Mhz) RT-N66U I am reaching 14 Mbits with AES-256 cipher and no compression.

Very interesting.

I have RT-AC68U OpenVPN server established at home on fiber-optic connection 200/45 on MerlinWRT 380.65_4. Settings are pretty much basic with responding to DNS, redirecting internet traffic enabled. Encryption AES-128-CBC, compression LZO Adaptive.

With the latest Tunneblick beta for Mac which supports OpenVPN client 2.4.1, I am 165ms away from home also using fiber-optic connection 100/20, reaching speeds of 30 Mbps down / 20 Mbps up. Is it max what I can achieve, should I tweak some settings? Do you think that the same setup on RT-AC88U would result in almost double the speed, considering almost twice powerful CPU?

Edit: however when I set OpenVPN client on my RT-AC56U (so identical CPU wise to RT-AC68U in which OpenVPN server is running at home) using the same details as for Tunnelblick desktop, I am only getting something around 10Mbps down / 10Mbps up. Any ideas why?

 

[netware5]

Very interesting.

I have RT-AC68U OpenVPN server established at home on fiber-optic connection 200/45 on MerlinWRT 380.65_4. Settings are pretty much basic with responding to DNS, redirecting internet traffic enabled. Encryption AES-128-CBC, compression LZO Adaptive.

With the latest Tunneblick beta for Mac which supports OpenVPN client 2.4.1, I am 165ms away from home also using fiber-optic connection 100/20, reaching speeds of 30 Mbps down / 20 Mbps up. Is it max what I can achieve, should I tweak some settings? Do you think that the same setup on RT-AC88U would result in almost double the speed, considering almost twice powerful CPU?

Edit: however when I set OpenVPN client on my RT-AC56U (so identical CPU wise to RT-AC68U in which OpenVPN server is running at home) using the same details as for Tunnelblick desktop, I am only getting something around 10Mbps down / 10Mbps up. Any ideas why?

It is interesting indeed. What version of OpenVPN server you are running on RT-AC68U? 2.3.x or 2.4.x? The same question apply also for the client on RT-AC56U.

 

[primitivo]

It is interesting indeed. What version of OpenVPN server you are running on RT-AC68U? 2.3.x or 2.4.x? The same question apply also for the client on RT-AC56U.

Both are running MerlinWRT 380.65_4 so OpenVPN 2.4.x

Desktop (Tunneblick) client speeds (30 down /20 up) are satisfying considering "home OpenVPN setup" and 165ms latency, I just wonder whether:

1. RT-AC88U as a OpenVPN server would be twice as efficient
2. Why is the RT-AC56U OpenVPN client connected to RT-AC68U OpenVPN server running at 10 Mbps down / up only.

 

[netware5]

Both are running MerlinWRT 380.65_4 so OpenVPN 2.4.x

Desktop (Tunneblick) client speeds (30 down /20 up) are satisfying considering "home OpenVPN setup" and 165ms latency, I just wonder whether:

1. RT-AC88U as a OpenVPN server would be twice as efficient
2. Why is the RT-AC56U OpenVPN client connected to RT-AC68U OpenVPN server running at 10 Mbps down / up only.

1. Yes, you could expect that RT-AC88U will outperform RT-AC68U approximately 1400/800 = 1.75 times.

2. This is really interesting. I don't know. Could you check the compression options in OpenVPN config files of RT-AC68U server and RT-AC56U and desktop clients? Are they identical? The OpenVPN 2.4.x supports LZ4 compression, which is highly recommended and I don't know what are the default options. The LZ4 algorithm has one significant difference compared to LZO. It has "asymmetrical" behavior, i.e. the compression/decompression speeds are 3-4 times different. So it depends "who" is performing compression and "who" is performing decompression. It is obvious that the desktop client significantly outperforms the RT-AC56U in these tasks.

Another new feature in OpenVPN 2.4.x is that cipher negotiation (NCP) can override the cipher specified by --cipher. In practice that means the 2.4.x will use AES-GCM instead AES-CBC if the NCP is not explicitly disabled. You may check the NCP related options in OpenVPN config files of RT-AC68U server and RT-AC56U and desktop clients to see if NCP is enabled. Do some reading of 2.4.x manual regarding these options. You may also check what is the cipher really used after establishing the session in both cases - desktop client and RT-AC56U client. This is important, because the AES-GCM is significantly faster than AES-CBC.

 

[primitivo]

Once I have more time I will take a closer look. For the time being with slightly lower latency of 157ms, I was able to get 39 down /20 (max) up Mbps via Tunneblick (Mac) connected via OpenVPN to RT-AC68U. These are very good results for "home" setup in my opinion as well as the latency / distance. If AC88U running as a server can almost double it, that would be quite interesting.