Persistent Issue With VPN Server

[Jumpstarter]

I am currently running latest 384.12 on a RT-AC3100, I am running all of the scripts AMTM has to offer atm. The rest is mostly just basic setup. My question is, what would cause one vpn server to hang on reboot, it is not always the same vpn server.(not client). all i notice is that it will get stuck at initializing, what changes on the router could cause this issue? and is there a solution.

one of the two will say stopped while the other will be working.

 

[Martineau]

I am currently running latest 384.12 on a RT-AC3100, I am running all of the scripts AMTM has to offer atm. The rest is mostly just basic setup. My question is, what would cause one vpn server to hang on reboot, it is not always the same vpn server.(not client). all i notice is that it will get stuck at initializing, what changes on the router could cause this issue? and is there a solution.

View attachment 18426
one of the two will say stopped while the other will be working.

OpenVPN is pretty good at stating what is wrong in Syslog. (I don't think there is any benefit to change 'verb 3' to say 'verb 6' etc. for a more verbose startup logging)

Worst case scenario is that /jffs may have gone bad, so it may not be possible to read the OpenVPN certs etc.

 

[Jumpstarter]

OpenVPN is pretty good at stating what is wrong in Syslog. (I don't think there is any benefit to change 'verb 3' to say 'verb 6' etc. for a more verbose startup logging)

Worst case scenario is that /jffs may have gone bad, so it may not be possible to read the OpenVPN certs etc.

rc_service: httpd 425:notify_rc restart_chpass;restart_vpnserver2

Jun 27 12:14:42 RT-AC3100-1250 kernel: ADDRCONF(NETDEV_UP): tun21: link is not ready

Jun 27 12:14:42 RT-AC3100-1250 kernel: device tun21 entered promiscuous mode
Jun 27 12:14:43 RT-AC3100-1250 kernel: ADDRCONF(NETDEV_CHANGE): tun21: link becomes ready
Jun 27 12:14:47 RT-AC3100-1250 rc_service: watchdog 429:notify_rc start_dnsmasq
Jun 27 12:14:47 RT-AC3100-1250 rc_service: waitting "restart_dnsmasq" via  ...
Jun 27 12:14:51 RT-AC3100-1250 stubby[9639]: Read config from file /etc/stubby/stubby.yml
Jun 27 12:14:53 RT-AC3100-1250 rc_service: skip the event: start_vpnserver2.

this whole time the first vpn server was active.

 

[consorts]

latest 384.12 on a RT-AC3100,

off topic;

i'm using yazfi to vpn a wifi ssid, so much simpler than what you're doing, but i gotta ask since we have the same router, how's 384.12 going for you otherwise, everything else seem to be working? is the gui reporting lan/wan traffic properly?

btw, if you really do that much openvpn intestive stuff, you should upgrade to a newer 1.8ghz router cause they have far better vpn processing built into the cpu. even with encryption disabled, my vpn's thru-put is pathetic - only a third what my isp and vpn outlet is capable of.

 

[Jumpstarter]

off topic;

i'm using yazfi to vpn a wifi ssid, so much simpler than what you're doing, but i gotta ask since we have the same router, how's 384.12 going for you otherwise, everything else seem to be working? is the gui reporting lan/wan traffic properly?

btw, if you really do that much openvpn intestive stuff, you should upgrade to a newer 1.8ghz router cause they have far better vpn processing built into the cpu. even with encryption disabled, my vpn's thru-put is pathetic - only a third what my isp and vpn outlet is capable of.

384.12 is running pretty well. my Open VPN site to site server is fine for my needs. I use both servers for different needs, but speed is not a factor in my use, thank you for the suggestion though.

 

[Jumpstarter]

OpenVPN is pretty good at stating what is wrong in Syslog. (I don't think there is any benefit to change 'verb 3' to say 'verb 6' etc. for a more verbose startup logging)

Worst case scenario is that /jffs may have gone bad, so it may not be possible to read the OpenVPN certs etc.

thank you for your suggestions I maybe seemed to have fixed, further testing is needed.