Posted: Tue May 14, 2019 8:09 Post subject: [SOLVED] openvpn with PIA keeps dropping every hour!
Greetings,
I have a Netgear r7800.
Firmware: DD-WRT v3.0-r39715M kongat (05/09/19)
It is now months I am reading all I can to solve the disconnection issue I have with Private Internet Accessopenvpn connection.
I saw a lot of posts and possible solutions. Mostly from the past. None worked.
I got in touch with PIA tech support, they have me trying all of those already tested possible solution mostly found in this DD-WRT forum. None worked.
At the end of long mail conversation with PIA, I was dismissed with the following reason:
From PIA:
"
I see the following in the logs:
Mar 21 21:35:52 titio daemon.debug process_monitor[1324]: We need to re-update after 3600 seconds
Mar 21 21:35:52 titio daemon.info process_monitor[1324]: process_monitor : set timer: 3600 seconds, callback: ntp_main()
3600 seconds does equal an hour and the time suddenly mismatching would certainly kill the openvpn connection.
I do not believe this is anything to do with the VPN at this point and it is like an issue with DD-WRT and NTP. I recommend seeking assistance on the DD-WRT forums as this would be outside of our scope of support.
"
Anyone can help me on this issue?
I am totally unstable with openvpn at the moment.
I must say, I had a very similar issue with wrt1900ac v1. This is why I moved to Neatgear but did not solved the problem.
It sounds like a DD-WRT issue.
What do you think?
PS
in all this, I do use whatsch dog to reconnect everytime I loose VPN connection (or I would simply be cut off). But in the process, my network suffers of internet loss and often have issue with all live online communications.
Regards
Bacco
Last edited by bacco on Thu Jul 04, 2019 22:58; edited 1 time in total
have you tried a build from early Feb 19 before all the big dd-wrt updates?
to be honest i had one of these and it never missed a beat running pia.
does it drop internet if you are not running a vpn client? i assume you will have tested this? i only ask as you say you had similar issue with another router maybe modem issue? just a thought.
That said disconnects do happen (not with me at the moment) and therefor you can use the watch dog script from @Sploit, this only restarts the VPN so the router itself will keep working, If you do not have the link to the script I will dig it up for you
The frequent disconnects can be very frustrating unfortunately there is often no simple an quick fix as there is no one cause.
Read the link. I dont think the ntp server makes a difference as I have tried many . yet, for the sake of being sure, I will try that too. (I think I did but I do that again)
And eventually I try the cron job as well.
Thanks for your reply and help.
Bacco
have you tried a build from early Feb 19 before all the big dd-wrt updates?
to be honest i had one of these and it never missed a beat running pia.
does it drop internet if you are not running a vpn client? i assume you will have tested this? i only ask as you say you had similar issue with another router maybe modem issue? just a thought.
Foz111,
I have tried builds from: 28-10-18, 1-2-19, 14-2-19 and 9-5-19.
All starting from a reset up to configuring nat and static leases and SAMBA.. step by step.
I have no internet disconnections without VPN.
Yes, I tried my 2 modems. And I also a TP-Link from a friend also with dd-wrt on it. Same problem.
Thnks for your reply
That said disconnects do happen (not with me at the moment) and therefor you can use the watch dog script from @Sploit, this only restarts the VPN so the router itself will keep working, If you do not have the link to the script I will dig it up for you
The frequent disconnects can be very frustrating unfortunately there is often no simple an quick fix as there is no one cause.
Thanks egc,
I will certainly give it a try.
What I found strange is that I have tried 3 different bands routers with same results.
However, about a year ago when I used an older router (not an AC router) I did not have any disconnections.
My problems started when I upgraded to a better router. (or sop I hoped)
Thanks for your reply. Will report after testing.
regards,
Bacco
One test I habve not done yet is subscribing a different VPN provider to test if it makes a difference.
One test I HAVE done is trying a frien PIA login to check if it was PIA messing around with my account. But that was not the case; I still had the same issue. And my frie d does not have any issue with the same account .
My last test beside all above you suggested, will be to bring my router to a friend and test it with his connection and see if is my ISP that plays a role in all this mess!
First I will try your suggestions above.
Than will try a different ISP if not successful solution.
I think that there must be a way to have stable solution. As it was in with less powerful routers.
That said disconnects do happen (not with me at the moment) and therefor you can use the watch dog script from @Sploit, this only restarts the VPN so the router itself will keep working, If you do not have the link to the script I will dig it up for you
The frequent disconnects can be very frustrating unfortunately there is often no simple an quick fix as there is no one cause.
Hi egc,
since last night I m testing this solution.
At the beginning looked like was working well. All tests did give good results and worked out as expected.
This morning I noticed I was without internet connection. I looked in the log file that the script produces and noticed that the ping lost 100% of the packages. And the connection was cut. The Tun1 is up but nothing go on it.
I tested the commands manually as per instruction on your link, and it keep giving bad results on PID kill:
"Redundancy Checking is ENABLED!!!
Executing VPN Tunnel UP Redundancy check
Starting SploitWorks VPN Tunnel Ping Checker on tun1
ping: bad address 'tun1'
ping: bad address 'tun1'
ping: bad address 'tun1'
ping: bad address 'tun1'
###############################################################
Ohhh No! We were unable to ping 8.8.8.8
Sooo....Executing OpenVPN Forced Restart...
###############################################################
Taking down OpenVPN Client Routes
Shutting Down OpenVPN...
sh: can't kill pid 10383: No such process [Note that the PID changes all the time but is correct]
OpenVPN is restarting...
Waiting 20 seconds for tunnel to open and secure...
Starting Up OpenVPN Client Routes"
And keeps on going forever like that.
(Looks like after 1 hour, something happen. And is not possible to kill and restart anymore. Like if something done and cannot be undone!)
So I start re-testing from beginning...
- rebooted
- started PIA OPENVPN
- than SSH on router and manually tested the script: first kill all openvpn, than run the script
All works perfect.
Than,
- I let openvpn running for hours. left home and back hours later
- no internet connection
Manually run the script. But it simply goes in a loop with no success.
I than looked at the script and tested the commands manually via SSH...
- no success!
Going back to the original question (That I think is the reason of all problems): what can actually cause the router to have EXACTLY one hour of openvpn life?
I'm not so sure tunnel pings would even be all that effective anyway. When you use the ping options (which are more commonly established using the keepalive directive, which is a helper directive for ping + ping-restart), that happens at the client to server connection level. And it's not even a traditional ping, as in the ping command, but something unique and internal to OpenVPN itself.
But there can be another problem in trying to use these directives. If the OpenVPN server pushes these to the client, and the client is using them as well, the server overrides the client! IOW, you're always bound by what the server wants, not what YOU want.
So before bothering w/ such changes, I'd first check to see if these are being pushed by the server to the client by examining the syslog.
There's also a potential problem w/ using reneg-sec 0.
What reneg-sec does is determine the minimum time between having the session rekeyed. A value of zero does NOT reduce that to zero. It disables it! And now there are two possibilities; either the server has done the same, so the time between being rekeyed default to 3600, *or*, the server has pushed its own value, which may be even worse than 3600 (e.g., 86400, or once a day).
This is another example why you have to be careful with some settings, and have a looksee what's being pushed by the server. You can actually aggravate the situation if you don't examine what's being negotiated by both sides, and understand how OpenVPN responds in situations where the client and server are *both* using the same directives. There's a protocol defined in each case, and it's detailed in the OpenVPN documentation.
These are the finer details that can sometimes lead ppl astray. And why dealing w/ OpenVPN problems can be rather difficult at times.
That's why I can't stress enough, every dd-wrt user should read the OpenVPN documentation before throwing directives at it. Many times things are NOT intuitive, and don't always work as you might expect.
Trying wont hurt.
If it does not work, it costs me 1h of my life. thats ok to me.
What do you suggest to improve my openvpn stability beside reading openvpn documentation?
I am honest... reading that not short documentation and trying to find a solution, is not easier than finding some guru that can suggest out of personal experience.
Your practical input is very welcome.
I still have faith in dd-wrt and pia... so far.
Regards,
Bacco
