VPN not working after upgrading to Mavericks

Given that the error indicates that some memory buffer is unavailable and one of the big "features" of Mavericks is the new memory management and memory compression mechanism, I'm guessing that those of us who are having this problem have something in our environment that is using up whatever buffer the VPN needs. There is probably a bug in Mavericks related to releasing the memory and other people aren't hitting it because they have less in the buffers.

The problem is that I haven't a clue what buffer would be full nor how to tweak anything in Mavericks memory management even if I did know what buffer needs to be bigger.

There's probably something we can uninstall that would make it better.

re: my earlier post on PPTP/VPN

Tracked the error down to a D-Link base station incompatibility. Switched to an Apple Time Capsule base station and VPN now works on my 10.9 MacBook.

Other Macs and iOS devices running non-Mavericks systems (10.6, 10.8, iOS 6 and 7) do VPN fine through the D-Link box; Mavericks crashes it. Tried vanilla settings, non-802.11N- modes, running outside the "DMZ" etc. options on the D-Link, no success.

And I'm having a slightly different problem with PPTP/VPN (of course it was working prior to the upgrade). I see the following in the log:

Fri Oct 25 12:44:03 2013 : PPTP connecting to server 'austin.tunnel.hp.net' (15.219.217.251)...

Fri Oct 25 12:44:03 2013 : PPTP connection established.

Fri Oct 25 12:44:03 2013 : PPTP set port-mapping for en0, interface: 4, protocol: 0, privatePort: 0

Fri Oct 25 12:44:03 2013 : Using interface ppp0

Fri Oct 25 12:44:03 2013 : Connect: ppp0 <--> socket[34:17]

Fri Oct 25 12:44:03 2013 : PPTP port-mapping for en0, interfaceIndex: 0, Protocol: None, Private Port: 0, Public Address: 4b47578e, Public Port: 0, TTL: 0.

Fri Oct 25 12:44:03 2013 : PPTP port-mapping for en0 inconsistent. is Connected: 1, Previous interface: 4, Current interface 0

Fri Oct 25 12:44:03 2013 : PPTP port-mapping for en0 initialized. is Connected: 1, Previous publicAddress: (0), Current publicAddress 4b47578e

Fri Oct 25 12:44:03 2013 : PPTP port-mapping for en0 fully initialized. Flagging up

Fri Oct 25 12:44:06 2013 : PPTP failed to set port-mapping for en0, errorCode: -65564

Fri Oct 25 12:44:06 2013 : PPTP port-mapping for en0 became invalid. is Connected: 1, Protocol: None, Private Port: 0, Previous publicAddress: (4b47578e), Previous publicPort: (0)

Fri Oct 25 12:44:06 2013 : PPTP public port-mapping for en0 changed... starting faster probe.

Fri Oct 25 12:44:33 2013 : LCP: timeout sending Config-Requests

Fri Oct 25 12:44:33 2013 : Connection terminated.

Fri Oct 25 12:44:33 2013 : PPTP disconnecting...

Fri Oct 25 12:44:33 2013 : PPTP clearing port-mapping for en0

Fri Oct 25 12:44:33 2013 : PPTP disconnected

Any thoughts?

I'm having the same issue after moving to Maverick. I'm unable to connect to my VPN server using L2TP. I had to enable PPTP connections as a short term work around.

continuing to poke around....

I found the source code that generates the

create_tun_interface: connect failed on kernel control socket (errno = 55)

message at https://www.opensource.apple.com/source/ppp/ppp-596.14/Controller/scnc_utils.c?t xt

if (connect(tunsock, (struct sockaddr *)&kernctl_addr, sizeof(kernctl_addr))) {

SCLog(TRUE, LOG_ERR, CFSTR("create_tun_interface: connect failed on kernel control socket (errno = %d)"), errno);

goto fail;

}

so it's coming from a call to "connect".

The man page for connect(2) is at https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/ man2/connect.2.html

and without adding much more clarity tells us that ENOBUFS (error 55) indicates:

[ENOBUFS] The system call was unable to allocate a needed memory buffer.

which still sounds to me like a bug in the new memory management stuff.

I'm not an apple developer, so apparently I can't file a bug with them :-(

Trying to watch memory allocation while this happens hasn't told me anything useful yet, but that's probably because i don't know what I'm doing.

Hope this sends someone else the right direction.

I am having the same problem. After the update to Mac OS 10.9, on a Mac Book Pro 17" (last model Apple did), all my VPN's are dead

Both L2TP and PPTP. Re-creating them is also not fixing at all..

Quite bad this...

Thanks and hope someone find a solution soon!

Leonardo

I think my version of VPN trouble is close to yours: L2TP and Cisco (which is a L2TP variant) connections were failing with a errno=55 message.

No buffers.... hmmm...

I watched a verbose boot closely and found an oddity. Over the years I've accumulated various tuning tweaks in /etc/sysctl.conf, most of which exist to raise various i/o and memory management limits that historically have impaired MacOS X server performance. But today I saw that the kern.ipc.maxsockbuf value was being reduced by an order of magnitude by my tweak.

I removed the setting of kern.ipc.maxsockbuf from /etc/sysctl.conf, rebooted, and VPN connections work again. I'm not sure if changing it on a live system works and don't know what the modern ideal for it is, but I can state with certainty that on a 8GB Mac, 512000 is too small. If you've got /etc/sysctl.conf, you probably should review and re-justify everything in it on Mavericks because the memory management has changed substantially.

Yep - that fixed it for me as well. I have no idea why or when I set that value in sysctl.conf

At first I couldn't see why either, since that value makes no sense on the machine I had it on. So I did a bit of research.

I'm convinced that in my case it was inherited across 2 hardware migrations, 5 major OS upgrades, and about 8 years, having originally been set on a Cube running Tiger using Apple's Broadband Tuner tool. That's the last PPC machine in this machine's ancestry, and that tool is/was PPC-only. I suspect it because the oddly decimal value of 512000 (512 * 1000, rather than 512*1024) is a widely-reported result of that tool, along with the asymmetric values I had for net.inet.tcp.sendspace and net.inet.tcp.recvspace.

Any chance those procedures highlighted above might apply to a non-Cisco issue, like the native Mac OS X 10.9 VPN client?

Thanks!

Leo

I did a clean re-install of OSX Mavericks on my mac mini. The problem is still there. I can connect to my VPN when connection through my local wifi and local ip adress of my server with my iPhone. When i try reaching the server with my external ip adress (from the outside), the problem occurs. My settings in my Airport Extreme are ok i checked it and i can see in the log that a connection is being made (see below), but ends with a timeout. My iPhone gives the error that the L2TP-VPN server is not responding. I have absolutely no idea how to solve this.

Oct 26 08:54:10 racoon[188]: Connecting.

Oct 26 08:54:10 racoon[188]: IPSec Phase 1 started (Initiated by peer).

Oct 26 08:54:10 racoon[188]: IKE Packet: receive success. (Responder, Main-Mode message 1).

Oct 26 08:54:10 racoon[188]: >>>>> phase change status = Phase 1 started by us

Oct 26 08:54:10 racoon[188]: IKE Packet: transmit success. (Responder, Main-Mode message 2).

Oct 26 08:54:12 racoon[188]: IKE Packet: receive success. (Responder, Main-Mode message 3).

Oct 26 08:54:12 racoon[188]: IKE Packet: transmit success. (Responder, Main-Mode message 4).

Oct 26 08:54:12 racoon[188]: Connecting.

Oct 26 08:54:15 racoon[188]: IKE Packet: transmit success. (Phase 1 Retransmit).

Oct 26 08:54:49 --- last message repeated 3 times ---

Oct 26 08:54:50 racoon[188]: IKE Packet: transmit success. (Phase 1 Retransmit).

Oct 26 08:55:08 racoon[188]: IKE Packet: transmit success. (Phase 1 Retransmit).

Oct 26 08:55:56 --- last message repeated 1 time ---

Oct 26 08:55:56 racoon[188]: IKE Packet: transmit success. (Phase 1 Retransmit).

Oct 26 08:56:26 racoon[188]: IKE Packet: transmit success. (Phase 1 Retransmit).

Oct 26 08:56:59 racoon[188]: IKEv1 Phase 1: maximum retransmits. (Phase 1 Maximum Retransmits).

Oct 26 08:56:59 racoon[188]: Phase 1 negotiation failed due to time up.