Recently my GL-AR300M started acting differently. Previously if I activated an Open VPN setting, it would stay active indefinitely. But recently it has changed tha if I leave it overnight and return the next day, it has disconnected.
Has something changed in an auto updated software version? Or is there a setting that controls this? It’s not the end of the world but it’s annoying.
Thanks.
Did you enable auto upgrading the firmware? If not then it will not update without your manually action.
Can you ssh to the router or use Luci to get the system log?
in ssh, use “logread”
in Luci, go to status->system log
Yes it’s on auto update.
I used Luci and have the log.
Sat Aug 12 00:17:09 2017 user.info mwan3track: Lost 3 ping(s) on interface wan (eth0)
Sat Aug 12 00:18:09 2017 user.notice mwan3track: Interface wan (eth0) is offline
Sat Aug 12 00:18:09 2017 user.notice mwan3: ifdown interface wan (eth0)
Sat Aug 12 00:18:10 2017 daemon.err openvpn[1273]: event_wait : Interrupted system call (code=4)
Sat Aug 12 00:18:10 2017 daemon.notice openvpn[1273]: /usr/sbin/ip addr del dev tun0 local 10.28.10.6 peer 10.28.10.5
Sat Aug 12 00:18:10 2017 daemon.notice netifd: Network device ‘tun0’ link is down
Sat Aug 12 00:18:10 2017 daemon.notice netifd: Interface ‘VPN_client’ has link connectivity loss
Sat Aug 12 00:18:10 2017 daemon.notice netifd: Interface ‘VPN_client’ is now down
Sat Aug 12 00:18:10 2017 daemon.notice openvpn[1273]: SIGHUP[hard,] received, process restarting
Sat Aug 12 00:18:10 2017 daemon.notice openvpn[1273]: OpenVPN 2.4.3 mips-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sat Aug 12 00:18:10 2017 daemon.notice openvpn[1273]: library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Sat Aug 12 00:18:10 2017 daemon.notice netifd: Interface ‘VPN_client’ is disabled
Sat Aug 12 00:18:15 2017 daemon.notice openvpn[1273]: TCP/UDP: Preserving recently used remote address: [AF_INET]209.95.50.64:1198
Sat Aug 12 00:18:15 2017 daemon.notice openvpn[1273]: UDP link local: (not bound)
Sat Aug 12 00:18:15 2017 daemon.notice openvpn[1273]: UDP link remote: [AF_INET]209.95.50.64:1198
Sat Aug 12 00:18:15 2017 user.info mwan3track: Lost 12 ping(s) on interface wan (eth0)
Sat Aug 12 00:18:16 2017 daemon.warn openvpn[1273]: WARNING: ‘link-mtu’ is used inconsistently, local=‘link-mtu 1558’, remote=‘link-mtu 1542’
Sat Aug 12 00:18:16 2017 daemon.warn openvpn[1273]: WARNING: ‘cipher’ is used inconsistently, local=‘cipher AES-128-CBC’, remote=‘cipher BF-CBC’
Sat Aug 12 00:18:16 2017 daemon.notice openvpn[1273]: [faa74dabe7d36859d2d1693d9624231b] Peer Connection Initiated with [AF_INET]209.95.50.64:1198
Sat Aug 12 00:18:17 2017 daemon.notice openvpn[1273]: AUTH: Received control message: AUTH_FAILED
Sat Aug 12 00:18:17 2017 daemon.notice openvpn[1273]: SIGTERM[soft,auth-failure] received, process exiting
Sat Aug 12 00:18:50 2017 user.notice mwan3track: Interface wan (eth0) is online
Sat Aug 12 00:18:51 2017 user.notice mwan3: ifup interface wan (eth0)
Sat Aug 12 00:18:52 2017 user.notice firewall: Reloading firewall due to ifup of wan (eth0)
The following log has problems. First cipher is different, which mean the server has updated its configurations. You need to regenerate the ovpn files from your service provider so that all the configurations are correct.
AUTH_FAILED means it could be wrong for some thing. If you fix your ovpn files this could be solved.
Sat Aug 12 00:18:16 2017 daemon.warn openvpn[1273]: WARNING: ‘cipher’ is used inconsistently, local=’cipher AES-128-CBC’, remote=’cipher BF-CBC’
Sat Aug 12 00:18:16 2017 daemon.notice openvpn[1273]: [faa74dabe7d36859d2d1693d9624231b] Peer Connection Initiated with [AF_INET]209.95.50.64:1198
Sat Aug 12 00:18:17 2017 daemon.notice openvpn[1273]: AUTH: Received control message: AUTH_FAILED
Thanks I’ll give that a try!
Hi Alzhao. Believe it or not I still haven’t resolved this problem. I’ve contacted PIA but that hasn’t helped as of yet.
My main suspicion is that this is all due to the connection timing out due to inactivity.
Is there a setting somewhere or some adjustment that I can make that will prevent that from happening?
THanks.
You can try a different server. Maybe I need to buy a PIA account and try again.
I bought account from every vpn service providers but these account has been expired.
I’m also getting this sometimes. Also, I’d say around 50% of the the time, I have to manually reconnect the VPN as it won’t auto-reconnect. This is with PIA as well. I downloaded the latest OVPN config files from their (PIA) server last evening. I’m using the “STRONG” set of files as I really want AES-256-CBC as the cipher.
I also get the error log messages about inconsistent ciphers but the VPN does come up, and function normally. I’m just concerned with the error log messages and they have been happening consistently and regularly, so there’s definitely something amiss. This also happens with even the “default” OVPN profiles provided by PIA; the error messages are not exactly the same but both mention cipher mismatches and the like.
Would it be possible for the company to take a look at this? PIA is very cheap to try you can buy 1-month for like a $5 bill if you don’t want a long term commitment but I just buy the year or two and be done with it. It’s the most widely used (by far) so should be the most rock-solid and stable of the providers but there appears to be some real issues with the connection to them.
Only solution I found is to run a reconnect script as cronjob.
Search" vpn reconnect script" for the thread.
Good news guys. PIA support has helped me out. Below is what they said…I used the no auth version and it works great.
Unfortunately, I believe you’ve encountered an OpenVPN bug — essentially, OpenVPN caches your auth token, and if you’re issued a new IP by your ISP, this cached token becomes invalid and the connection drops instead of renegotiating. You may be able to fix this by adding one of two options (try the first, if it doesn’t work out for you, then try the second) to your OpenVPN config.
The first option you should try is this: auth-nocache
This instructs the client to not cache an auth token, and can resolve the issue on some routers, depending on what options are hardcoded.
The second option to try is this: pull-filter ignore “auth-token”
This instructs the client to ignore the auth token altogether, and depending on firmware, some users find this more effective than auth-nocache.
Well, neither of those solutions will work effectively (as reported in this thread):
BUT congratulations on being only the second person in history to get a reply from PIA support!
The first option “auth-nocache” is not a good solution. If you use usename and password, when openvpn connection is broken, it will not connect. I met this problem before and I have to remove this option.
The second option I didn’t try. But hopefully this solves the problem.