VPN fails when rebooted

Ron, the script worked! Thanks so much for your efforts! 🙂

This script also works fine for me. Thank you!

Do you know a possibility to check if the vpn server is running?

Ok, thank you!

I had the same issue and after reading several posts about it my intuition told me it was a timing issue with the service starting as suggested earlier in this thread.

Instead of messing with a script I just tried sending the vpn process an ALRM signal which restarted it.

(following reboot VPN not working from remote)

sh-3.2# ps -ef | grep vpn

0 293 1 0 9:27PM ?? 0:00.80 vpnd -x -i com.apple.ppp.l2tp

0 11385 11164 0 1:53AM ttys001 0:00.00 grep vpn

sh-3.2# kill -ALRM 293

(VPN now working from remote)

Suppose I could have done a "pkill -ALRM vpnd" instead, I'll try that next time I reboot. Of course you still need shell access to the server but luckily I have ssh mapped so I can get in remotely.

C'mon Apple, shouldn't have to be a sysadmin to get your stuff to work right. The startup script for the VPN service should check the lower layers and wait for them if necessary.

Hi Ron, good information in your post with regard to your supposition that racoon can't bind to these IP adddresses behind a NAT when OSx server starts up. Like many on this thread I have been experiencing this issue since OS 10.10.1. I too have not found any solution and your launchd daemon is a good work around. Thanks for that.

This VPN connection failure after a OSx restart (reboot) is quite repeatable after a reboot on this particular configuration.

However on some systems we deal with, the VPN is ready every time!

Here's some more information I'd like to contribute. This is a sequence from today's maintenance OSX 10.10.5 update restart of our main server.

Like clockwork, VPN L2TP clients fail authentication to connect to the VPN. Our procedure is to ssh in and severadmin stop/start VPN. VPN connections then succeed flawlessly from then on. Yep this always works.

Symptoms as above: logs reviewed:

We noticed that the racoon/vpnd agent is underway PRIOR to the successful establishment of the other NIC's on this particular macmini. (Ethernet [subnet 1] and THUNDERBOLT/ethernet [subnet 2] ). . The /var/log sequence for vpnd, L2TP and racoon is:

Sep 6 09:28:29 macmini-server.msf.studio vpnd[262]: Server 'com.apple.ppp.l2tp' starting...

Sep 6 09:28:29 macmini-server.msf.studio vpnd[262]: Loading plugin /System/Library/Extensions/L2TP.ppp

,.....

Sep 6 09:28:30 macmini-server kernel[0]: L2TP domain init

Sep 6 09:28:30 macmini-server kernel[0]: L2TP domain init complete

Sep 6 09:28:30 macmini-server kernel[0]: l2tp_udp_init_threads: changing # of threads from 0 to 7

Sep 6 09:28:30 macmini-server.msf.studio vpnd[262]: Listening for connections...

Sep 6 09:28:30 macmini-server.msf.studio swupd_syncd[272]: Download for "Deprecations.plist" failed (reason: The Internet connection appears to be offline.)

.....

Sep 6 09:28:31 macmini-server.msf.studio racoon[371]: accepted connection on vpn control socket.

Sep 6 09:28:32 macmini-server kernel[0]: Ethernet [AppleBCM5701Ethernet]: Link up on en4, 1-Gigabit, Full-duplex, Symmetric flow-control, EEE enabled, Debug [796d,0301,0de1,0300,c5e1,3800]

Sep 6 09:28:32 macmini-server.msf.studio servermgr-notify[338]: up and running

Sep 6 09:28:32 macmini-server.msf.studio ServerEventsDaemon[264]: Connected to the Notify Service

Sep 6 09:28:32 macmini-server kernel[0]: Ethernet [AppleBCM5701Ethernet]: Link up on en0, 1-Gigabit, Full-duplex, Symmetric flow-control, Debug [796d,2301,0de1,0300,cde1,3800]

....

This is curious only because of our attention to your post , we noted the following behaviour:

1. and also that we could not see this same sequence on our test OSX 10.9.5 system. This may just be coincidence.
2. 09:28:32 Of note above is that the Thunderbolt/Ethernet EN4 interface becomes initialised/active PRIOR to the EN0 (on board ethernet). The EN4 NIC subnet is NIC service order is 2 ... strange that it is enabled before the EN) which is service order 1 (the Bluetooth service order 0) is disabled on these servers) . The EN0 NIC accesses a Lan port DHCP on an Apple Airport Extreme 802.11AC 2013 model. The server's IP address is DHCP reserved.
3. at these log event point, there's no indication that the VPN racoon service recognises the upstream PUBLIC/WAN gateway address(WAN).
4. 09:28:30 earlier, obviously from the last system.log entry at this point in the system initialisation / startup/"boot" above, that the system has no access to the WAN yet the VPN is started and ready for connections.

macmini-server:~ warwick$ networksetup -listnetworkserviceorder

(1) Bluetooth DUN

(Hardware Port: Bluetooth DUN, Device: Bluetooth-Modem)

(2) Ethernet

(Hardware Port: Ethernet, Device: en0)

(3) Thunderbolt Ethernet

(Hardware Port: Thunderbolt Ethernet, Device: en4)

(4) Wi-Fi

(Hardware Port: Wi-Fi, Device: en1)

(5) Thunderbolt Bridge

(Hardware Port: Thunderbolt Bridge, Device: bridge0)

The vpnd initialisation/start sequence continues three seconds later ....

Sep 6 09:31:09 macmini-server com.apple.xpc.launchd[1] (com.apple.ppp.l2tp): This service is defined to be constantly running and is inherently inefficient.

Sep 6 09:31:09 macmini-server.msf.studio vpnd[835]: Server 'com.apple.ppp.l2tp' starting...

Sep 6 09:31:09 macmini-server.msf.studio vpnd[835]: Loading plugin /System/Library/Extensions/L2TP.ppp

Sep 6 09:31:09 macmini-server.msf.studio vpnd[835]: Listening for connections...

The initialisation subjectively appears event seems to out or order such that the VPND agent is ready but theres no LAN interface enabled. The state information in use is then used to service any incoming connections that are in turn failed.

Also we confirm the usual "racoon[nnn]: failed to bind to address ..... because interface address is/was not ready (flags 2)." messages early in this sequence ...

Sep 6 09:28:50 macmini-server.msf.studio msf[371]: failed to bind to address fdf3:7e55:2f5b:59b6:a1b2:bab8:8b4c:5fae[500] (Can't assign requested address).

Sep 6 09:28:50 macmini-server.msf.studio msf[371]: failed to bind to address fdf3:7e55:2f5b:59b6:a1b2:bab8:8b4c:5fae[500]: because interface address is/was not ready (flags 2).

Possible Causes and Further places to look:

1. Initiation LAG? between the 2013 apple airport extreme router LAN port, and 24 port GBE unmanaged switch and the ethernet ports on the macmini
2. the above (1.) is slow
3. will look into replacing apple 2013 AC router with commercial grade router for test to determine if the Apple router 2013 is the issue. Sadly we cannot get any logs for this appliance fro Network Util nor snmp. any clues are helpful.

I will post any further developments here.

Please post any results for others to see.

Warwick

Hong Kong

Hello all.

I just found this thread while searching for an answer as to why I have been "losing" my VPN.

I have been having this problem since at least Mavericks (when I started using Server).

I'd reboot, turn VPN server off then on, test a connection from my iPhone and then leave home for multi-day work trips. Whenever I'd try to reconnect to the VPN while traveling, It would not work!

I have the computer set to reboot every morning and I guess I was causing this problem.

My fix was to create a script to turn off the VPN, wait a minute and then turn it back on.

I set the script to be run by Hazel any time a text file with a specially crafted name showed up in a specific folder on Dropbox. Then, when I was out and realized I had no VPN, I'd create a blank file with the special file name in a text editing app on my iPhone. Save the file to the Dropbox folder and wait a couple minutes.

Hazel would restart the VPN, then erase the file and viola, I had VPN.

After reading the advice on this thread, I now plan to create an AppleScript that I can run after startup to turn the VPN off and back on again. Shouldn't be too difficult as I have a few other scripts that run after re-start already (unmounting and such).

Thanks for all the research into this issue. It is a shame such a simple issue has survived at least three Operating System updates.

I have tried to implement this fix because I have the same issue. Although I feel very tech savvy, but have yet to successfully make these scripts work. Can anyone write a little more detail on the process of the working fix?

Thanks!

Can this be made to run every 24 hours as well? I got it to work but still seem to have issues if the computer is running for a while and it usually is ok after a vpn restart. If it just automatically does it, it would help a lot.

Thanks