What's new

Tutorial How to Setup a VPN client including Policy Rules for PIA and other VPN providers 384.5 07.10.18

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I want to share this to you guys, I have RT-AC68U with Merlin 380 and I'm having a problem connecting to my astrillVPN, when connecting to my VPN it always prompt a connecting status but it never connects at all it just keeps loading. I already restart my router and browser and still having an issue. I try to clear my browser's cookies and cache and these resolved my issue. I hope this help to other users that use astrillvpn.

Have you tried just downloading the ovpn file from Astrill the uploading into Open VPN client 1? I have done this with various ovpn files on three different ASUS routers running Merlin and never had an issue. On the other hand if you are trying to run the Astrill app on an ASUS router that can be trickier and I found less stable.
 
Having similar issues as some of you fine folks in relation to VPN on Merlin, but via IPVANISH.

VPN runs fine for about 24hrs then just cuts out.

Glad it's not just me. The Merlin software is mighty fine, and IPVANISH generally works with no trouble, but this odd cutting-out thing has been happening daily, for over a week now. No predictable time, nothing in the logs that indicates a problem, and the VPN status still shows as Connected. I wondered if it's because I'm using policy routing, maybe the VPN is dropping then being reinstated but without the policy rules being re-applied?
 
i have read where people put this command on the custom configurations made their VPN faster

I haven't tried it because I only have a 15 megabit line but a few people have mentioned it. Maybe try this without overclocking the router. it will get hot and then you need a cooling fan.
I have seen where people overclocked the CPU and didn't get any major difference although this command should bump it to a faster speed.
If anyone can try with high speed connections and confirm that this command pushes their speeds way more then tradition, I will put it in the guide.

try without the push command first and then add the push commands. I have a feeling all you need is the sndbuf and the revbuf.
Please if someone can test this I would appreciate it.

sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"


100Mbit connection and mine went from 13 to 20Mbit using AES-256 us-midwest.privateinternetaccess.com:1197. Server seemed a bit slow tonight but I would expect 20 to be 30 on some nights just as others reported. I am going to run this for a while and see how it goes.
 
Adding the buffer mods increased my dl speed from 61 to 74 Mbps on my AC3100. Upload speeds remained at 84 Mbps. Using AES-128-CBC.
 
Could you please explain this in layman terms please? Ty

Sent from my SM-G935F using Tapatalk
He is probably referring to this:
Code:
sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"
Place it in the Custom Configuration section on the VPN Client page.
 
He is probably referring to this:
Code:
sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"
Place it in the Custom Configuration section on the VPN Client page.
Ah i see, not sure running this 24/7 will do the router much good!

Sent from my SM-G935F using Tapatalk
 
Ah i see, not sure running this 24/7 will do the router much good!

Sent from my SM-G935F using Tapatalk
I've had it that way for over one year now on several routers with no problems.

Following is a synopsis from http://winaero.com/blog/speed-up-openvpn-and-get-faster-speed-over-its-channel

You might be wondering why and how these tweaks work? Let's refer to the history of OpenVPN. In the year 2004, OpenVPN had a problem with different buffer sizes on different platforms. To unify the data transfer channel, developers set the fixed buffers to 64Kb. However, this caused completely strange issues with the MTU for all adapters in Windows. To fix it, developers hardcoded these lines, which work for non-Windows based servers and clients:

#ifndef WIN32
o->rcvbuf = 65536;
o->sndbuf = 65536;
#endif
These lines are still presented in the OpenVPN source code, so that is why we are getting the slowdown!
 
I have updated the article with new images for VPN client to latest firmware 380.66.4
With 380.66.2 and latest update I have had no issues with VPN dropping connection or not reconnecting properly as in previous version. This is a very stable release :)
 
I have updated the article with new images for VPN client to latest firmware 380.66.4
With 380.66.2 and latest update I have had no issues with VPN dropping connection or not reconnecting properly as in previous version. This is a very stable release :)

There's still a lingering issue with PIA, where after a few hours it eventually fails to reauthenticate. I've been in touch with PIA about it, we'll see what happens. I suspect it could be a bug in OpenVPN, where the authentication token becomes invalid after a while.
 
There's still a lingering issue with PIA, where after a few hours it eventually fails to reauthenticate. I've been in touch with PIA about it, we'll see what happens. I suspect it could be a bug in OpenVPN, where the authentication token becomes invalid after a while.
I had that issue with 380.66.0 where after a day or so it would show connected but had no internet. Since 380.66.2 this issue is no longer.
I did however disabled the new Cipher Negotiation and enabled the legacy cipher falback and I can connect to PIA with no issues. its been stable ever since the.2 release.
Is this new Cipher Negotiation suppose to work with PIA? If I enable it and disable cipher fallback it wont work. Not sure if PIA has updated their servers with the latest version of OpenVPN. if you know anything about it please let us know :)
 
Is this new Cipher Negotiation suppose to work with PIA? If I enable it and disable cipher fallback it wont work. Not sure if PIA has updated their servers with the latest version of OpenVPN. if you know anything about it please let us know :)

I don't know if they switched to 2.4.x or if they did enable NCP support. I suspect that for compatibility reason, they will keep supporting legacy ciphers, although they might eventually support both.

My main contact at PIA has been in and out of the office lately, so his answers can sometimes be delayed. You might want to try contacting their tech support directly if you want a more definitive answer on this, but my guess is they updated to 2.4, but didn't enable NCP support.
 
Many thanks to everyone who has contributed to this thread. The last 2 versions have proven to be very stable with PIA, no disconnects at all. I do see this in my logs though using the latest version 380_66_4:

WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.

I removed the "--ns-cert-type" line from the custom config & the warning has now gone - just wondering if it's still "safe"?
 
Many thanks to everyone who has contributed to this thread. The last 2 versions have proven to be very stable with PIA, no disconnects at all. I do see this in my logs though using the latest version 380_66_4:

WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.

I removed the "--ns-cert-type" line from the custom config & the warning has now gone - just wondering if it's still "safe"?
I don't get any such error. Are you sure you have the command like this? "ns-cert-type server" if you are missing the server part then that's why it was causing an error.
Your config if you are using aes-128-CBC port 1198 should look like this
tls-client
remote-cert-tls server
ns-cert-type server
auth-nocache
mute-replay-warnings
disable-occ
 
I don't get any such error. Are you sure you have the command like this? "ns-cert-type server" if you are missing the server part then that's why it was causing an error.
Your config if you are using aes-128-CBC port 1198 should look like this
tls-client
remote-cert-tls server
ns-cert-type server
auth-nocache
mute-replay-warnings
disable-occ

Yes, I had the full "ns-cert-type server" in the config. My current config is:

tls-client
remote-cert-tls server
disable-occ
auth-nocache
persist-key
persist-tun

If I add "ns-cert-type server" to the config I then get the following warning in the logs when starting the vpn client:

"WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead"

The above warning is a copy/paste from the logs, so the CAPS are original.

Edit: I found this:

https://community.openvpn.net/openvpn/ticket/876

What do you think?

Edit2: here's a screen (click to enlarge):

 
Last edited:
You are right. I had to reset my VPN and it did the same thing.
So ns-cert-type server has to be removed and everything works.
I have a feeling there is a problem with 2.4 OpenVPN with PIA because the new cipher don't work
I will update the guide as soon as I figure out if its possible to use the new cipher.
I will keep everyone posted :)
 
Even Pia removed ns-cert-type server from their scripts so its safe to remove it from custom configurations
thanks for the tip :)
 
Even Pia removed ns-cert-type server from their scripts so its safe to remove it from custom configurations
thanks for the tip :)

No problem & you're welcome.

I wasn't overly concerned about it but just wanted to make sure. Glad it's now known about.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top