I had the same problems and did the following for my Lion Server running on a Mac Mini Server:
- Deleted the VPN client settings on the client computer.
- Stopped the VPN server on Lion Server.
- Removed the plist file for the VPN
- Started the VPN on the server.
As it still did not work but I this time got authentication failed errors i trying using the "short name" for the login. Example: User name is Lars Adam so the short name is larsadam, removing any spaces and using only lower case.
It worked for both Mac and Windows clients.
I recently went through this same issue and found that it is very easy to mislead oneself, in part because it appears that some components in the infrastructure do throw things away after a time. Specifically, port triggers created by Back To My Mac. Routers will only keep an inbound port open for a programmed amount of time after an outbound connection triggers the opening of the inbound port.
What I discovered is that on our Comcast Business Gateway, which provides a NAT firewall, there were port triggers being created by Back to My Mac clients in the office connecting outbound. This relates to Apple's explicit statement that Lion Server VPN and Back To My Mac are mutually exclusive in the same network. Although they refer to connecting through an Airport, the same is true for any router.
(see Apple article <http://support.apple.com/kb/TS1629>)
Once I deleted the port triggers from the firewall, using the web admin interface, the VPN worked as it should. Note the conflicting ports were 500 and 4500, both used for VPN L2TP IKE key exchanges.
Of course, if you are using a different box for a NAT firewall, you will have to find where you can see and delete any port triggers that may have been created.
I am at a total loss here. I'm trying to connect to a Sonicwall NSA 240 at work from my recently upgraded Mac Book Air with no luck. I am running a D-link DIR-825 at home and I have no triggers configured on that router. VPN works correctly on my MacPro workstation running 10.6.8 and actually connects instantly. I did a lot of googling and none of the solutions work for me. One person suggests that 3DES is broken in Lion and to change the setting on the Sonicwall to AES encryption for the IKE (Phase 1) and Ipsec (Phase 2). I reconfigured the Sonicwall to use AES encryption, but that didn't work for me and of course broke VPN for the snow leopard/linux/windows clients. I set the Sonicwall back to 3DES and it of course the snow leopard/linux/windows clients where back in business, but no luck for my Lion installed MBA. I have tried everything in this thread, plus what I listed above and even tried rebooting in 32bit mode with no avail. I am incredibly frustrated. So it looks like no other computer at my work (or home) is getting Lion upgrades, since this is a real deal breaker. Anyone else using a Sonicwall at their business?
I think I can add a me too as well. My setup doesn't use any version of OS X as the VPN server, and is definitely a client issue.
I have a hardware VPN server that I know is working correctly. I normally have it setup so that all connections have to be L2TP over IPSec, but currently also have PPTP connections enabled.
At the moment I can do the following:
Connect to it from a machine running Windows 7 using all methods
Connect to it from a machine running Snow Leopard using the in built PPTP and L2TP over IPSec network configurations
Connect to it from a machine running Lion using the in built PPTP network configuration
Connect to it from a machine running Lion using Equinux's VPN Tracker 6
What I can't do is connect to it from a machine running Lion using L2TP over IPSec using the network configuration
I have tried a clean install of Lion and entering the connections. I have tried using an install of Snow Leopard that works and then upgrading it. I just cannot get it to work.
Looking at the logs on both the VPN server and my machine I can see that the IPSec connection is established but then my client says that it cannot connect to the server whilst my server is saying that CHAP login has failed.
I have been through all of the potential solutions I can find on here or the wider internet, no matter how unlikely they seem to be to my problem. I've ensured that there are no potential firewall issues. I've also tried every setting I can think of on both my client and the server. I've tried changing secrets and passwords, including reducing their length, ensuring nothing like Back to My Mac can interfere, and even starting up in 32 bit mode.
I've now exhausted my ideas. Does anybody have any ideas, a potential solution or managed to get this to work?
Your post sounds just like mine. It's pretty clear apple has broken L2TP over IPSec. Since apple doesn't read these forums, I suggest you report the bug to www.apple.com/feedback/macosx.html or if you are a developer to bugreport.apple.com.Maybe I'm being optimistic, but if enough people do it maybe they will fix it one day. I need to buy 10 macbook pros for my company, but I'm holding off until this is fixed since the new machines come pre-installed with Lion.
I realize this isn't a solution per say, but rather a means to get you where you need to go...
You mentioned you connected successfully with other computer, both Windows and Mac. On the mac machine that runs Snow Leopard, if it's always available on your network, you could rather than continue to fight this try adding a route so that any traffic destined for your VPN subnet will go through that SL box from your Lion box. I actually do a form of this on my home network with my Lion laptop, though in my case I'm routing vpn traffic to a linux server which is running openSwan, but the idea is the same.
From your broken Lion box you could try opening terminal and typing:
sudo route add 10.0.0.0/16 <ip address of SL machine>
where 10.0.0.0 is the subnet of your VPN, be it 10's or 192 etc and 16 is the subnet mask, which in the case of 16 translates to 255.255.0.0, so you'd need to adjust the command line accordingly.
Now I honestly can't remember if I had to do this next part, but since technically your VPN and your ethernet are different interfaces you might need to also perform this task one time on your SL box:
sysctl -w net.inet.ip.forwarding=1
see this link:
As a short reference to this, see the section titled NATD.
You can always turn that back off by changing that forward param back to 0...
The advantage of this is that if you have a mac running in your home 24x7 you can actually turn it into a vpn router and any computer in your network could then be on VPN at the same time. I do realize this won't help you if your a road-warrior.
Lastly, if this does fit the bill for you, you will obviously need to re-add that route each time your computer restarts, PITA that Mac doesn't allow static routes to survive a reboot, though if you can create a launchDaemon to automatically execute that command for you whenever you restart, that part I'll leave for a google search if you are so interested.
Hope this helps...
I'm not sure what exactly happened yet, but I restarted my office Netgear firewall/router and my VPN probems were fixed. A few machines on my network have Back to my Mac running, so it could be a conflict of interests as LEK2 wrote. I suspect that any port triggers (as that were created were flushed out. The frustrating issue for me was that I had VPN working one week earlier with Lion Server and then it stopped for seemingly no reason. When the problem started VPN would work on the LAN side, but not from the WAN side of the firewall.
I hope restarting the router is not the permanent solution to this issue.
Thanks very much dlangh, that's a very comprehensive response.
My only problem with a workaround though is the users I have accessing the VPN. Unfortunately, this wouldn't be a solution for all of them, but neither do I want to add the cost of VPN Tracker on to the cost of each MacBook we buy. It's leaving us at a real impasse.