PPTP VPN is broken on Yosemite

Im having similar issues just using the in built vpn connection - in my case I can connect the VPN service, but absolutely no traffic will parse the connection - can't even load a web page when connected to the vpn connection.

Im already using dhcp on connection - any suggestions ?

I'm amazed apple hasn't fixed this- like 4 weeks ago. VPN kernel client services terminate on sleep/shutdown in the new patch. Here's a workaround the takes some programming (apples job) but will fix it. But hey at least are computers are pretty...

http://roosbertl.blogspot.de/2014/10/auto-connect-osx-yosemite-ipsec-vpn-on.html

Did you manage to fix this ? I have the same issue following upgrade to Yosemite. Previously established VPN set up with Mavericks connect ok and the network pref screen for the VPN shows sent/received traffic but none of the previously mapped server drives will parse (and they can't be pinged either). I have tried all the other fixes here except installing the beta........

Hi,

Looks like it's broken again since the Security Update 2015-002.

I fixed mine by manually setting the DNS in my VPN settings to the right one (the right one for me was my router default gateway).

Go to System Preferences > Network > Choose your VPN connection.

The other thing that you can try is toggling the setting "Send all traffic over VPN connection" and see if it works. Hope this helps.

Do you mean using a static IP on the VPN server? it's not completely clear from your answer.

At the office:

• I have a server behind a router with a static IP.
• The server runs Yosemite 10.10.5 with server 5.0.4.
• I have OD set up with all users able to access VPN.
• I have a domain mapped to the WAN address of the router.
• I have checked port forwarding settings on the router, all VPN port entries have been entered correctly a year ago, and have functioned up until last week.
• Our internet connection was recently blocked by the ISP because of an open UDP 53 port. This has since been closed. Could it be they are blocking VPN traffic and other insecure services?

On Home-Office locations I have:

• Clients with dynamic DHCP IP's
• VPN is configured using a profile generated by the server
• The VPN profile is unsigned, no idea how to sign it, i checked the box at profile manager setting.
• I have tried setting the "Send all traffic" checkbox, and this did not change behaviour
• I have tried changing the wi-fi service order as suggested here: Re: PPTP VPN is broken on Yosemite
• nmap has trouble finding ports:

nmap server.com -Pn

Starting Nmap 6.47 ( http://nmap.org ) at 2015-10-13 13:41 CEST
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0

SSH connections timing out to the server

The crew recently added a new computer to the mix, I believe that has El Capitan installed. That one used to work fine up until a week ago, using the new profile, before that was installed we had renewed our certificates.

I've found the following log message repeated a few times earlier today:

server.com racoon[]: failed to bind to address fdb6:7c16:9c8f:47eb:78e0:df69:89a8:edcd[500]: because interface address is/was not ready (flags 2)

and it seems to be related to this topic as well:

VPN fails when rebooted

And this:

Re: PPTP VPN is broken on Yosemite

So my question is, is 5.0.4 the culprit, and should I file a bug report?

Or are the new certificates the problem? We downloaded the new trust profiles and reinstalled profiles after the certificate renewal, so should not be the problem imo.

Or should I contact the ISP? which of these is the likely culprit? Is it a mix of the two?

Unfortunately these solutions don't work for me, though I have similar issues! if anyone can help me out by looking at my post here: Re: PPTP VPN is broken on Yosemite

Ok so I've found my own solution.

The VPN works fine if I use the "Exposed host" feature of the modem. Of course this is completely insecure, but the regular port forwarding settings don't do jack!

Also the VPN server survives the reboot, so the startup script isn't needed 🙂 Of to bicker with the ISP!