What's new

How to auto-restart remote clients (an Asus RT-AC68U) OpenVPN client

  • 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!

Yup, agreed. Will see how it goes tonight. Will report findings. Thanks.
Just rebooted the RT-AC68U side and observed the log on the AX86U side and this is what log captured on the server /RT-AX86U side after the reboot and the client didn't connect (replaced the original IP of the client with X.X.X.X):

Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=RT-AX86U, emailAddress=me@asusrouter.lan
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=client, emailAddress=me@asusrouter.lan
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_VER=2.6.3
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_PLAT=linux
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_TCPNL=1
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_MTU=1600
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_NCP=2
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_PROTO=990
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_LZO_STUB=1
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_COMP_STUB=1
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_COMP_STUBv2=1
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 TLS: Username/Password authentication succeeded for username 'some name'
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 TLS: tls_multi_process: initial untrusted session promoted to trusted
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 [client] Peer Connection Initiated with [AF_INET6]::ffff:[X.X.X.Xclient side]:32922 (via ::ffff:[X.X.X.X server side]%eth0)
Aug 31 13:18:51 ovpn-server1[13096]: client/X.X.X.X:32922 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Aug 31 13:18:51 ovpn-server1[13096]: client/X.X.X.X:32922 MULTI: Learn: 10.8.0.2 -> client/X.X.X.X:32922
Aug 31 13:18:51 ovpn-server1[13096]: client/X.X.X.X:32922 MULTI: primary virtual IP for client/X.X.X.X:32922: 10.8.0.2
Aug 31 13:18:51 ovpn-server1[13096]: client/X.X.X.X:32922 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.50.0 255.255.255.0 vpn_gateway 500,dhcp-option DNS 9.9.9.11,dhcp-option DNS 149.112.112.11,redirect-gateway def1,explicit-exit-notify 3,route-gateway 10.8.0.1,topology subnet,ping 15,ping-restart 60,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)
Aug 31 13:18:52 ovpn-server1[13096]: client/X.X.X.X:32922 Data Channel: cipher 'AES-256-GCM', peer-id: 0
Aug 31 13:18:52 ovpn-server1[13096]: client/X.X.X.X:32922 Timers: ping 15, ping-restart 120
Aug 31 13:18:52 ovpn-server1[13096]: client/X.X.X.X:32922 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt

Not sure I follow what the entry is all about since the client didn't reconnect till I did it manually.
 
Last edited:
Just rebooted the RT-AC68U side and observed the log on the AX86U side and this is what log captured on the server /RT-AX86U side after the reboot and the client didn't connect (replaced the original IP of the client with X.X.X.X):

Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=RT-AX86U, emailAddress=me@asusrouter.lan


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=client, emailAddress=me@asusrouter.lan


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_VER=2.6.3


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_PLAT=linux


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_TCPNL=1


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_MTU=1600


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_NCP=2


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_PROTO=990


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_LZO_STUB=1


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_COMP_STUB=1


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 peer info: IV_COMP_STUBv2=1


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 TLS: Username/Password authentication succeeded for username 'admin'


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 TLS: tls_multi_process: initial untrusted session promoted to trusted


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256


Aug 31 13:18:51 ovpn-server1[13096]: X.X.X.X:32922 [client] Peer Connection Initiated with [AF_INET6]::ffff:[X.X.X.Xclient side]:32922 (via ::ffff:[X.X.X.X server side]%eth0)


Aug 31 13:18:51 ovpn-server1[13096]: client/X.X.X.X:32922 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)


Aug 31 13:18:51 ovpn-server1[13096]: client/X.X.X.X:32922 MULTI: Learn: 10.8.0.2 -> client/X.X.X.X:32922


Aug 31 13:18:51 ovpn-server1[13096]: client/X.X.X.X:32922 MULTI: primary virtual IP for client/X.X.X.X:32922: 10.8.0.2


Aug 31 13:18:51 ovpn-server1[13096]: client/X.X.X.X:32922 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.50.0 255.255.255.0 vpn_gateway 500,dhcp-option DNS 9.9.9.11,dhcp-option DNS 149.112.112.11,redirect-gateway def1,explicit-exit-notify 3,route-gateway 10.8.0.1,topology subnet,ping 15,ping-restart 60,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)


Aug 31 13:18:52 ovpn-server1[13096]: client/X.X.X.X:32922 Data Channel: cipher 'AES-256-GCM', peer-id: 0


Aug 31 13:18:52 ovpn-server1[13096]: client/X.X.X.X:32922 Timers: ping 15, ping-restart 120


Aug 31 13:18:52 ovpn-server1[13096]: client/X.X.X.X:32922 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt


Not sure I follow what the entry is all about since client didn't reconnect will I did it manually.
This is log info after I initiated manual re-connection (again client IP replaced with X.X.X.X and server side with Y.Y.Y.Y):

Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=RT-AX86U, emailAddress=me@asusrouter.lan
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=client, emailAddress=me@asusrouter.lan
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 peer info: IV_VER=2.6.3
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 peer info: IV_PLAT=linux
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 peer info: IV_TCPNL=1
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 peer info: IV_MTU=1600
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 peer info: IV_NCP=2
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 peer info: IV_PROTO=990
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 peer info: IV_LZO_STUB=1
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 peer info: IV_COMP_STUB=1
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 peer info: IV_COMP_STUBv2=1
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 TLS: Username/Password authentication succeeded for username 'admin'
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 TLS: tls_multi_process: initial untrusted session promoted to trusted
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Aug 31 14:06:15 ovpn-server1[13096]: X.X.X.X:53531 [client] Peer Connection Initiated with [AF_INET6]::ffff:X.X.X.X:53531 (via ::ffff:Y.Y.Y.Y%eth0)
Aug 31 14:06:15 ovpn-server1[13096]: client/X.X.X.X:53531 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Aug 31 14:06:15 ovpn-server1[13096]: client/X.X.X.X:53531 MULTI: Learn: 10.8.0.2 -> client/X.X.X.X:53531
Aug 31 14:06:15 ovpn-server1[13096]: client/X.X.X.X:53531 MULTI: primary virtual IP for client/X.X.X.X:53531: 10.8.0.2
Aug 31 14:06:15 ovpn-server1[13096]: client/X.X.X.X:53531 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.50.0 255.255.255.0 vpn_gateway 500,dhcp-option DNS 9.9.9.11,dhcp-option DNS 149.112.112.11,redirect-gateway def1,explicit-exit-notify 3,route-gateway 10.8.0.1,topology subnet,ping 15,ping-restart 60,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)
Aug 31 14:06:16 ovpn-server1[13096]: client/X.X.X.X:53531 Data Channel: cipher 'AES-256-GCM', peer-id: 0
Aug 31 14:06:16 ovpn-server1[13096]: client/X.X.X.X:53531 Timers: ping 15, ping-restart 120
Aug 31 14:06:16 ovpn-server1[13096]: client/X.X.X.X:53531 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
 
So both logs are identical apart from the dynamic port being used. So any clues would have to come from the log on the client side. You can see that it connected from the server's log. What happened after that in the corresponding client log?
 
So both logs are identical apart from the dynamic port being used. So any clues would have to come from the log on the client side. You can see that it connected from the server's log. What happened after that in the corresponding client log?

Log info at the time from the client side. I replaced only the server IP with [CLIENT IP Y.Y.Y.Y]: attached file since post wouldn't allow me due to the data size.
 

Attachments

  • loginfo.txt
    16.5 KB · Views: 36
Log info at the time from the client side. I replaced only the server IP with [CLIENT IP Y.Y.Y.Y]: attached file since post wouldn't allow me due to the data size.
We need to see the client logs from ~13:18 onwards.
 
We need to see the client logs from ~13:18 onwards.
Unfortunately, I had other things to do, and by the time I saw your message the log flipped and even the syslog.log-1 has retained only Aug 31 14:17:37 unward.

The reboots happened at 1am (client side on RT-AC68U) and 3 am (the server side RT-AX86U), and VPN session never got re-establsihed. So the UI config feeature of auto connection at the time of device reboot /restart is clealry not working on this AC68U even with the latest merlin code running.


Found this in the log (ip replaced with X.X.X.X) and am not sure is it related to this but when client session to the server is initiated manually there are no issues with cipher or anything, it simply connects and works as designed/configured :
Aug 31 14:40:42 ovpn-client1[7754]: Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Aug 31 14:40:42 ovpn-client1[7754]: OpenVPN 2.6.3 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Aug 31 14:40:42 ovpn-client1[7754]: library versions: OpenSSL 1.1.1t 7 Feb 2023, LZO 2.08
Aug 31 14:40:42 ovpn-client1[7755]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 31 14:40:42 ovpn-client1[7755]: TCP/UDP: Preserving recently used remote address: [AF_INET]X.X.X.X:443
Aug 31 14:40:42 ovpn-client1[7755]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Aug 31 14:40:42 ovpn-client1[7755]: UDPv4 link local: (not bound)
Aug 31 14:40:42 ovpn-client1[7755]: UDPv4 link remote: [AF_INET]X.X.X.X:443
Aug 31 14:40:42 ovpn-client1[7755]: TLS: Initial packet from [AF_INET]X.X.X.X:443, sid=8f380ccd f0a9a23e
Aug 31 14:40:42 ovpn-client1[7755]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
 
Unfortunately, I had other things to do, and by the time I saw your message the log flipped and even the syslog.log-1 has retained only Aug 31 14:17:37 unward.

The reboots happened at 1am (client side on RT-AC68U) and 3 am (the server side RT-AX86U), and VPN session never got re-establsihed. So the UI config feeature of auto connection at the time of device reboot /restart is clealry not working on this AC68U even with the latest merlin code running.


Found this in the log (ip replaced with X.X.X.X) and am not sure is it related to this but when client session to the server is initiated manually there are no issues with cipher or anything, it simply connects and works as designed/configured :
Aug 31 14:40:42 ovpn-client1[7754]: Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Aug 31 14:40:42 ovpn-client1[7754]: OpenVPN 2.6.3 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Aug 31 14:40:42 ovpn-client1[7754]: library versions: OpenSSL 1.1.1t 7 Feb 2023, LZO 2.08
Aug 31 14:40:42 ovpn-client1[7755]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 31 14:40:42 ovpn-client1[7755]: TCP/UDP: Preserving recently used remote address: [AF_INET]X.X.X.X:443
Aug 31 14:40:42 ovpn-client1[7755]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Aug 31 14:40:42 ovpn-client1[7755]: UDPv4 link local: (not bound)
Aug 31 14:40:42 ovpn-client1[7755]: UDPv4 link remote: [AF_INET]X.X.X.X:443
Aug 31 14:40:42 ovpn-client1[7755]: TLS: Initial packet from [AF_INET]X.X.X.X:443, sid=8f380ccd f0a9a23e
Aug 31 14:40:42 ovpn-client1[7755]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Additional question Colin. Due to some DNS issues I had in the past, I am restarting dns deamon hourly as to service restart_dnsmasq and wonder can that be the issue. Decided before you even respond to this to disable that script and kill that cron job, and see will it help.
 
We need to see the client logs from ~13:18 onwards.
Additional question as I have a feeling relevant to this. Both client and server side routers are set to the same time zone. However, the client router is physically located in EU while server side router in USA. They have near identical time since they use same NTP service. Should I leave as is or set the router in EU to the local time zone?
 
Additional question as I have a feeling relevant to this. Both client and server side routers are set to the same time zone. However, the client router is physically located in EU while server side router in USA. They have near identical time since they use same NTP service. Should I leave as is or set the router in EU to the local time zone?
Each router should have the correct timezone set for their location. NTP servers, regardless of their location, return the time in UTC only.
 
Each router should have the correct timezone set for their location. NTP servers, regardless of their location, return the time in UTC only.
Thank you for the follow-up. Agreed. Will change that config as soon as I get a chance. My remote location is now unavailable till tomorrow due to some maintenance. Will report how things progress with changes made, since I removed DNS daemon/service restarts and some other things I had running and will only leave the reboot script in cron for 1am local time.
 
Changed routers time zone and ensured it is on the client side using local EU time. Also removed crontabd since it had some cron jobs I no longer need and added only restart cron job for nightly 1 am cycle. Booted few times and VPN never came up. ...so auto re-connect definitely does not work with all changes tried so far based on our posts here and my independent research.

Then, on the client side, added cron job as to service start_vpnclient1 to be done every morning at 8am because I care for that VPN tunnel to be up during the regular business hours on the client end and will check is the VPN session active as of 8 am EU time which is 2 am EDT in US.

Any other ideas I am open for any suggestions but the default option in config to auto start at the reboot definitely DOES NOT work on Merlin 386.11 code on Asus RT-AC68U (at least not on my router and am not in the mood to restore to factory and start from scratch because all other I need works fine).
 
I'm still waiting to see a log file from the client side that shows the client disconnecting and failing to reconnect. That was the missing information from before.
 
I'm still waiting to see a log file from the client side that shows the client disconnecting and failing to reconnect. That was the missing information from before.
As indicated that log has flipped from the other night when I had no access due to the local network maintenance. Attached here is the latest syslog I took of the client side after the reboot fe wmin ago. Within this file the starting point is Sep 2 19:08:02 system: Rebooting... and afterward, at least I don't even see the client attempting to connect but it sure wants to route the devices that are set in VPN Director....then I did manual VPN client initiation and that is at Sep 2 19:17:02 rc_service: httpd 311:notify_rc start_vpnclient1. I will keep this file attached here for about an hour and then delete it because I am not comfortable sharing it with just about anyone. Let me know if you got it when you got it.
 
Can you SSH into the remote router and post the output of these commands:
Code:
nvram get vpn_client1_state
nvram get vpn_client1_errno
nvram get vpn_clientx_eas
 
Last edited:
[Begin cheerleading] Watching this closely and thanks for the effort being put into this. A key differentiating feature of AsusMerlin is the ability to have 2 servers and clients to be able to have a chance to go in and fix something on either side, and boy have I needed it. Like the OP, my locations are not physically accessible for months on end. I've been lucky that autostart has always worked, but like the OP I have used reboots (in my case, weekly), to provide a last line of defense. [End cheerleading]
 
Can you SSH into the remote router and post the output of these commands:
Code:
nvram get vpn_client1_state
nvram get vpn_client1_errno
nvram get vpn_clientx_eas
admin@RT-AC68U-9B30:/tmp/home/root# nvram get vpn_client1_state
2
admin@RT-AC68U-9B30:/tmp/home/root# nvram get vpn_client1_errno
0
admin@RT-AC68U-9B30:/tmp/home/root# nvram get vpn_clientx_eas
1,
 
admin@RT-AC68U-9B30:/tmp/home/root# nvram get vpn_client1_state
2
admin@RT-AC68U-9B30:/tmp/home/root# nvram get vpn_client1_errno
0
admin@RT-AC68U-9B30:/tmp/home/root# nvram get vpn_clientx_eas
1,
Thanks. That looks OK.

The problem after the reboot is that the router is cancelling the queued VPN start:
Rich (BB code):
Sep  2 19:10:47 rc_service: ntpd_synced 984:notify_rc start_vpnclient1
Sep  2 19:10:47 rc_service: waitting "restart_firewall" via  ...
Sep  2 19:10:47 rc_service: skip the event: stop_ntpd.
Sep  2 19:10:47 rc_service: wanduck 239:notify_rc start_ntpd
Sep  2 19:10:47 rc_service: waitting "restart_firewall" via  ...
Sep  2 19:11:02 rc_service: skip the event: start_vpnclient1.
Sep  2 19:11:02 rc_service: skip the event: start_ntpd.

I don't know why it's doing that but it sounds the same as this post: https://www.snbforums.com/threads/release-asuswrt-merlin-384-11-is-available.56501/post-497576 Do you have a custom firewall script? What do you have in services-start ?

I think this is a separate issue to your overnight reconnection problem though. When it happens again tonight save the entire log for us to look at.

P.S. Can you also set "Log only messages more urgent than" to All on the System Log - General Log page.
 
Last edited:
OK I've go that file.

I think I'm loosing track of what problem we're trying to diagnose now. In the beginning you said the client was loosing connection when you rebooted the server. Now we seem to be talking about an issue after rebooting the client router. They're two different issues (if indeed the original issue exists at all).
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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