Lion Server VPN

Having the exact same problem since the upgrade. Can't seem to remember what the next step would be after L2TP sent SCCRP. Still looking for a solution.

Yeah, welcome to the pain. Not yet found a solution to this, and do have a bugreporter ticket/case on it. Sent in some verbose logging data, but so far no fix has come forward.

Have you been able to get PPTP working? For me neither work. I get the following errors for PPTP on the server:

Sun Sep 4 10:24:43 2011 : DSAuth plugin: Could not authenticate key agent for encryption key retrieval.

Sun Sep 4 10:24:43 2011 : sent [CHAP Success id=0xa9 "S=55299EAA89204494CACFF6D5BC5EFD1123090965 M=Access granted"]

Sun Sep 4 10:24:43 2011 : CHAP peer authentication succeeded for edljedi

Sun Sep 4 10:24:43 2011 : DSAccessControl plugin: User 'edljedi' authorized for access

Sun Sep 4 10:24:43 2011 : MPPE required, but keys are not available. Possible plugin problem?

Sun Sep 4 10:24:43 2011 : sent [LCP TermReq id=0x2 "MPPE required but not available"]

Sun Sep 4 10:24:43 2011 : Connection terminated.

and the following errors on the laptop:

9/4/11 8:24:39.055 AM pppd: pppd 2.4.2 (Apple version 560.13) started by edljedi, uid 502

9/4/11 8:24:39.452 AM pppd: PPTP connecting to server 'delariviere.net' (68.15.133.50)...

9/4/11 8:24:39.992 AM pppd: PPTP connection established.

9/4/11 8:24:40.278 AM pppd: Connect: ppp0 <--> socket[34:17]

9/4/11 8:24:40.000 AM kernel: PPTP domain init

9/4/11 8:24:43.345 AM pppd: PPTP error when reading socket : EOF

9/4/11 8:24:43.345 AM pppd: PPTP error when reading header : read -1, expected 12 bytes

9/4/11 8:24:43.350 AM pppd: Connection terminated.

9/4/11 8:24:43.384 AM pppd: PPTP disconnecting...

9/4/11 8:24:43.388 AM pppd: PPTP disconnected

I have tried all the various solutions for this one to no avail. I would much prefer to get L2TP working but at this point I would settle for at least one.

I'm pretty sure it's a server problem since I have tried to connect with a Mac OS X 10.7 system, my iPhone and WinXP. All fail. I had tried simplifying my shared key on L2TP to no avail as someone else had suggested. If I could figure out what is supposed to happen after the SCCRP step (what the connecting machine is supposed to send back, maybe I can figure out why it is not).

On my server I get the same errors as you. On my laptop I get:

9/4/11 8:31:53.854 AM pppd: L2TP connecting to server 'server.net' (68.133.xx.xx)...

9/4/11 8:31:53.863 AM pppd: IPSec connection started

9/4/11 8:31:54.029 AM racoon: Connecting.

9/4/11 8:31:54.029 AM racoon: IPSec Phase1 started (Initiated by me).

9/4/11 8:31:54.030 AM racoon: IKE Packet: transmit success. (Initiator, Main-Mode message 1).

9/4/11 8:31:54.181 AM racoon: IKE Packet: receive success. (Initiator, Main-Mode message 2).

9/4/11 8:31:54.201 AM racoon: IKE Packet: transmit success. (Initiator, Main-Mode message 3).

9/4/11 8:31:54.339 AM racoon: IKE Packet: receive success. (Initiator, Main-Mode message 4).

9/4/11 8:31:54.346 AM racoon: IKE Packet: transmit success. (Initiator, Main-Mode message 5).

9/4/11 8:31:54.473 AM racoon: IKEv1 Phase1 AUTH: success. (Initiator, Main-Mode Message 6).

9/4/11 8:31:54.473 AM racoon: IKE Packet: receive success. (Initiator, Main-Mode message 6).

9/4/11 8:31:54.473 AM racoon: IKEv1 Phase1 Initiator: success. (Initiator, Main-Mode).

9/4/11 8:31:54.473 AM racoon: IPSec Phase1 established (Initiated by me).

9/4/11 8:31:55.475 AM racoon: IPSec Phase2 started (Initiated by me).

9/4/11 8:31:55.477 AM racoon: IKE Packet: transmit success. (Initiator, Quick-Mode message 1).

9/4/11 8:31:55.613 AM racoon: IKE Packet: receive success. (Initiator, Quick-Mode message 2).

9/4/11 8:31:55.614 AM racoon: IKE Packet: transmit success. (Initiator, Quick-Mode message 3).

9/4/11 8:31:55.615 AM racoon: IKEv1 Phase2 Initiator: success. (Initiator, Quick-Mode).

9/4/11 8:31:55.615 AM racoon: IPSec Phase2 established (Initiated by me).

9/4/11 8:31:55.615 AM pppd: IPSec connection established

9/4/11 8:32:15.616 AM pppd: L2TP cannot connect to the server

9/4/11 8:32:15.681 AM racoon: IKE Packet: transmit success. (Information message).

9/4/11 8:32:15.681 AM racoon: IKEv1 Information-Notice: transmit success. (Delete IPSEC-SA).

9/4/11 8:32:15.684 AM racoon: IKE Packet: transmit success. (Information message).

9/4/11 8:32:15.684 AM racoon: IKEv1 Information-Notice: transmit success. (Delete ISAKMP-SA).

Based on the timestamps, something is expected to be happening between the 31 min 55 second mark and the 32 min 15 second mark when it hangs up. The fun part is the server keeps saying "here's an IP, how bout this one, or this one":

2011-09-04 10:31:55 EDT Incoming call... Address given to client = 192.168.x.140

Sun Sep 4 10:31:55 2011 : Directory Services Authentication plugin initialized

Sun Sep 4 10:31:55 2011 : Directory Services Authorization plugin initialized

Sun Sep 4 10:31:55 2011 : L2TP incoming call in progress from '72.254.xx.xx'...

Sun Sep 4 10:31:55 2011 : L2TP received SCCRQ

Sun Sep 4 10:31:55 2011 : L2TP sent SCCRP

2011-09-04 10:31:56 EDT Incoming call... Address given to client = 192.168.x.141

Sun Sep 4 10:31:56 2011 : Directory Services Authentication plugin initialized

Sun Sep 4 10:31:56 2011 : Directory Services Authorization plugin initialized

Sun Sep 4 10:31:56 2011 : L2TP incoming call in progress from '72.254.xx.xx'...

Sun Sep 4 10:31:56 2011 : L2TP received SCCRQ

Sun Sep 4 10:31:56 2011 : L2TP sent SCCRP

2011-09-04 10:31:58 EDT Incoming call... Address given to client = 192.168.x.142

Sun Sep 4 10:31:58 2011 : Directory Services Authentication plugin initialized

Sun Sep 4 10:31:58 2011 : Directory Services Authorization plugin initialized

Sun Sep 4 10:31:58 2011 : L2TP incoming call in progress from '72.254.xx.xx'...

Sun Sep 4 10:31:58 2011 : L2TP received SCCRQ

Sun Sep 4 10:31:58 2011 : L2TP sent SCCRP

2011-09-04 10:32:06 EDT Incoming call... Address given to client = 192.168.x.128

Sun Sep 4 10:32:06 2011 : Directory Services Authentication plugin initialized

Sun Sep 4 10:32:06 2011 : Directory Services Authorization plugin initialized

Sun Sep 4 10:32:06 2011 : L2TP incoming call in progress from '72.254.xx.xx'...

Sun Sep 4 10:32:06 2011 : L2TP received SCCRQ

Sun Sep 4 10:32:06 2011 : L2TP sent SCCRP

2011-09-04 10:32:10 EDT Incoming call... Address given to client = 192.168.x.129

Sun Sep 4 10:32:10 2011 : Directory Services Authentication plugin initialized

Sun Sep 4 10:32:10 2011 : Directory Services Authorization plugin initialized

Sun Sep 4 10:32:10 2011 : L2TP incoming call in progress from '72.254.xx.xx'...

Sun Sep 4 10:32:10 2011 : L2TP received SCCRQ

Sun Sep 4 10:32:10 2011 : L2TP sent SCCRP

2011-09-04 10:32:14 EDT Incoming call... Address given to client = 192.168.x.130

Sun Sep 4 10:32:14 2011 : Directory Services Authentication plugin initialized

Sun Sep 4 10:32:14 2011 : Directory Services Authorization plugin initialized

Sun Sep 4 10:32:14 2011 : L2TP incoming call in progress from '72.254.xx.xx'...

Sun Sep 4 10:32:14 2011 : L2TP received SCCRQ

Sun Sep 4 10:32:14 2011 : L2TP sent SCCRP

2011-09-04 10:32:15 EDT --> Client with address = 192.168.x.140 has hungup

2011-09-04 10:32:16 EDT --> Client with address = 192.168.x.141 has hungup

2011-09-04 10:32:18 EDT --> Client with address = 192.168.x.142 has hungup

2011-09-04 10:32:22 EDT --> Client with address = 192.168.x.143 has hungup

2011-09-04 10:32:26 EDT --> Client with address = 192.168.x.128 has hungup

2011-09-04 10:32:30 EDT --> Client with address = 192.168.x.129 has hungup

2011-09-04 10:32:34 EDT --> Client with address = 192.168.x.130 has hungup

Well I went looking through my old logs and found the steps that are used on the server when establishing a L2TP connection.

Sat Jul 23 11:00:30 2011 : L2TP received SCCRQ

Sat Jul 23 11:00:30 2011 : L2TP sent SCCRP

Sat Jul 23 11:00:30 2011 : L2TP received SCCCN

Sat Jul 23 11:00:30 2011 : L2TP received ICRQ

Sat Jul 23 11:00:30 2011 : L2TP sent ICRP

Sat Jul 23 11:00:30 2011 : L2TP received ICCN

Sat Jul 23 11:00:30 2011 : L2TP connection established.

Sat Jul 23 11:00:30 2011 : using link 0

Sat Jul 23 11:00:30 2011 : Using interface ppp0

Sat Jul 23 11:00:30 2011 : Connect: ppp0 <--> socket[34:18]

Seems to be either the server is sending the SCCRP and the client isn't getting it or the client is getting it but it's not right and so isn't sending back the SCCCN. I have no idea what any of those terms mean. I had looked through the Guide to IPSec VPNs by the National Institute of Standards and Technology but it was a little overarching and didn't have those terms. More digging. Ugh.

Found what they mean:

1 (SCCRQ) Start-Control-Connection-Request

2 (SCCRP) Start-Control-Connection-Reply

3 (SCCCN) Start-Control-Connection-Connected

Still digging.

Good info here:

http://rfc-ref.org/RFC-TEXTS/2661/chapter5.html

Not sure if it helps yet...

Found this little bit in it:

If the expected response and response received from a peer does not match, establishment of the tunnel MUST be disallowed.

I'm wondering if that's why the tunnel isn't being established. But why?

Message was edited by: edljedi

Seeing the same issue here. My server is running as the NAT as well and the funny thing is I can connect from the internal network but not the external one. I see the repeated attempts with no percievable reply recieved as per the original post. Is anyone else on here running a similar config?

To add further mystery, I have eight user accounts on my Lion Server. Four of the accounts can connect successfully, four cannot. Doesn't matter from where and from what machine I test the accounts. Four succeed at CHAP peer authentication and the other four fail.

The one piece of feedback I got from the Apple Bugreporter process on this asked *how* I created the accounts -- so the fact that four of your eight work, Brad, indicates that they too are aware that the key to this working is somehow possibly associated with accounts themselves.

I've created accounts through both the simple Server.app as well as Server Admin utilities, neither worked for me, but, that doesn't mean that the problem can't still be there somewhere.

I'm NOT running Open Directory, which also may be a factor.

Frustrating that this still doesn't work, months in!

Well, this afternoon I deleted and recreated the four failing accounts. And now they work.

Some background: I started with local accounts. But yesterday I created an OD Master. Yesterday the new accounts didn't work. Today, after another restart and recreating the accounts -- they work.

Sorry I don't have more detail than that.

Interesting. I have my server set up as an OD Master. I have tried to authenticate the VPN with an account (the initial admin account) which is outside OD and an admin account created in OD. I might have to start creating some more accounts and see if I can connect with them.

Which method did you use to create your accounts in OD?

On a side note, I have gotten around some of the stuff I was tring to do by enabling Back To My Mac on some of the machines inside my network. Worked like a charm without having to VPN. Too bad I can't do the same with my XP machine.

I had a similar issue. I tried deleting and re-adding the user accounts and checking other suggestions in this and other VPN threads, but none resolved the problem.

It turned out I had misconfigured the DNS for the server by having a Primary Zone of servername.domain.local instead of just domain.local. I fixed that, re-added my server under the Primary Zone, checked the forwarders, restarted DNS, and users' VPN could connect again.

On my VPN server, which is also the DNS server, I have a Primary Zone setup similar to the following. My server is named "servera", a second named "serverb", and my domain is "mydomain.local":

mydomain.local

servera.mydomain.local 10.20.0.1

serverb.mydomain.local 10.20.0.2

The reverse zones are created automatically.

Under settings, I make sure I have the proper forwarders. In my case it is the DNS servers for my ISP.