Jump to content
Not connected, Your IP: 18.224.60.132
AirVPN
Vimes

ANSWERED Why does my AirVPN connection reset at 3:00am...?

By Vimes, ... in Troubleshooting and Problems

Recommended Posts

Vimes    4

Vimes
Posted ...

Hi

I have started to use a R7800 router and it is flashed with DD-WRT v3.0-r31900M kongat (04/26/17).

 

All seems well with the VPN connection, using the inbuilt OpenVPN client. 

 

But each time that I log into this site it confirms that at 3:00AM my connection was established with AirVPN. 

 

I look at the uptime of the routers connection and that is for much longer, in other words my WAN connection is up and stays up.

 

I look at the logs for the OpenVPN client.....

 

 

Client: CONNECTED SUCCESS

Local Address: 10.4.25.88 
Remote Address: 10.4.25.88 
Status VPN Client Stats TUN/TAP read bytes 28962537 TUN/TAP write bytes 660000521 TCP/UDP read bytes 687183664 TCP/UDP write bytes 41162037 Auth read bytes 660009753 pre-compress bytes 0 post-compress bytes 0 pre-decompress bytes 0 post-decompress bytes 0
LogClientlog: 
20170502 03:00:11 I OpenVPN 2.4.1 arm-unknown-linux-gnu [sSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 26 2017 
20170502 03:00:11 I library versions: OpenSSL 1.0.2h 3 May 2016 LZO 2.09 
20170502 03:00:11 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16 
20170502 03:00:11 W WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead. 
20170502 03:00:11 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 
20170502 03:00:11 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 
20170502 03:00:11 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 
20170502 03:00:11 I TCP/UDP: Preserving recently used remote address: [AF_INET]185.103.96.131:443 
20170502 03:00:11 Socket Buffers: R=[180224->180224] S=[180224->180224] 
20170502 03:00:11 I UDPv4 link local: (not bound) 
20170502 03:00:11 I UDPv4 link remote: [AF_INET]185.103.96.131:443 
20170502 03:00:11 TLS: Initial packet from [AF_INET]185.103.96.131:443 sid=140a803b 6fe55a1a 
20170502 03:00:11 VERIFY OK: depth=1 C=IT ST=IT L=Perugia O=airvpn.org CN=airvpn.org CA emailAddress=info@airvpn.org 
20170502 03:00:11 VERIFY OK: nsCertType=SERVER 
20170502 03:00:11 NOTE: --mute triggered... 
20170502 03:00:11 2 variation(s) on previous 3 message(s) suppressed by --mute 
20170502 03:00:11 I [server] Peer Connection Initiated with [AF_INET]185.103.96.131:443 
20170502 03:00:13 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) 
20170502 03:00:13 PUSH: Received control message: 'PUSH_REPLY redirect-gateway def1 bypass-dhcp dhcp-option DNS 10.4.0.1 comp-lzo no route-gateway 10.4.0.1 topology subnet ping 10 ping-restart 60 ifconfig 10.4.25.88 255.255.0.0' 
20170502 03:00:13 OPTIONS IMPORT: timers and/or timeouts modified 
20170502 03:00:13 NOTE: --mute triggered... 
20170502 03:00:13 5 variation(s) on previous 3 message(s) suppressed by --mute 
20170502 03:00:13 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key 
20170502 03:00:13 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 
20170502 03:00:13 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key 
20170502 03:00:13 NOTE: --mute triggered... 
20170502 03:00:13 1 variation(s) on previous 3 message(s) suppressed by --mute 
20170502 03:00:13 I TUN/TAP device tun1 opened 
20170502 03:00:13 TUN/TAP TX queue length set to 100 
20170502 03:00:13 D do_ifconfig tt->did_ifconfig_ipv6_setup=0 
20170502 03:00:13 I /sbin/ifconfig tun1 10.4.25.88 netmask 255.255.0.0 mtu 1500 broadcast 10.4.255.255 
20170502 03:00:13 /sbin/route add -net 185.103.96.131 netmask 255.255.255.255 gw 195.166.130.248 
20170502 03:00:13 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.4.0.1 
20170502 03:00:13 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.4.0.1 
20170502 03:00:13 I Initialization Sequence Completed 
20170502 04:00:11 VERIFY OK: depth=1 C=IT ST=IT L=Perugia O=airvpn.org CN=airvpn.org CA emailAddress=info@airvpn.org 
20170502 04:00:11 VERIFY OK: nsCertType=SERVER 
20170502 04:00:11 VERIFY OK: depth=0 C=IT ST=IT L=Perugia O=airvpn.org CN=server emailAddress=info@airvpn.org 

 

 

....all that seems to confirm to me is that it does connect at 3:00am.

 

Prior to that connection I leave the PC or other devices knowing that I had a working connection to the AirVPN connection without issue. It will remain that way until 3:00am the next day, if this pattern continues. This has happened for several nights in a row and I did not notice it when I had my R7000 and using a AsusWRT- Merlin firmware.

 

Last night I was playing around a little with Samba shares and so on, meaning the router was being rebooted etc but I left it at its default setting and all was well, with WAN uptime which exceeds that of the AirVPN reconnection.

 

Curious as it does seem to be at 3:00am.

 

I'll enable system logging in DD-WRT, just noticed that it is disabled by default.

 

Other disconnections from AirVPN are planned, meaning that I have been testing Samba or DLNA access and shares etc as well as radio settings for the 2.4Ghz or 5Ghz channel, often these needing a reboot of the router and thus a new AirVPN connection.

 

Thanks

Share this post

Link to post

go558a83nk    364

go558a83nk
Posted ...

It's probably a nightly release of your ISP connection.  Perhaps it boils down to how the different firmwares handle DHCP release.

Share this post

Link to post

Vimes    4

Vimes
Posted ...

It's probably a nightly release of your ISP connection.  Perhaps it boils down to how the different firmwares handle DHCP release.

 

 

Thanks, it is strange, well at least to me.

 

The connection to my WAN remains valid and up.

 

Last night in the System log.....

 

May 3 03:00:00 DD-WRT daemon.err openvpn[15238]: event_wait : Interrupted system call (code=4)

 

 

in the VPN log....

 

 

Log

Clientlog: 

20170503 03:00:10 I OpenVPN 2.4.1 arm-unknown-linux-gnu [sSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 26 2017 

20170503 03:00:10 I library versions: OpenSSL 1.0.2h 3 May 2016 LZO 2.09 

20170503 03:00:10 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16 

20170503 03:00:10 W WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead. 

20170503 03:00:10 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 

20170503 03:00:10 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 

20170503 03:00:10 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 

20170503 03:00:10 I TCP/UDP: Preserving recently used remote address: [AF_INET]185.103.96.132:443 

20170503 03:00:10 Socket Buffers: R=[180224->180224] S=[180224->180224] 

20170503 03:00:10 I UDPv4 link local: (not bound) 

20170503 03:00:10 I UDPv4 link remote: [AF_INET]185.103.96.132:443 

20170503 03:00:11 TLS: Initial packet from [AF_INET]185.103.96.132:443 sid=2a55df60 df412309 

20170503 03:00:11 VERIFY OK: depth=1 C=IT ST=IT L=Perugia O=airvpn.org CN=airvpn.org CA emailAddress=info@airvpn.org 

20170503 03:00:11 VERIFY OK: nsCertType=SERVER 

20170503 03:00:11 NOTE: --mute triggered... 

20170503 03:00:11 2 variation(s) on previous 3 message(s) suppressed by --mute 

20170503 03:00:11 I [server] Peer Connection Initiated with [AF_INET]185.103.96.132:443 

20170503 03:00:12 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) 

20170503 03:00:12 PUSH: Received control message: 'PUSH_REPLY redirect-gateway def1 bypass-dhcp dhcp-option DNS 10.4.0.1 comp-lzo no route-gateway 10.4.0.1 topology subnet ping 10 ping-restart 60 ifconfig 10.4.27.59 255.255.0.0' 

20170503 03:00:12 OPTIONS IMPORT: timers and/or timeouts modified 

20170503 03:00:12 NOTE: --mute triggered... 

20170503 03:00:12 5 variation(s) on previous 3 message(s) suppressed by --mute 

20170503 03:00:12 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key 

20170503 03:00:12 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 

20170503 03:00:12 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key 

20170503 03:00:12 NOTE: --mute triggered... 

20170503 03:00:12 1 variation(s) on previous 3 message(s) suppressed by --mute 

20170503 03:00:12 I TUN/TAP device tun1 opened 

20170503 03:00:12 TUN/TAP TX queue length set to 100 

20170503 03:00:12 D do_ifconfig tt->did_ifconfig_ipv6_setup=0 

20170503 03:00:12 I /sbin/ifconfig tun1 10.4.27.59 netmask 255.255.0.0 mtu 1500 broadcast 10.4.255.255 

20170503 03:00:12 /sbin/route add -net 185.103.96.132 netmask 255.255.255.255 gw 195.166.130.253 

20170503 03:00:12 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.4.0.1 

20170503 03:00:12 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.4.0.1 

20170503 03:00:12 I Initialization Sequence Completed 

 

 

so again at 3:00am I get the disconnection.

 

The uptime of the WAN exceeds that of the VPN and is stable.

Share this post

Link to post

go558a83nk    364

go558a83nk
Posted ...

Definitely odd.  As you can see by the status page AirVPN doesn't disconnect people.  Some have been connected for weeks.

Share this post

Link to post

Vimes    4

Vimes
Posted ...

Definitely odd.  As you can see by the status page AirVPN doesn't disconnect people.  Some have been connected for weeks.

 

 

As I used to be. I do not see anything in my setup, followed the guide on here, for my OpenVPN / DD-WRT connection which should cause an "expiration" and reconnection at exactly 24 hours since the last one. 

 

As I write this post I have checked and seen that I have been connected since 3:00am with no issues. I can only imagine that at 3:00am tomorrow I'll be disconnected and then reconnected - whilst my WAN (connection to my ISP) remains unchanged and connected.

Share this post

Link to post

tehhellhound    8

tehhellhound
Posted ...

That is the typical ISP maintenance window. On my old ISP, I used to get disconnected from anything at that time, whether it be an online game or streaming radio. The interruption was very brief. It would not show up in my router. The most I would see is a T3 timeout in my modem logs, but not always. I was told by numerous techs that that was normal on their system. This doesn't happen on my current ISP with the same equipment.

Share this post

Link to post

Vimes    4

Vimes
Posted ...

That is the typical ISP maintenance window. On my old ISP, I used to get disconnected from anything at that time, whether it be an online game or streaming radio. The interruption was very brief. It would not show up in my router. The most I would see is a T3 timeout in my modem logs, but not always. I was told by numerous techs that that was normal on their system. This doesn't happen on my current ISP with the same equipment.

 

 

Good point and maybe that is what is happening.

 

Just seems strange to me that my previous R7000 router and VPN client never saw that and the information in the AirVPN client page would show that I'm connected for days on end. Since changing to the R7800 and DD-WRT and that VPN client I'm now seeing the 3:00am "issue" / non issue, but that also shows up at the AirVPN site. 

Share this post

Link to post

Vimes    4

Vimes
Posted ...

Just to add at 3:00am the sys log shows.....

 

 

May 3 03:00:00 DD-WRT user.info : openvpn : OpenVPN daemon (Client) successfully stopped May 3 03:00:00 DD-WRT daemon.notice openvpn[15238]: 88 variation(s) on previous 3 message(s) suppressed by --mute May 3 03:00:00 DD-WRT daemon.err openvpn[15238]: event_wait : Interrupted system call (code=4) May 3 03:00:00 DD-WRT daemon.notice openvpn[15238]: /tmp/openvpncl/route-down.sh tun1 1500 1558 10.4.50.191 255.255.0.0 init May 3 03:00:00 DD-WRT daemon.notice openvpn[15238]: /sbin/route del -net 94.229.74.90 netmask 255.255.255.255 May 3 03:00:00 DD-WRT daemon.notice openvpn[15238]: /sbin/route del -net 0.0.0.0 netmask 128.0.0.0 May 3 03:00:00 DD-WRT daemon.notice openvpn[15238]: /sbin/route del -net 128.0.0.0 netmask 128.0.0.0 May 3 03:00:00 DD-WRT daemon.notice openvpn[15238]: Closing TUN/TAP interface May 3 03:00:00 DD-WRT daemon.notice openvpn[15238]: /sbin/ifconfig tun1 0.0.0.0 May 3 03:00:00 DD-WRT daemon.notice openvpn[15238]: SIGTERM[hard,] received, process exiting May 3 03:00:00 DD-WRT user.info : pppd : pppoe process successfully stopped May 3 03:00:00 DD-WRT daemon.info pppd[10826]: Exit. May 3 03:00:00 DD-WRT user.info : redial : ppp redial daemon successfully stopped May 3 03:00:01 DD-WRT daemon.notice pppd[27903]: pppd 2.4.7 started by root, uid 0 May 3 03:00:01 DD-WRT user.info : ppp_redial : redial process successfully started May 3 03:00:08 DD-WRT user.info : vpn modules : vpn modules successfully unloaded May 3 03:00:08 DD-WRT user.info : vpn modules : nf_conntrack_proto_gre successfully loaded May 3 03:00:08 DD-WRT user.info : vpn modules : nf_nat_proto_gre successfully loaded May 3 03:00:08 DD-WRT user.info : vpn modules : nf_conntrack_pptp successfully loaded May 3 03:00:08 DD-WRT user.info : vpn modules : nf_nat_pptp successfully loaded May 3 03:00:08 DD-WRT user.info : process_monitor : Process Monitor successfully stopped May 3 03:00:08 DD-WRT user.info : process_monitor successfully started May 3 03:00:08 DD-WRT user.info : upnp : upnp daemon successfully stopped May 3 03:00:08 DD-WRT daemon.debug process_monitor[27999]: We need to re-update after 3600 seconds May 3 03:00:08 DD-WRT daemon.info process_monitor[27999]: set timer: 3600 seconds, callback: ntp_main() May 3 03:00:09 DD-WRT user.info : vpn modules : vpn modules successfully unloaded May 3 03:00:09 DD-WRT user.info : vpn modules : nf_conntrack_proto_gre successfully loaded May 3 03:00:09 DD-WRT user.info : vpn modules : nf_nat_proto_gre successfully loaded May 3 03:00:09 DD-WRT user.info : vpn modules : nf_conntrack_pptp successfully loaded May 3 03:00:09 DD-WRT user.info : vpn modules : nf_nat_pptp successfully loaded

Share this post

Link to post

Vimes    4

Vimes
Posted ...

Is the "Force Reconnect" option enabled and set to 3:00 am?

 

 

Woot you might have found it

 

 

DD_WRT.7800_build_31900_M_Setup.png

 

 

Under my PPPOE connection tab there was the above ticked, never knew that.

 

Excellent find there and most appreciated.

 

I have unticked and applied that now.

 

Many thanks

Share this post

Link to post

Vimes    4

Vimes
Posted ...

This now is marked as solved as the Force reconnect option was the issue.

 

Thanks again.

Share this post

Link to post
Guest
This topic is now closed to further replies.
Go To Topic Listing
×
×
  • Create New...