Extremely low speed on ac86u with openvpn client

[hassangh]

I am new to the openvpn topics. I have an ac59u running on asuswrt and just bought an ac86u running on merlin. I set exactly the same openvpn client on both of these routers (vpn server from hotspot shield). Following are my observations:
1. The dl and ul speed on ac59u is higher than those of ac86u.
2. The speed on ac86u is extremely low like 2 to 3 mbs.
3. The connection on ac86u is not stable and glitches time by time.
4. When on ac86u, I can't open some sites including Google play, youtube, and Instagram.

What are the sources of problem?
What should I do? I downgraded ac86u to different versions of merlin and even asuswrt of no avail. I even used openvpn configuration from other vpn providers ending up the same result.
I observed that CPU usage on ac86u would not spike even 50%. The ac86u performance is great on other times but not when using openvpn client.
I checked the logged report but there was no error.
Is there any specific setting I should consider when applying openvpn configuration? What about not opening some sites?

 

[Tech9]

just bought an ac86u

Not sure what your VPN issue is, but this router is End-of-Life at Asus and will be Asuswrt-Merlin supported by the end of the year only, plus it's well known for multiple hardware and software issues. If you purchased it used - run it on stock Asuswrt for some time to make sure it works properly.

 

[eibgrad]

Poor performance combined w/ not being able to open some sites suggests you may have an mtu issue w/ OpenVPN.

You could try adding the following directive to the OpenVPN client custom config field so it can test for the proper (i.e., largest supported) mtu size.

mtu-test

Takes 2-3 minutes to complete the test, w/ results reported in the syslog.

P.S. In my experience, I find it's best to stay at 1400 or less.

tun-mtu 1400

 

[hassangh]

Poor performance combined w/ not being able to open some sites suggests you may have an mtu issue w/ OpenVPN.

You could try adding the following directive to the OpenVPN client custom config field so it can test for the proper (i.e., largest supported) mtu size.

mtu-test

Takes 2-3 minutes to complete the test, w/ results reported in the syslog.

P.S. In my experience, I find it's best to stay at 1400 or less.

tun-mtu 1400

Thank you for your response. Should I also change the mtu size on the modem connecting to the router? There is a filed on the modem under dns indicating mtu size as 1500. In the config generated by the vpn provider, the tun-mtu is also set to 1450. Attached is the screenshot of openvpn client config on merlin. This config works quite well on ac59u, as you probably know, ac59u doesn't give you much of freedom. Just upload the ovpn file, set the username and password, then you are good to go. I also
noticed that the AC59U is able to successfully connect to the OpenVPN server provided by a specific VPN provider, while the AC86U, using the same OVPN configuration, does not. Even when ac86u is able to connect to the openvpn server provided by another vpn provider, it cannot access some popular sites like YouTube. Any advice on this issue is highly appreciated.

 

[eibgrad]

The way the config file import feature works, any directives that are NOT used to configure the various fields of the GUI simply get dumped into the custom config field. But in my experience, I find adding anything to the custom config field is far more likely to break things than improve things. Very rarely is anything essential to the configuration needed in the custom config field (that's why the import feature otherwise ignores it). And there's an awful lot of manipulation of the mtu in those directives, far more than I would have expected.

So first thing I would do is to remove everything in the custom config field and try again. If things do NOT improve, then add the tun-mtu directive as I indicated above.

BTW, I'm not sure why the AC59U works, but frankly, there's no way to know if each router is actually creating the same configuration based on the same import file. For all I know, the AC56U is in fact ignoring those additional directives and avoiding the problem.

 

[hassangh]

Thank you very much for your advice. By setting tun-mtu 1400 I am able to access youtube and their folks now. I have noticed whenever the public is unknown, as indicated in the attached file, I am not able to connect to internet in some specific openvpn config. Do you know what the cause of disconnection is?

The way the config file import feature works, any directives that are NOT used to configure the various fields of the GUI simply get dumped into the custom config field. But in my experience, I find adding anything to the custom config field is far more likely to break things than improve things. Very rarely is anything essential to the configuration needed in the custom config field (that's why the import feature otherwise ignores it). And there's an awful lot of manipulation of the mtu in those directives, far more than I would have expected.

So first thing I would do is to remove everything in the custom config field and try again. If things do NOT improve, then add the tun-mtu directive as I indicated above.

BTW, I'm not sure why the AC59U works, but frankly, there's no way to know if each router is actually creating the same configuration based on the same import file. For all I know, the AC56U is in fact ignoring those additional directives and avoiding the problem.

 

[eibgrad]

Thank you very much for your advice. By setting tun-mtu 1400 I am able to access youtube and their folks now. I have noticed whenever the public is unknown, as indicated in the attached file, I am not able to connect to internet in some specific openvpn config. Do you know what the cause of disconnection is?

No clue. I assume if you really are connected, then there's no logical reason the public IP should NOT be discerned. I assume it's just accessing a remote website for such purposes. But if the configuration is connected but is having some other form of communications problem, then I suppose that could be the reason. The only time I've seen this happen is when the two sides are using compression, but different algorithms. The connection is there, but neither side can understand the other. In such a case, the tunnel statistics typically show only outbound traffic, and no replies.

If your previous post is any indication of your current OpenVPN client config, there is a potential for problems when you have ALL traffic being routed through the tunnel (which includes the router itself) and you specify Strict for Accept DNS configuration. As a practical matter, Strict and Relaxed produce the same results (something I've complained about in the past). Both the DNS servers of the ISP and the VPN are available for name resolution. But suppose the ISP's DNS servers are only made available to its own customers over the WAN (not uncommon)! You *could* create a situation in which you are trying to access those ISP DNS servers over the VPN! That's why I recommend NOT using Strict or Relaxed, but Exclusive. NOW all your DNS is over the VPN, and most importantly, accessing the VPN provider's DNS servers.

 

[hassangh]

No clue. I assume if you really are connected, then there's no logical reason the public IP should NOT be discerned. I assume it's just accessing a remote website for such purposes. But if the configuration is connected but is having some other form of communications problem, then I suppose that could be the reason. The only time I've seen this happen is when the two sides are using compression, but different algorithms. The connection is there, but neither side can understand the other. In such a case, the tunnel statistics typically show only outbound traffic, and no replies.

If your previous post is any indication of your current OpenVPN client config, there is a potential for problems when you have ALL traffic being routed through the tunnel (which includes the router itself) and you specify Strict for Accept DNS configuration. As a practical matter, Strict and Relaxed produce the same results (something I've complained about in the past). Both the DNS servers of the ISP and the VPN are available for name resolution. But suppose the ISP's DNS servers are only made available to its own customers over the WAN (not uncommon)! You *could* create a situation in which you are trying to access those ISP DNS servers over the VPN! That's why I recommend NOT using Strict or Relaxed, but Exclusive. NOW all your DNS is over the VPN, and most importantly, accessing the VPN provider's DNS servers.

Great explanation! Your effort in giving persuasive guidance is highly appreciated.