Menu
What's new
By:
Filters Better Search

vpnmgr NordVPN failing to connect

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

Viktor Jaep

Viktor Jaep

Part of the Furniture
Every so often, I'll check my IP location, and find that my RT-AC86U (386.3_2) is not connected to NordVPN... This happens occasionally, maybe 1x every few weeks. I'm using VPNMGR (big thanks to @Jack Yaz ). I have it resetting its connection at midnight. The way I get it to connect again is by going into VPNMGR, click on "refresh" cached data, and hit "save". This will reconnect the VPN successfully to NordVPN. I'm trying to figure out why it is not able to recover from this by itself, and included some logs below? Might it be prudent of VPNMGR to automatically force another refresh of NordVPN server data if it gets a failed connect or two? I can understand that VPNMGR has now passed the baton, and is no longer aware of whats happening after it forces the reset... so I'm just trying to figure out what can be done here?

Dec 6 00:00:00 vpnmgr: Refreshing NordVPN country data...
Dec 6 00:00:02 vpnmgr: No changes in PIA OpenVPN file archives
Dec 6 00:00:02 vpnmgr: No changes in WeVPN OpenVPN file archives
Dec 6 00:02:00 vpnmgr: Retrieving recommended VPN server using NordVPN API with below parameters
Dec 6 00:02:00 vpnmgr: Protocol: UDP - Type: Standard - Country: United States
Dec 6 00:02:01 vpnmgr: Updating VPN client 2 to NordVPN server
Dec 6 00:02:01 rc_service: service 23130:notify_rc restart_vpnclient2
Dec 6 00:02:01 custom_script: Running /jffs/scripts/service-event (args: restart vpnclient2)
Dec 6 00:02:01 vpnmgr: VPN client 2 updated successfully (US6696 Standard UDP)
Dec 6 00:02:01 ovpn-client2[2457]: event_wait : Interrupted system call (code=4)
Dec 6 00:02:01 ovpn-client2[2457]: SIGTERM received, sending exit notification to peer
Dec 6 00:02:02 ovpn-client2[2457]: ovpn-route-pre-down tun12 1500 1584 10.8.2.4 255.255.255.0 init
Dec 6 00:02:02 ovpn-client2[2457]: Closing TUN/TAP interface
Dec 6 00:02:02 ovpn-client2[2457]: /usr/sbin/ip addr del dev tun12 10.8.2.4/24
Dec 6 00:02:02 ovpn-client2[2457]: ovpn-down 2 client tun12 1500 1584 10.8.2.4 255.255.255.0 init
Dec 6 00:02:02 ovpn-client2[2457]: SIGTERM[soft,exit-with-notification] received, process exiting
Dec 6 00:02:02 openvpn-routing: Clearing routing table for VPN client 2
Dec 6 00:02:02 ovpn-client2[23253]: --cipher is not set. Previous OpenVPN version 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.
Dec 6 00:02:02 ovpn-client2[23253]: OpenVPN 2.5.3 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug 6 2021
Dec 6 00:02:02 ovpn-client2[23253]: library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.08
Dec 6 00:02:02 ovpn-client2[23254]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 6 00:02:02 ovpn-client2[23254]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 6 00:02:02 ovpn-client2[23254]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 6 00:02:02 ovpn-client2[23254]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 6 00:02:02 ovpn-client2[23254]: TCP/UDP: Preserving recently used remote address: [AF_INET]89.157.17.191:1194
Dec 6 00:02:02 ovpn-client2[23254]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 6 00:02:02 ovpn-client2[23254]: UDP link local: (not bound)
Dec 6 00:02:02 ovpn-client2[23254]: UDP link remote: [AF_INET]89.157.17.191:1194
Dec 6 00:02:02 ovpn-client2[23254]: write UDP: Operation not permitted (code=1)
Dec 6 00:02:04 ovpn-client2[23254]: write UDP: Operation not permitted (code=1)
Dec 6 00:02:08 ovpn-client2[23254]: write UDP: Operation not permitted (code=1)
Dec 6 00:02:16 ovpn-client2[23254]: write UDP: Operation not permitted (code=1)
Dec 6 00:02:32 ovpn-client2[23254]: write UDP: Operation not permitted (code=1)
Dec 6 00:03:02 ovpn-client2[23254]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec 6 00:03:02 ovpn-client2[23254]: TLS Error: TLS handshake failed
Dec 6 00:03:02 ovpn-client2[23254]: SIGUSR1[soft,tls-error] received, process restarting
Dec 6 00:03:02 ovpn-client2[23254]: Restart pause, 5 second(s)
Dec 6 00:03:07 ovpn-client2[23254]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 6 00:03:07 ovpn-client2[23254]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 6 00:03:07 ovpn-client2[23254]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 6 00:03:07 ovpn-client2[23254]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 6 00:03:07 ovpn-client2[23254]: TCP/UDP: Preserving recently used remote address: [AF_INET]89.157.17.191:1194
Dec 6 00:03:07 ovpn-client2[23254]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 6 00:03:07 ovpn-client2[23254]: UDP link local: (not bound)
Dec 6 00:03:07 ovpn-client2[23254]: UDP link remote: [AF_INET]89.157.17.191:1194
Dec 6 00:03:07 ovpn-client2[23254]: write UDP: Operation not permitted (code=1)
Dec 6 00:03:09 ovpn-client2[23254]: write UDP: Operation not permitted (code=1)
Dec 6 00:03:13 ovpn-client2[23254]: write UDP: Operation not permitted (code=1)
Dec 6 00:03:21 ovpn-client2[23254]: write UDP: Operation not permitted (code=1)
Dec 6 00:03:37 ovpn-client2[23254]: write UDP: Operation not permitted (code=1)
....
And it just keeps looping like this until I manually intervene.

This is the custom config I'm using:

remote-random
resolv-retry infinite
remote-cert-tls server
ping 15
ping-restart 0
ping-timer-rem
persist-key
persist-tun
reneg-sec 0
fast-io
disable-occ
mute-replay-warnings
auth-nocache
sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"
pull-filter ignore "auth-token"
pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"
explicit-exit-notify 3
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450

As always, your help with this is very much appreciated!
 
I'm NOT familiar w/ VPNMGR, so putting that aside, it's my recommendation that users of OpenVPN client always do two things; a) specify multiple servers (as in multiple remote directives in the custom config field), and b) include a watchdog.

www.snbforums.com

ASUS RT-AC86U - ExpressVPN disconnecting

Hello guys, i have a ASUS RT-AC86U with Merlin 384.19 build. I've been struggling to get a stable connection with ExpressVPN for weeks. I setup the OpenVPN Client like with every other VPN Provider but i always getting disconnect after a few hours. Sometimes it's working for 2 hours and...
www.snbforums.com www.snbforums.com

pastebin.com

merlin-ovpn-client-watchdog.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
pastebin.com pastebin.com

In the former case, you never want to assume the same server is going to be available 24/7/365. ALL servers need to come down for various reasons, be it maintenance, overloading, etc. In the latter case, relying on a failed OpenVPN client to get restarted on its own is a bad bet.
 
eibgrad said:
I'm NOT familiar w/ VPNMGR, so putting that aside, it's my recommendation that users of OpenVPN client always do two things; a) specify multiple servers (as in multiple remote directives in the custom config field), and b) include a watchdog.

In the former case, you never want to assume the same server is going to be available 24/7/365. ALL servers need to come down for various reasons, be it maintenance, overloading, etc. In the latter case, relying on a failed OpenVPN client to get restarted on its own is a bad bet.
Click to expand...

Thanks for the suggestions, @eibgrad! So, the beauty of the vpnmgr here is that it queries NordVPN's API for a current list of servers closest to you, and populates the #1 server in your VPN slot:

Dec 6 00:02:00 vpnmgr: Retrieving recommended VPN server using NordVPN API with below parameters
Dec 6 00:02:00 vpnmgr: Protocol: UDP - Type: Standard - Country: United States
Dec 6 00:02:01 vpnmgr: Updating VPN client 2 to NordVPN server

I have a feeling it's somehow failing to do that though, as it doesn't take 1 second to do all this... When I perform this function manually with vpnmgr, it can take upwards of 5+ seconds to complete. Needless to say, I do like your idea of using this watchdog, to see if it has a positive effect. Seeing that my services-start script is already being used, what command should I be using in this script to get this to run? Sorry, I'm still a bit of a n00b when it comes to scripting. Hey, at least I was able to copy it over, and run it... ;)

Thank you!
 
Have you tried just using a default configuration file provided by Nord VPN?

I haven't found that any custom config settings beyond what the VPN provider includes in their configuration file improves through put. Since Nord controls their servers they probably ignore some or all of the settings you have added and there is also the possibility make the connection unstable and harder to restart.

Perhaps your result does improves with Nord using some of the custom setting but as I said I never found any improvement with PIA, Astrill or Strong.
 
Viktor Jaep said:
Seeing that my services-start script is already being used, what command should I be using in this script to get this to run?
Click to expand...

That's always the tricky part when it comes to multiple scripts that require the same event handler. Since I know nothing about the other script, you're just going to have to install my script elsewhere (probably under another name) and call it from the other script (or vice versa). One of the reasons I don't do it automatically is precisely because I can't anticipate what issues/conflicts might arise. YOU have to make those determinations.
 
next time it happens, can you check if simply restarting the VPN client over ssh works?
Code: 
service restart_vpnclient2
I've seen (rarely) that the restart command doesn't seem to fully tear down the tunnel. it's on my to-do to improve in vpnmgr when I start active dev again
 
CaptainSTX said:
Have you tried just using a default configuration file provided by Nord VPN?

I haven't found that any custom config settings beyond what the VPN provider includes in their configuration file improves through put. Since Nord controls their servers they probably ignore some or all of the settings you have added and there is also the possibility make the connection unstable and harder to restart.

Perhaps your result does improves with Nord using some of the custom setting but as I said I never found any improvement with PIA, Astrill or Strong.
Click to expand...
I was initially using the default config, but ended up using the current version based on others experiences with Nordvpn and vpnmgr... this actually has helped speed things up considerably compared to default settings. But you're right... who knows, it could be a single item in this config statement throwing the inability for it to properly reconnect. The fact that it usually works right makes it even more frustrating. ;)
 
Jack Yaz said:
next time it happens, can you check if simply restarting the VPN client over ssh works?
Code: 
service restart_vpnclient2
I've seen (rarely) that the restart command doesn't seem to fully tear down the tunnel. it's on my to-do to improve in vpnmgr when I start active dev again
Click to expand...
You got it... Thanks for the suggestion, and will check back with results in the near future. ;)
 
Jack Yaz said:
next time it happens, can you check if simply restarting the VPN client over ssh works?
Code: 
service restart_vpnclient2
I've seen (rarely) that the restart command doesn't seem to fully tear down the tunnel. it's on my to-do to improve in vpnmgr when I start active dev again
Click to expand...

Well, this happened sooner than expected... so here's some feedback/logs. It was looping again after being unable to reconnect to Nordvpn after vpnmgr did it's reset last night, so here's the executive summary with more detailed logs following:

1. After midnight's automatic vpnmgr reset, the ovpn-client2 continued to try to make a connection, and kept failing on the TLS handshake
2. This morning, per your suggestion, I executed the "service restart_vpnclient2", and it continued to fail in the same failed TLS handshake fashion
3. Then I went through the process of refreshing the cache through vpnmgr, hit "save", and it successfully connected back to Nordvpn without any issue.

So here are the logs...

The looping behavior after a failed vpnmgr refresh:
Code: 
...
Dec  8 09:40:45 ovpn-client2[25560]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec  8 09:40:45 ovpn-client2[25560]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec  8 09:40:45 ovpn-client2[25560]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec  8 09:40:45 ovpn-client2[25560]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec  8 09:40:45 ovpn-client2[25560]: TCP/UDP: Preserving recently used remote address: [AF_INET]98.178.117.160:1194
Dec  8 09:40:45 ovpn-client2[25560]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec  8 09:40:45 ovpn-client2[25560]: UDP link local: (not bound)
Dec  8 09:40:45 ovpn-client2[25560]: UDP link remote: [AF_INET]98.178.117.160:1194
Dec  8 09:40:45 ovpn-client2[25560]: write UDP: Operation not permitted (code=1)
Dec  8 09:40:47 ovpn-client2[25560]: write UDP: Operation not permitted (code=1)
Dec  8 09:40:51 ovpn-client2[25560]: write UDP: Operation not permitted (code=1)
Dec  8 09:41:00 ovpn-client2[25560]: write UDP: Operation not permitted (code=1)
Dec  8 09:41:16 ovpn-client2[25560]: write UDP: Operation not permitted (code=1)
Dec  8 09:41:45 ovpn-client2[25560]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  8 09:41:45 ovpn-client2[25560]: TLS Error: TLS handshake failed
Dec  8 09:41:45 ovpn-client2[25560]: SIGUSR1[soft,tls-error] received, process restarting
Dec  8 09:41:45 ovpn-client2[25560]: Restart pause, 300 second(s)
...

The behavior experienced after executing "service restart_vpnclient2":
Code: 
...
Dec  8 10:01:37 rc_service: service 8519:notify_rc restart_vpnclient2
Dec  8 10:01:37 custom_script: Running /jffs/scripts/service-event (args: restart vpnclient2)
Dec  8 10:01:37 ovpn-client2[25560]: SIGTERM[hard,init_instance] received, process exiting
Dec  8 10:01:37 openvpn-routing: Clearing routing table for VPN client 2
Dec  8 10:01:38 ovpn-client2[8617]: --cipher is not set. Previous OpenVPN version 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.
Dec  8 10:01:38 ovpn-client2[8617]: OpenVPN 2.5.3 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug  6 2021
Dec  8 10:01:38 ovpn-client2[8617]: library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.08
Dec  8 10:01:38 ovpn-client2[8618]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec  8 10:01:38 ovpn-client2[8618]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec  8 10:01:38 ovpn-client2[8618]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec  8 10:01:38 ovpn-client2[8618]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec  8 10:01:38 ovpn-client2[8618]: TCP/UDP: Preserving recently used remote address: [AF_INET]98.178.117.160:1194
Dec  8 10:01:38 ovpn-client2[8618]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec  8 10:01:38 ovpn-client2[8618]: UDP link local: (not bound)
Dec  8 10:01:38 ovpn-client2[8618]: UDP link remote: [AF_INET]98.178.117.160:1194
Dec  8 10:01:38 ovpn-client2[8618]: write UDP: Operation not permitted (code=1)
Dec  8 10:01:40 ovpn-client2[8618]: write UDP: Operation not permitted (code=1)
Dec  8 10:01:44 ovpn-client2[8618]: write UDP: Operation not permitted (code=1)
Dec  8 10:01:52 ovpn-client2[8618]: write UDP: Operation not permitted (code=1)
Dec  8 10:02:08 ovpn-client2[8618]: write UDP: Operation not permitted (code=1)
Dec  8 10:02:38 ovpn-client2[8618]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  8 10:02:38 ovpn-client2[8618]: TLS Error: TLS handshake failed
Dec  8 10:02:38 ovpn-client2[8618]: SIGUSR1[soft,tls-error] received, process restarting
Dec  8 10:02:38 ovpn-client2[8618]: Restart pause, 5 second(s)
...
Dec  8 10:02:43 ovpn-client2[8618]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec  8 10:02:43 ovpn-client2[8618]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec  8 10:02:43 ovpn-client2[8618]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec  8 10:02:43 ovpn-client2[8618]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec  8 10:02:43 ovpn-client2[8618]: TCP/UDP: Preserving recently used remote address: [AF_INET]98.178.117.160:1194
Dec  8 10:02:43 ovpn-client2[8618]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec  8 10:02:43 ovpn-client2[8618]: UDP link local: (not bound)
Dec  8 10:02:43 ovpn-client2[8618]: UDP link remote: [AF_INET]98.178.117.160:1194
Dec  8 10:02:43 ovpn-client2[8618]: write UDP: Operation not permitted (code=1)
Dec  8 10:02:45 ovpn-client2[8618]: write UDP: Operation not permitted (code=1)
Dec  8 10:02:49 ovpn-client2[8618]: write UDP: Operation not permitted (code=1)
Dec  8 10:02:57 ovpn-client2[8618]: write UDP: Operation not permitted (code=1)
Dec  8 10:03:13 ovpn-client2[8618]: write UDP: Operation not permitted (code=1)
Dec  8 10:03:43 ovpn-client2[8618]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  8 10:03:43 ovpn-client2[8618]: TLS Error: TLS handshake failed
Dec  8 10:03:43 ovpn-client2[8618]: SIGUSR1[soft,tls-error] received, process restarting
Dec  8 10:03:43 ovpn-client2[8618]: Restart pause, 5 second(s)
...

Continuing logs in the next post due to 10,000 char limits...

Hope this is beneficial, @Jack Yaz! Thanks for your help and advice on this...
 
And the output after manually refreshing vpnmgr, and hitting "Save":
Code: 
...
Dec  8 10:06:20 rc_service: httpd 1616:notify_rc start_vpnmgrcheckupdate
Dec  8 10:06:20 custom_script: Running /jffs/scripts/service-event (args: start vpnmgrcheckupdate)
Dec  8 10:06:23 rc_service: httpd 1616:notify_rc start_vpnmgrrefreshcacheddata
Dec  8 10:06:23 custom_script: Running /jffs/scripts/service-event (args: start vpnmgrrefreshcacheddata)
Dec  8 10:06:27 vpnmgr: Refreshing NordVPN country data...
Dec  8 10:06:28 vpnmgr: No changes in NordVPN country data
Dec  8 10:06:29 vpnmgr: Refreshing OpenVPN file archives...
Dec  8 10:06:30 vpnmgr: No changes in PIA OpenVPN file archives
Dec  8 10:06:30 vpnmgr: No changes in WeVPN OpenVPN file archives
Dec  8 10:06:41 rc_service: httpd 1616:notify_rc start_vpnmgr
Dec  8 10:06:41 custom_script: Running /jffs/scripts/service-event (args: start vpnmgr)
Dec  8 10:06:41 vpnmgr: Updated settings from WebUI found, merging into /jffs/addons/vpnmgr.d/config
Dec  8 10:06:43 vpnmgr: Merge of updated settings from WebUI completed successfully
Dec  8 10:06:43 vpnmgr: Removing management of VPN client 1
Dec  8 10:06:43 vpnmgr: Removing scheduled update for VPN client 1
Dec  8 10:06:43 vpnmgr: Scheduled update cancelled for VPN client 1
Dec  8 10:06:43 vpnmgr: Management of VPN client 1 successfully removed
Dec  8 10:06:43 vpnmgr: Enabling management of VPN client 2
Dec  8 10:06:43 vpnmgr: Management of VPN client 2 successfully enabled
Dec  8 10:06:43 vpnmgr: Configuring scheduled update for VPN client 2
Dec  8 10:06:43 vpnmgr: Scheduled update created for VPN client 2
Dec  8 10:06:43 vpnmgr: Retrieving recommended VPN server using NordVPN API with below parameters
Dec  8 10:06:43 vpnmgr: Protocol: UDP - Type: Standard - Country: United States - City: Atlanta
Dec  8 10:06:44 vpnmgr: Updating VPN client 2 to NordVPN server
Dec  8 10:06:45 rc_service: service 12739:notify_rc restart_vpnclient2
Dec  8 10:06:45 custom_script: Running /jffs/scripts/service-event (args: restart vpnclient2)
Dec  8 10:06:45 vpnmgr: VPN client 2 updated successfully (US8217 Standard UDP)
Dec  8 10:06:45 ovpn-client2[8618]: event_wait : Interrupted system call (code=4)
Dec  8 10:06:45 ovpn-client2[8618]: SIGTERM received, sending exit notification to peer
Dec  8 10:06:45 vpnmgr: Removing management of VPN client 3
Dec  8 10:06:45 vpnmgr: Removing scheduled update for VPN client 3
Dec  8 10:06:45 vpnmgr: Scheduled update cancelled for VPN client 3
Dec  8 10:06:45 vpnmgr: Management of VPN client 3 successfully removed
Dec  8 10:06:45 vpnmgr: Removing management of VPN client 4
Dec  8 10:06:45 vpnmgr: Removing scheduled update for VPN client 4
Dec  8 10:06:45 vpnmgr: Scheduled update cancelled for VPN client 4
Dec  8 10:06:45 vpnmgr: Management of VPN client 4 successfully removed
Dec  8 10:06:45 vpnmgr: Removing management of VPN client 5
Dec  8 10:06:45 vpnmgr: Removing scheduled update for VPN client 5
Dec  8 10:06:45 vpnmgr: Scheduled update cancelled for VPN client 5
Dec  8 10:06:45 vpnmgr: Management of VPN client 5 successfully removed
Dec  8 10:06:48 ovpn-client2[8618]: SIGTERM[soft,exit-with-notification] received, process exiting
Dec  8 10:06:48 openvpn-routing: Clearing routing table for VPN client 2
Dec  8 10:06:48 ovpn-client2[12930]: --cipher is not set. Previous OpenVPN version 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.
Dec  8 10:06:48 ovpn-client2[12930]: OpenVPN 2.5.3 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug  6 2021
Dec  8 10:06:48 ovpn-client2[12930]: library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.08
Dec  8 10:06:48 ovpn-client2[12931]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec  8 10:06:48 ovpn-client2[12931]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec  8 10:06:48 ovpn-client2[12931]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec  8 10:06:48 ovpn-client2[12931]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec  8 10:06:48 ovpn-client2[12931]: TCP/UDP: Preserving recently used remote address: [AF_INET]94.191.71.195:1194
Dec  8 10:06:48 ovpn-client2[12931]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec  8 10:06:48 ovpn-client2[12931]: UDP link local: (not bound)
Dec  8 10:06:48 ovpn-client2[12931]: UDP link remote: [AF_INET]94.191.71.195:1194
Dec  8 10:06:48 ovpn-client2[12931]: TLS: Initial packet from [AF_INET]94.191.71.195:1194, sid=c87139bf c2fea6ae
Dec  8 10:06:48 ovpn-client2[12931]: VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
Dec  8 10:06:48 ovpn-client2[12931]: VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA6
Dec  8 10:06:48 ovpn-client2[12931]: VERIFY KU OK
Dec  8 10:06:48 ovpn-client2[12931]: Validating certificate extended key usage
Dec  8 10:06:48 ovpn-client2[12931]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Dec  8 10:06:48 ovpn-client2[12931]: VERIFY EKU OK
Dec  8 10:06:48 ovpn-client2[12931]: VERIFY OK: depth=0, CN=us8217.nordvpn.com
Dec  8 10:06:48 ovpn-client2[12931]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA512
Dec  8 10:06:48 ovpn-client2[12931]: [us8217.nordvpn.com] Peer Connection Initiated with [AF_INET]94.191.71.195:1194
Dec  8 10:06:49 ovpn-client2[12931]: SENT CONTROL [us8217.nordvpn.com]: 'PUSH_REQUEST' (status=1)
Dec  8 10:06:49 ovpn-client2[12931]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 103.86.96.100,dhcp-option DNS 103.86.99.100,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,comp-lzo no,route-gateway 10.8.1.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.8.1.9 255.255.255.0,peer-id 7,cipher AES-256-GCM'
Dec  8 10:06:49 ovpn-client2[12931]: OPTIONS IMPORT: timers and/or timeouts modified
Dec  8 10:06:49 ovpn-client2[12931]: OPTIONS IMPORT: explicit notify parm(s) modified
Dec  8 10:06:49 ovpn-client2[12931]: OPTIONS IMPORT: compression parms modified
Dec  8 10:06:49 ovpn-client2[12931]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Dec  8 10:06:49 ovpn-client2[12931]: Socket Buffers: R=[1048576->1048576] S=[1048576->1048576]
Dec  8 10:06:49 ovpn-client2[12931]: OPTIONS IMPORT: --ifconfig/up options modified
Dec  8 10:06:49 ovpn-client2[12931]: OPTIONS IMPORT: route options modified
Dec  8 10:06:49 ovpn-client2[12931]: OPTIONS IMPORT: route-related options modified
Dec  8 10:06:49 ovpn-client2[12931]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Dec  8 10:06:49 ovpn-client2[12931]: OPTIONS IMPORT: peer-id set
Dec  8 10:06:49 ovpn-client2[12931]: OPTIONS IMPORT: adjusting link_mtu to 1656
Dec  8 10:06:49 ovpn-client2[12931]: OPTIONS IMPORT: data channel crypto options modified
Dec  8 10:06:49 ovpn-client2[12931]: Data Channel: using negotiated cipher 'AES-256-GCM'
Dec  8 10:06:49 ovpn-client2[12931]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Dec  8 10:06:49 ovpn-client2[12931]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Dec  8 10:06:49 ovpn-client2[12931]: TUN/TAP device tun12 opened
Dec  8 10:06:49 ovpn-client2[12931]: TUN/TAP TX queue length set to 1000
Dec  8 10:06:49 ovpn-client2[12931]: /usr/sbin/ip link set dev tun12 up mtu 1500
Dec  8 10:06:49 ovpn-client2[12931]: /usr/sbin/ip link set dev tun12 up
Dec  8 10:06:49 ovpn-client2[12931]: /usr/sbin/ip addr add dev tun12 10.8.1.9/24
Dec  8 10:06:49 ovpn-client2[12931]: ovpn-up 2 client tun12 1500 1584 10.8.1.9 255.255.255.0 init
Dec  8 10:06:51 ovpn-client2[12931]: Initialization Sequence Completed

(Sorry for having to split this in 2 messages)
 
Sorry for not getting back to you. Can you try switching to the develop branch of vpnmgr?
Code: 
vpnmgr develop
I've implemented some changes to stop, wait 5 seconds, make sure the process is really dead, then start it again
 
Jack Yaz said:
Sorry for not getting back to you. Can you try switching to the develop branch of vpnmgr?
Code: 
vpnmgr develop
I've implemented some changes to stop, wait 5 seconds, make sure the process is really dead, then start it again
Click to expand...
Thanks @Jack Yaz! I've enabled the develop branch, and was about to send you the great news that it wasn't failing on me anymore... I tried resetting about 7x in a row, and each time, a successful connection was made, which was definitely a new record... but I guess it could have also been a fluke because on the 8th time, it failed... :( Here's the logs. Are there any vpnmgr specific logs I can pull for you?

Code: 
Dec 29 18:23:03 ovpn-client2[12035]: write UDP: Operation not permitted (code=1)
Dec 29 18:23:47 ovpn-client2[12035]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec 29 18:23:47 ovpn-client2[12035]: TLS Error: TLS handshake failed
Dec 29 18:23:47 ovpn-client2[12035]: SIGUSR1[soft,tls-error] received, process restarting
Dec 29 18:23:47 ovpn-client2[12035]: Restart pause, 5 second(s)
Dec 29 18:23:52 ovpn-client2[12035]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 29 18:23:52 ovpn-client2[12035]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 29 18:23:52 ovpn-client2[12035]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 29 18:23:52 ovpn-client2[12035]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 29 18:23:52 ovpn-client2[12035]: TCP/UDP: Preserving recently used remote address: [AF_INET]185.93.0.98:1194
Dec 29 18:23:52 ovpn-client2[12035]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 29 18:23:52 ovpn-client2[12035]: UDP link local: (not bound)
Dec 29 18:23:52 ovpn-client2[12035]: UDP link remote: [AF_INET]185.93.0.98:1194
Dec 29 18:23:52 ovpn-client2[12035]: write UDP: Operation not permitted (code=1)
Dec 29 18:23:54 ovpn-client2[12035]: write UDP: Operation not permitted (code=1)
Dec 29 18:23:58 ovpn-client2[12035]: write UDP: Operation not permitted (code=1)

I was also wondering what you thought of this idea... any idea to keep vpnmgr resident, or using a cron job to poll the ovpn-clients (each minute/selectable) to see if a vpn tunnel is successfully established and working... if not, perhaps go through a reset, and let it try again?
 
Viktor Jaep said:
Thanks @Jack Yaz! I've enabled the develop branch, and was about to send you the great news that it wasn't failing on me anymore... I tried resetting about 7x in a row, and each time, a successful connection was made, which was definitely a new record... but I guess it could have also been a fluke because on the 8th time, it failed... :( Here's the logs. Are there any vpnmgr specific logs I can pull for you?

Code: 
Dec 29 18:23:03 ovpn-client2[12035]: write UDP: Operation not permitted (code=1)
Dec 29 18:23:47 ovpn-client2[12035]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec 29 18:23:47 ovpn-client2[12035]: TLS Error: TLS handshake failed
Dec 29 18:23:47 ovpn-client2[12035]: SIGUSR1[soft,tls-error] received, process restarting
Dec 29 18:23:47 ovpn-client2[12035]: Restart pause, 5 second(s)
Dec 29 18:23:52 ovpn-client2[12035]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 29 18:23:52 ovpn-client2[12035]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 29 18:23:52 ovpn-client2[12035]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 29 18:23:52 ovpn-client2[12035]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 29 18:23:52 ovpn-client2[12035]: TCP/UDP: Preserving recently used remote address: [AF_INET]185.93.0.98:1194
Dec 29 18:23:52 ovpn-client2[12035]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 29 18:23:52 ovpn-client2[12035]: UDP link local: (not bound)
Dec 29 18:23:52 ovpn-client2[12035]: UDP link remote: [AF_INET]185.93.0.98:1194
Dec 29 18:23:52 ovpn-client2[12035]: write UDP: Operation not permitted (code=1)
Dec 29 18:23:54 ovpn-client2[12035]: write UDP: Operation not permitted (code=1)
Dec 29 18:23:58 ovpn-client2[12035]: write UDP: Operation not permitted (code=1)

I was also wondering what you thought of this idea... any idea to keep vpnmgr resident, or using a cron job to poll the ovpn-clients (each minute/selectable) to see if a vpn tunnel is successfully established and working... if not, perhaps go through a reset, and let it try again?
Click to expand...
perhaps we're looking at the wrong area -
https://www.reddit.com/r/OpenVPN/comments/hyy1nn
suggests it could be a firewall. so let's check!
Code: 
iptables -S
iptables -t raw -S
and for good measure, let's check routing tables
Code: 
ip rule show
ip route shown ovpnc2
 
Jack Yaz said:
perhaps we're looking at the wrong area - suggests it could be a firewall. so let's check!
Click to expand...

Thanks Jack... I split this up between the output of when I am experiencing a good connection to NordVPN, and when it's failing during a looping event... the only real difference (I could find) was that none of the ovpnc connections had any routing tables because they weren't connected yet... you see anything?

Output from a healthy connection to NordVPN:
Code: 
adm@RT-AC86U-BE10:/jffs/scripts# iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N ACCESS_RESTRICTION
-N DNSFILTER_DOT
-N FUPNP
-N INPUT_ICMP
-N INPUT_PING
-N NSFW
-N OVPN
-N PControls
-N PTCSRVLAN
-N PTCSRVWAN
-N SECURITY
-N default_block
-N logaccept
-N logdrop
-N other2wan
-A INPUT -i eth0 -p igmp -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j INPUT_PING
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j logdrop
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp -j INPUT_ICMP
-A INPUT -j logdrop
-A FORWARD -d 224.0.0.0/4 -i eth0 -j ACCEPT
-A FORWARD -i br0 -m time --timestart 00:00:00 --timestop 06:00:00 --kerneltz -m mac --mac-source 31:32:13:B5:39:34 -j PControls
-A FORWARD -i br0 -m mac --mac-source 31:32:13:B5:39:34 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD ! -i br0 -o eth0 -j other2wan
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -m state --state INVALID -j logdrop
-A FORWARD -j NSFW
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -m state --state NEW -j OVPN
-A FORWARD -j logdrop
-A FUPNP -d 192.168.1.54/32 -p udp -m udp --dport 3074 -j ACCEPT
-A FUPNP -d 192.168.1.54/32 -p udp -m udp --dport 2003 -j ACCEPT
-A INPUT_ICMP -p icmp -m icmp --icmp-type 8 -j RETURN
-A INPUT_ICMP -p icmp -m icmp --icmp-type 13 -j RETURN
-A INPUT_ICMP -p icmp -j ACCEPT
-A INPUT_PING -i eth0 -p icmp -j logdrop
-A OVPN -i tun14 -j DROP
-A PControls -i br0 -o br0 -j logdrop
-A PControls -m state --state INVALID -j logdrop
-A PControls -j NSFW
-A PControls -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j logdrop
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j logdrop
-A SECURITY -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -j DROP
-A other2wan -i tun+ -j RETURN
-A other2wan -j logdrop

adm@RT-AC86U-BE10:/jffs/scripts# iptables -t raw -S
-P PREROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i br+ -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j LOG --log-prefix "[BLOCKED - OUTBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A PREROUTING -i br+ -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j DROP
-A PREROUTING -i eth0 -m set ! --match-set Skynet-Whitelist src -m set --match-set Skynet-Master src -j LOG --log-prefix "[BLOCKED - INBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A PREROUTING -i eth0 -m set ! --match-set Skynet-Whitelist src -m set --match-set Skynet-Master src -j DROP
-A OUTPUT -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j LOG --log-prefix "[BLOCKED - OUTBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A OUTPUT -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j DROP

adm@RT-AC86U-BE10:/jffs/scripts# ip rule show
0:      from all lookup local
10010:  from 192.168.1.181 lookup main
10011:  from 192.168.1.54 lookup main
10012:  from 192.168.1.60 lookup main
10013:  from 192.168.1.134 lookup main
10014:  from 192.168.1.158 lookup main
10810:  from 192.168.1.172 lookup ovpnc4
32766:  from all lookup main
32767:  from all lookup default

adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc4
default via 10.8.0.1 dev tun14
10.8.0.0/24 dev tun14 proto kernel scope link src 10.8.0.8
68.26.139.0/24 dev eth0 proto kernel scope link src 68.26.139.133
68.26.139.1 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
185.202.220.146 via 68.26.139.1 dev eth0
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

And, output from a failed, looping connection:

Code: 
adm@RT-AC86U-BE10:/jffs/scripts# iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N ACCESS_RESTRICTION
-N DNSFILTER_DOT
-N FUPNP
-N INPUT_ICMP
-N INPUT_PING
-N NSFW
-N OVPN
-N PControls
-N PTCSRVLAN
-N PTCSRVWAN
-N SECURITY
-N default_block
-N logaccept
-N logdrop
-N other2wan
-A INPUT -i eth0 -p igmp -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j INPUT_PING
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j logdrop
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp -j INPUT_ICMP
-A INPUT -j logdrop
-A FORWARD -d 224.0.0.0/4 -i eth0 -j ACCEPT
-A FORWARD -i br0 -m time --timestart 00:00:00 --timestop 06:00:00 --kerneltz -m mac --mac-source 27:13:94:F2:42:D4 -j PControls
-A FORWARD -i br0 -m mac --mac-source 27:13:94:F2:42:D4 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD ! -i br0 -o eth0 -j other2wan
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -m state --state INVALID -j logdrop
-A FORWARD -j NSFW
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -m state --state NEW -j OVPN
-A FORWARD -j logdrop
-A FUPNP -d 192.168.1.54/32 -p udp -m udp --dport 3074 -j ACCEPT
-A FUPNP -d 192.168.1.54/32 -p udp -m udp --dport 2003 -j ACCEPT
-A INPUT_ICMP -p icmp -m icmp --icmp-type 8 -j RETURN
-A INPUT_ICMP -p icmp -m icmp --icmp-type 13 -j RETURN
-A INPUT_ICMP -p icmp -j ACCEPT
-A INPUT_PING -i eth0 -p icmp -j logdrop
-A OVPN -i tun11 -j DROP
-A PControls -i br0 -o br0 -j logdrop
-A PControls -m state --state INVALID -j logdrop
-A PControls -j NSFW
-A PControls -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j logdrop
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j logdrop
-A SECURITY -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -j DROP
-A other2wan -i tun+ -j RETURN
-A other2wan -j logdrop

adm@RT-AC86U-BE10:/jffs/scripts# iptables -t raw -S
-P PREROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i br+ -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j LOG --log-prefix "[BLOCKED - OUTBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A PREROUTING -i br+ -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j DROP
-A PREROUTING -i eth0 -m set ! --match-set Skynet-Whitelist src -m set --match-set Skynet-Master src -j LOG --log-prefix "[BLOCKED - INBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A PREROUTING -i eth0 -m set ! --match-set Skynet-Whitelist src -m set --match-set Skynet-Master src -j DROP
-A OUTPUT -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j LOG --log-prefix "[BLOCKED - OUTBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A OUTPUT -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j DROP

adm@RT-AC86U-BE10:/jffs/scripts# ip rule show
0:      from all lookup local
10010:  from 192.168.1.181 lookup main
10011:  from 192.168.1.54 lookup main
10012:  from 192.168.1.60 lookup main
10013:  from 192.168.1.134 lookup main
10014:  from 192.168.1.158 lookup main
32766:  from all lookup main
32767:  from all lookup default

adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc1
adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc2
adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc3
adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc4
adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc5
adm@RT-AC86U-BE10:/jffs/scripts# ip route show
default via 63.12.119.1 dev eth0
63.12.119.0/24 dev eth0 proto kernel scope link src 63.12.119.134
63.12.119.1 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
 
Viktor Jaep said:
Thanks Jack... I split this up between the output of when I am experiencing a good connection to NordVPN, and when it's failing during a looping event... the only real difference (I could find) was that none of the ovpnc connections had any routing tables because they weren't connected yet... you see anything?

Logs from a healthy connection to NordVPN:
Code: 
adm@RT-AC86U-BE10:/jffs/scripts# iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N ACCESS_RESTRICTION
-N DNSFILTER_DOT
-N FUPNP
-N INPUT_ICMP
-N INPUT_PING
-N NSFW
-N OVPN
-N PControls
-N PTCSRVLAN
-N PTCSRVWAN
-N SECURITY
-N default_block
-N logaccept
-N logdrop
-N other2wan
-A INPUT -i eth0 -p igmp -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j INPUT_PING
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j logdrop
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp -j INPUT_ICMP
-A INPUT -j logdrop
-A FORWARD -d 224.0.0.0/4 -i eth0 -j ACCEPT
-A FORWARD -i br0 -m time --timestart 00:00:00 --timestop 06:00:00 --kerneltz -m mac --mac-source 31:32:13:B5:39:34 -j PControls
-A FORWARD -i br0 -m mac --mac-source 31:32:13:B5:39:34 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD ! -i br0 -o eth0 -j other2wan
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -m state --state INVALID -j logdrop
-A FORWARD -j NSFW
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -m state --state NEW -j OVPN
-A FORWARD -j logdrop
-A FUPNP -d 192.168.1.54/32 -p udp -m udp --dport 3074 -j ACCEPT
-A FUPNP -d 192.168.1.54/32 -p udp -m udp --dport 2003 -j ACCEPT
-A INPUT_ICMP -p icmp -m icmp --icmp-type 8 -j RETURN
-A INPUT_ICMP -p icmp -m icmp --icmp-type 13 -j RETURN
-A INPUT_ICMP -p icmp -j ACCEPT
-A INPUT_PING -i eth0 -p icmp -j logdrop
-A OVPN -i tun14 -j DROP
-A PControls -i br0 -o br0 -j logdrop
-A PControls -m state --state INVALID -j logdrop
-A PControls -j NSFW
-A PControls -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j logdrop
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j logdrop
-A SECURITY -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -j DROP
-A other2wan -i tun+ -j RETURN
-A other2wan -j logdrop

adm@RT-AC86U-BE10:/jffs/scripts# iptables -t raw -S
-P PREROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i br+ -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j LOG --log-prefix "[BLOCKED - OUTBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A PREROUTING -i br+ -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j DROP
-A PREROUTING -i eth0 -m set ! --match-set Skynet-Whitelist src -m set --match-set Skynet-Master src -j LOG --log-prefix "[BLOCKED - INBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A PREROUTING -i eth0 -m set ! --match-set Skynet-Whitelist src -m set --match-set Skynet-Master src -j DROP
-A OUTPUT -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j LOG --log-prefix "[BLOCKED - OUTBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A OUTPUT -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j DROP

adm@RT-AC86U-BE10:/jffs/scripts# ip rule show
0:      from all lookup local
10010:  from 192.168.1.181 lookup main
10011:  from 192.168.1.54 lookup main
10012:  from 192.168.1.60 lookup main
10013:  from 192.168.1.134 lookup main
10014:  from 192.168.1.158 lookup main
10810:  from 192.168.1.172 lookup ovpnc4
32766:  from all lookup main
32767:  from all lookup default

adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc4
default via 10.8.0.1 dev tun14
10.8.0.0/24 dev tun14 proto kernel scope link src 10.8.0.8
68.26.139.0/24 dev eth0 proto kernel scope link src 68.26.139.133
68.26.139.1 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
185.202.220.146 via 68.26.139.1 dev eth0
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

And, logs from a failed, looping connection:

Code: 
adm@RT-AC86U-BE10:/jffs/scripts# iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N ACCESS_RESTRICTION
-N DNSFILTER_DOT
-N FUPNP
-N INPUT_ICMP
-N INPUT_PING
-N NSFW
-N OVPN
-N PControls
-N PTCSRVLAN
-N PTCSRVWAN
-N SECURITY
-N default_block
-N logaccept
-N logdrop
-N other2wan
-A INPUT -i eth0 -p igmp -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j INPUT_PING
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j logdrop
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp -j INPUT_ICMP
-A INPUT -j logdrop
-A FORWARD -d 224.0.0.0/4 -i eth0 -j ACCEPT
-A FORWARD -i br0 -m time --timestart 00:00:00 --timestop 06:00:00 --kerneltz -m mac --mac-source 27:13:94:F2:42:D4 -j PControls
-A FORWARD -i br0 -m mac --mac-source 27:13:94:F2:42:D4 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD ! -i br0 -o eth0 -j other2wan
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -m state --state INVALID -j logdrop
-A FORWARD -j NSFW
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -m state --state NEW -j OVPN
-A FORWARD -j logdrop
-A FUPNP -d 192.168.1.54/32 -p udp -m udp --dport 3074 -j ACCEPT
-A FUPNP -d 192.168.1.54/32 -p udp -m udp --dport 2003 -j ACCEPT
-A INPUT_ICMP -p icmp -m icmp --icmp-type 8 -j RETURN
-A INPUT_ICMP -p icmp -m icmp --icmp-type 13 -j RETURN
-A INPUT_ICMP -p icmp -j ACCEPT
-A INPUT_PING -i eth0 -p icmp -j logdrop
-A OVPN -i tun11 -j DROP
-A PControls -i br0 -o br0 -j logdrop
-A PControls -m state --state INVALID -j logdrop
-A PControls -j NSFW
-A PControls -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j logdrop
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j logdrop
-A SECURITY -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -j DROP
-A other2wan -i tun+ -j RETURN
-A other2wan -j logdrop

adm@RT-AC86U-BE10:/jffs/scripts# iptables -t raw -S
-P PREROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i br+ -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j LOG --log-prefix "[BLOCKED - OUTBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A PREROUTING -i br+ -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j DROP
-A PREROUTING -i eth0 -m set ! --match-set Skynet-Whitelist src -m set --match-set Skynet-Master src -j LOG --log-prefix "[BLOCKED - INBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A PREROUTING -i eth0 -m set ! --match-set Skynet-Whitelist src -m set --match-set Skynet-Master src -j DROP
-A OUTPUT -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j LOG --log-prefix "[BLOCKED - OUTBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A OUTPUT -m set ! --match-set Skynet-Whitelist dst -m set --match-set Skynet-Master dst -j DROP

adm@RT-AC86U-BE10:/jffs/scripts# ip rule show
0:      from all lookup local
10010:  from 192.168.1.181 lookup main
10011:  from 192.168.1.54 lookup main
10012:  from 192.168.1.60 lookup main
10013:  from 192.168.1.134 lookup main
10014:  from 192.168.1.158 lookup main
32766:  from all lookup main
32767:  from all lookup default

adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc1
adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc2
adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc3
adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc4
adm@RT-AC86U-BE10:/jffs/scripts# ip route show table ovpnc5
adm@RT-AC86U-BE10:/jffs/scripts# ip route show
default via 63.12.119.1 dev eth0
63.12.119.0/24 dev eth0 proto kernel scope link src 63.12.119.134
63.12.119.1 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
Click to expand...
nothing obvious, but, do you see any outbound blocks in your log from Skynet?
 
Jack Yaz said:
nothing obvious, but, do you see any outbound blocks in your log from Skynet?
Click to expand...
Nothing being blocked outbound by Skynet when this is happening... however, I have found some other anomalies that might be of interest.

Vpnmgr configured my VPN Client #1 to use "NordVPN US9183"... which in the VPN client Config is listed as 83.136.182.100. You can see in the VPN Status screen, it was trying to connect to that:
Screenshot 2021-12-30 09.04.55.png


However, when you dive into the logs, it seems it attempted to use this address, but bombed out on an X509 Name Error resolution? After which, you will notice that it starts using other IP addresses, referring to them as "TCP/UDP: Preserving recently used remote address:", and trying to connect to those. Like, 45.85.89.113, 172.98.33.82, 154.6.16.191, all referring to VPN Client 1... in the interim, nothing has changed. It still shows US9183 and the VPN IP specified in the client config remains 83.136.182.100:1194. Is that normal?? Also, weirdly... when it starts retrying/looping, they seem to be using port 1195, instead of 1194 as specified in the VPN 1 config. Weird.

** just noticed this. The VPN 1 client is configured to use US9183... however, when it did that VERIFY X509 cert, it came back it being US9187? -- "VERIFY X509NAME ERROR: CN=us9187.nordvpn.com, must be Server". Hum. ;)

Code: 
Dec 30 07:45:23 ovpn-client1[29500]: Server poll timeout, restarting
Dec 30 07:45:23 ovpn-client1[29500]: SIGUSR1[soft,server_poll] received, process restarting
Dec 30 07:45:23 ovpn-client1[29500]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 30 07:45:23 ovpn-client1[29500]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 30 07:45:23 ovpn-client1[29500]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:45:23 ovpn-client1[29500]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:45:23 ovpn-client1[29500]: TCP/UDP: Preserving recently used remote address: [AF_INET]83.136.182.108:1194
Dec 30 07:45:23 ovpn-client1[29500]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 30 07:45:23 ovpn-client1[29500]: UDP link local: (not bound)
Dec 30 07:45:23 ovpn-client1[29500]: UDP link remote: [AF_INET]83.136.182.108:1194
Dec 30 07:45:23 ovpn-client1[29500]: TLS: Initial packet from [AF_INET]83.136.182.108:1194, sid=77eaa006 9ddf5c46
Dec 30 07:45:23 ovpn-client1[29500]: VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
Dec 30 07:45:23 ovpn-client1[29500]: VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA6
Dec 30 07:45:23 ovpn-client1[29500]: VERIFY KU OK
Dec 30 07:45:23 ovpn-client1[29500]: Validating certificate extended key usage
Dec 30 07:45:23 ovpn-client1[29500]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Dec 30 07:45:23 ovpn-client1[29500]: VERIFY EKU OK
Dec 30 07:45:23 ovpn-client1[29500]: VERIFY X509NAME ERROR: CN=us9187.nordvpn.com, must be Server
Dec 30 07:45:23 ovpn-client1[29500]: OpenSSL: error:1416F086:lib(20):func(367):reason(134)
Dec 30 07:45:23 ovpn-client1[29500]: TLS_ERROR: BIO read tls_read_plaintext error
Dec 30 07:45:23 ovpn-client1[29500]: TLS Error: TLS object -> incoming plaintext read error
Dec 30 07:45:23 ovpn-client1[29500]: TLS Error: TLS handshake failed
Dec 30 07:45:23 ovpn-client1[29500]: SIGUSR1[soft,tls-error] received, process restarting
Dec 30 07:45:23 ovpn-client1[29500]: Restart pause, 300 second(s)
Dec 30 07:50:23 ovpn-client1[29500]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 30 07:50:23 ovpn-client1[29500]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 30 07:50:23 ovpn-client1[29500]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:50:23 ovpn-client1[29500]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:50:23 ovpn-client1[29500]: TCP/UDP: Preserving recently used remote address: [AF_INET]45.85.89.113:1195
Dec 30 07:50:23 ovpn-client1[29500]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 30 07:50:23 ovpn-client1[29500]: UDP link local: (not bound)
Dec 30 07:50:23 ovpn-client1[29500]: UDP link remote: [AF_INET]45.85.89.113:1195
Dec 30 07:50:33 ovpn-client1[29500]: Server poll timeout, restarting
Dec 30 07:50:33 ovpn-client1[29500]: SIGUSR1[soft,server_poll] received, process restarting
Dec 30 07:50:33 ovpn-client1[29500]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 30 07:50:33 ovpn-client1[29500]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 30 07:50:33 ovpn-client1[29500]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:50:33 ovpn-client1[29500]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:50:33 ovpn-client1[29500]: TCP/UDP: Preserving recently used remote address: [AF_INET]45.84.215.238:1195
Dec 30 07:50:33 ovpn-client1[29500]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 30 07:50:33 ovpn-client1[29500]: UDP link local: (not bound)
Dec 30 07:50:33 ovpn-client1[29500]: UDP link remote: [AF_INET]45.84.215.238:1195

...

Dec 30 07:51:24 ovpn-client1[29500]: Server poll timeout, restarting
Dec 30 07:51:24 ovpn-client1[29500]: SIGUSR1[soft,server_poll] received, process restarting
Dec 30 07:51:24 ovpn-client1[29500]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 30 07:51:24 ovpn-client1[29500]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 30 07:51:24 ovpn-client1[29500]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:51:24 ovpn-client1[29500]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:51:24 ovpn-client1[29500]: TCP/UDP: Preserving recently used remote address: [AF_INET]172.98.33.82:1195
Dec 30 07:51:24 ovpn-client1[29500]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 30 07:51:24 ovpn-client1[29500]: UDP link local: (not bound)
Dec 30 07:51:24 ovpn-client1[29500]: UDP link remote: [AF_INET]172.98.33.82:1195
Dec 30 07:51:34 ovpn-client1[29500]: Server poll timeout, restarting
Dec 30 07:51:34 ovpn-client1[29500]: SIGUSR1[soft,server_poll] received, process restarting
Dec 30 07:51:34 ovpn-client1[29500]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 30 07:51:34 ovpn-client1[29500]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 30 07:51:34 ovpn-client1[29500]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:51:34 ovpn-client1[29500]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:51:34 ovpn-client1[29500]: TCP/UDP: Preserving recently used remote address: [AF_INET]172.98.33.231:1195
Dec 30 07:51:34 ovpn-client1[29500]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 30 07:51:34 ovpn-client1[29500]: UDP link local: (not bound)
Dec 30 07:51:34 ovpn-client1[29500]: UDP link remote: [AF_INET]172.98.33.231:1195

...

Dec 30 07:51:54 ovpn-client1[29500]: Server poll timeout, restarting
Dec 30 07:51:54 ovpn-client1[29500]: SIGUSR1[soft,server_poll] received, process restarting
Dec 30 07:51:54 ovpn-client1[29500]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 30 07:51:54 ovpn-client1[29500]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 30 07:51:54 ovpn-client1[29500]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:51:54 ovpn-client1[29500]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:51:54 ovpn-client1[29500]: TCP/UDP: Preserving recently used remote address: [AF_INET]154.6.16.191:1195
Dec 30 07:51:54 ovpn-client1[29500]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 30 07:51:54 ovpn-client1[29500]: UDP link local: (not bound)
Dec 30 07:51:54 ovpn-client1[29500]: UDP link remote: [AF_INET]154.6.16.191:1195
Dec 30 07:52:04 ovpn-client1[29500]: Server poll timeout, restarting
Dec 30 07:52:04 ovpn-client1[29500]: SIGUSR1[soft,server_poll] received, process restarting
Dec 30 07:52:04 ovpn-client1[29500]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Dec 30 07:52:04 ovpn-client1[29500]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 30 07:52:04 ovpn-client1[29500]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:52:04 ovpn-client1[29500]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Dec 30 07:52:04 ovpn-client1[29500]: TCP/UDP: Preserving recently used remote address: [AF_INET]173.239.207.223:1195
Dec 30 07:52:04 ovpn-client1[29500]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Dec 30 07:52:04 ovpn-client1[29500]: UDP link local: (not bound)
Dec 30 07:52:04 ovpn-client1[29500]: UDP link remote: [AF_INET]173.239.207.223:1195
 
Last edited:
Just hit the 10K char limit. To make matters even more confusing, doing an nslookup on us9183.nordvpn.com = 83.136.182.100... while us9187.nordvpn.com = 83.136.182.108. So I'm not sure how the VPN 1 config showed US9183 with an 83.136.182.108 IP?
 
very weird. do you have any clients that connect on port 1195 and there's some sort of config mangling?

have you tried the latest develop updates by the way? it now includes a 10s ping test and 3 client restarts to check if the client is actually up or not. for now, if its still not up it will exit with a message
 
Jack Yaz said:
very weird. do you have any clients that connect on port 1195 and there's some sort of config mangling?

have you tried the latest develop updates by the way? it now includes a 10s ping test and 3 client restarts to check if the client is actually up or not. for now, if its still not up it will exit with a message
Click to expand...
OMG... I think I may have found why. I still had an old openvpnclient1.postconf file sitting out in my scripts folder. It was referencing lots of remote random expressvpn hosts on port 1195... I'm guessing this postconf was interfering in a way, possibly when vpn client 1 gets activated. I've renamed it, and hopefully removed it from the equation. I've also updated to the latest vpnmgr, going to do a fresh reboot, and will get some testing done! :)
 
Thank you, @Jack Yaz! I restarted the connection at least 10x, and connected flawlessly each time now. No more indications of it wanting to connect to other IPs on 1195. I had one issue where skynet blocked an outgoing connection to a NordVPN server, and added that range to the whitelist. Shortly after, it connected on its own without issue. Nothing I can really to do to prevent that other than taking care of them as they come up I guess. I'll keep my eye on this over the next week or so, and will report if I see any other anomalies! Thanks again for your help! :)
 
You must log in or register to reply here.

Similar threads

T
[Help] Problems setting up OpenVPN
Replies
7
Views
264
Thookie
T
P
RT-AX88U - 388.2_2 - Previously Working VPN Client (NordVPN) no longer functions - Suggestions for NordVPN Working Settings July 2023
Replies
2
Views
2K
PC Pilot
P
Viktor Jaep
vpnmgr Randomizer Script for Nordvpn
Replies
8
Views
2K
Viktor Jaep
Viktor Jaep
G
TLS error with OpenVPN client
Replies
4
Views
3K
eibgrad
eibgrad
A
Devices connect to my openvpn server correctly but no traffic from server to client
Replies
6
Views
1K
ragtap
R
Similar threads
Thread starter Title Forum Replies Date
jrmathis BACKUPMON BackupMon Failing Asuswrt-Merlin AddOns 41
R Diversion Diversion and Ubisoft Connect - how to find out what is the problematic block? Asuswrt-Merlin AddOns 5
8 ASUS RT-AX58U (F/W Ver.:V3.0.0.4.384.8601) with Asuswrt-Merlin 3004.388.5 - Transmission: "Could not connect to the server. You may need to reload" Asuswrt-Merlin AddOns 2

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!

Members online

Total: 707 (members: 17, guests: 690)
Top