Fix Cisco VPN in 10.6 Snow Leopard 10.6.2–10.6.3
The update to Snow Leopard 10.6.4 fixes the second of the two issues I observed in 10.6.0–10.6.3. Therefore, no need to change the configuration of
racoon anymore. But the fix for password storage is still necessary, i.e. you still need to add /usr/libexec/configd to the list of applications that are allowed to access your keychain XAUTH password entry.
In order to revert your configuration to the stock one, remove the last line from /etc/racoon.conf, so that the last line is again
include "/var/run/racoon/*.conf" ;
Please let me know in the comments if you still observe disconnections with 10.6.4.
Snow Leopard brought built-in support for Cisco VPN over TCP (not over UDP). However, as of 10.6.3, there are still two issues.
- The password is saved in the keychain but cannot be accessed, causing the user to be asked every time upon initiating a connection
- The connection is disconnected when the phase 1 key should be renegotiated (after 48 minutes).
The password issue can be solved by adding ”/usr/libexec/configd” to the list of applications that are allowed to access the keychain entries.
The timeout issue can be worked around by delaying the re-keying to a longer time (e.g. 1 week). Note that this may severely decrease the security of your VPN connection as attackers now have up to 1 week to attack the phase 1 key.
I have no clue where Apple stores the configuration template for racoon, but I have found the following workaround.
1. Create directory ”/etc/racoon/remote/” as root.
2. Open a VPN connection to your Cisco VPN concentrator and copy the config file from /var/run/racoon/<IP address>.conf to /etc/racoon/remote, replacing all lines
lifetime time 3600 sec;
by
lifetime time 168 hours;
This is achieved by the following sed command:
sudo sed -i.bak 's/lifetime time 3600 sec/lifetime time 168 hours/' /var/run/racoon/*.conf \ && sudo mv /var/run/racoon/*.conf /etc/racoon/remote
3. To make racoon read our converted file, insert a line
include "/etc/racoon/remote/*.conf" ;
right before the last line of /etc/racoon.conf, so that the last two lines are now
include "/etc/racoon/remote/*.conf" ; include "/var/run/racoon/*.conf" ;
This is achieved by executing the following patch command:
sudo patch /etc/racoon/racoon.conf <<EOF --- /etc/racoon.orig/racoon.conf 2009-06-23 09:09:08.000000000 +0200 +++ /etc/racoon/racoon.conf 2009-12-11 13:52:11.000000000 +0100 @@ -135,4 +135,5 @@ # by including all files matching /var/run/racoon/*.conf # This line should be added at the end of the racoon.conf file # so that settings such as timer values will be appropriately applied. +include "/etc/racoon/remote/*.conf" ; include "/var/run/racoon/*.conf" ; EOF
4. Restart racoon:
sudo launchctl stop com.apple.racoon sudo launchctl start com.apple.racoon
That's it. If this did not do the trick, try restarting your machine.
To summarize, here are all the commands to be executed:
sudo mkdir /etc/racoon/remote sudo sed -i.bak 's/lifetime time 3600 sec/lifetime time 168 hours/' /var/run/racoon/*.conf \ && sudo mv /var/run/racoon/*.conf /etc/racoon/remote sudo patch /etc/racoon/racoon.conf <<EOF --- /etc/racoon.orig/racoon.conf 2009-06-23 09:09:08.000000000 +0200 +++ /etc/racoon/racoon.conf 2009-12-11 13:52:11.000000000 +0100 @@ -135,4 +135,5 @@ # by including all files matching /var/run/racoon/*.conf # This line should be added at the end of the racoon.conf file # so that settings such as timer values will be appropriately applied. +include "/etc/racoon/remote/*.conf" ; include "/var/run/racoon/*.conf" ; EOF sudo launchctl stop com.apple.racoon sudo launchctl start com.apple.racoon
Discussion
I've searched Google up and down, and this site is the only one that makes reference to OSX's racoon. Please forgive me if I'm posting this in the wrong place..
I have Mac OS X 10.6.4 Server running L2TP IPSEC. It has a file /etc/racoon/racoon.conf. If I modify that file to any extent it usually reports the VPN is sick. If I modify the include file located at /var/run/racoon/anonymous.conf… it reports as being sick.
I'm trying to get my Avaya 5610 VOIP phone to communicate with the IPSEC network.. Unfortunately, I'm not really getting a full debug log even after changing the /etc/racoon/racoon.conf file to indicate “logs debug”.
Can anyone point me in the right direction? Apple themselves seem to not be interested as long as the IP SEC works for basic connectivity to their devices.
Thank you very kindly in advance for any help. Juda
I just found this site last night, and following the advice found here, added /usr/libexec/configd to the list of applications that can access the Cisco-VPN-over-TCP keychain entries. (I am running 10.6.4, and have not made any racoon-related changes.)
Over the course of today, I did not notice any behavioral difference in 10.6.4 compared to before; after various periods of time, the password seems to be forgotten, and I was asked for the password again. On one occasion, I was asked for the password repeatedly, having to enter it several times before it “took”.
It looks like the password request times can be found by searching for the string “IKEv1 Phase1 AUTH: success” in /var/log/system.log, which in my case would make the periods (in chronological order, generally rounded to the nearest minute): 48 minutes, 54 minutes, 2 minutes, 2 minutes, 2 minutes, 9 minutes, 54 minutes, 54 minutes, 54 minutes, 54 minutes, 54 minutes, 2 minutes, 2 minutes, 1 minute, 25 minutes, 54 minutes, 19 seconds, 1 second, 0 seconds, 11 seconds, 12 seconds, 34 minutes [when I intentionally disconnected]. Every dead peer detection request that was transmitted had a matching response received within one second, so I don’t think that this behavior is due to a DPD problem.
Comparing my log entries to those of Tom Boucher, I had no “(DPD maximum retransmits)” log entry, and only had one “(Delete IPSEC-SA)” log entry — after I’d intentionally disconnected. However, I did have many “(Delete ISAKMP-SA)” log entries, as well as two “IKEv1 XAUTH: failed. (XAUTH Status is not OK).” log entries. There were four “Disconnecting” log entries: one was after a connection negotiation of 1.5 seconds, and the other three were for periods well over 54 minutes each, so the password entries more often than not kept the current connection going.
If anyone has any ideas for extending this current 54 minute limit, I’m all eyes!
press Command-Shift-G, enter /usr/libexec
How do you add ”/usr/libexec/configd” to the Keychain?
FWIW, I was having VPN connections hang precisely at 57 minutes rather than 48 minutes (although not all the time - I'd have good days and bad days). No reprompt, it would just silently hang. I'm on 10.6.4, but the keychain fix alone did not work for me - I needed to also modify “lifetime time”.
So here's what I'm seeing in the log.
Start of Connection
7/7/10 7:10:02 PM racoon[76911] Connecting. 7/7/10 7:10:02 PM racoon[76911] IKE Packet: transmit success. (Initiator, Aggressive-Mode message 1). 7/7/10 7:10:03 PM racoon[76911] IKEv1 Phase1 AUTH: success. (Initiator, Aggressive-Mode Message 2). 7/7/10 7:10:03 PM racoon[76911] IKE Packet: receive success. (Initiator, Aggressive-Mode message 2). 7/7/10 7:10:03 PM racoon[76911] IKEv1 Phase1 Initiator: success. (Initiator, Aggressive-Mode). 7/7/10 7:10:03 PM racoon[76911] IKE Packet: transmit success. (Initiator, Aggressive-Mode message 3). 7/7/10 7:10:07 PM racoon[76911] IKE Packet: transmit success. (Mode-Config message). 7/7/10 7:10:07 PM racoon[76911] IKEv1 XAUTH: success. (XAUTH Status is OK).Then…
around the time my exchange stops working and I can no longer ping any internal resources…
7/7/10 8:09:04 PM racoon[76911] IKE Packet: receive success. (Information message). 7/7/10 8:09:24 PM racoon[76911] IKE Packet: transmit success. (Information message). 7/7/10 8:09:24 PM racoon[76911] IKEv1 Information-Notice: transmit success. (R-U-THERE?). 7/7/10 8:09:24 PM racoon[76911] IKEv1 Dead-Peer-Detection: request transmitted. (Initiator DPD Request). 7/7/10 8:09:24 PM racoon[76911] IKEv1 Dead-Peer-Detection: response received. (Initiator DPD Response). 7/7/10 8:09:24 PM racoon[76911] IKE Packet: receive success. (Information message). 7/7/10 8:09:25 PM racoon[76911] IKE Packet: transmit success. (Information message). 7/7/10 8:09:25 PM racoon[76911] IKEv1 Information-Notice: transmit success. (Delete IPSEC-SA). 7/7/10 8:09:25 PM racoon[76911] IKE Packet: transmit success. (Information message). 7/7/10 8:09:25 PM racoon[76911] IKEv1 Information-Notice: transmit success. (Delete IPSEC-SA). 7/7/10 8:09:25 PM racoon[76911] IKE Packet: transmit success. (Information message). 7/7/10 8:09:25 PM racoon[76911] IKEv1 Information-Notice: transmit success. (Delete ISAKMP-SA). 7/7/10 8:09:35 PM racoon[77894] Connecting.It appears around every time this happens I see this:
7/7/10 9:05:16 PM racoon[77894] IKE Packet: receive success. (Information message). 7/7/10 9:06:43 PM racoon[77894] IKE Packet: receive success. (Responder, Quick-Mode message 1). 7/7/10 9:06:43 PM racoon[77894] IKE Packet: transmit success. (Responder, Quick-Mode message 2). 7/7/10 9:06:44 PM racoon[77894] IKE Packet: receive success. (Responder, Quick-Mode message 3). 7/7/10 9:06:44 PM racoon[77894] IKEv1 Phase2 Responder: success. (Responder, Quick-Mode). 7/7/10 9:06:47 PM racoon[77894] IKE Packet: transmit success. (Information message). 7/7/10 9:06:47 PM racoon[77894] IKEv1 Information-Notice: transmit success. (Delete IPSEC-SA).If I'm not at the keyboard, it'll take a while, but you'll see this finally:
7/7/10 9:44:58 PM racoon[77894] IKEv1 Dead-Peer-Detection: maximum retransmits. (DPD maximum retransmits). 7/7/10 9:44:58 PM racoon[77894] IKE Packet: transmit failed. (Information message). 7/7/10 9:44:58 PM racoon[77894] IKEv1 Information-Notice: transmit failed. (Delete IPSEC-SA). 7/7/10 9:44:58 PM racoon[77894] IKE Packet: transmit failed. (Information message). 7/7/10 9:44:58 PM racoon[77894] IKEv1 Information-Notice: transmit failed. (Delete IPSEC-SA).and I never get a notification from Mac OS X about reconnection or that it finally disconnected.
Is this the Pre 10.6.4 behavior? Any other logs I can look at to figure out what might be happening?
Tom, it's not the behavior I have been seeing. But Lamont Granquist, on 2010/03/19 15:58, suggests to “try setting dpd_delay=0 in /etc/racoon/remote/<ipaddr>.conf”. However, the same effect you could probably achieve by connecting to some remote site via VPN or login via SSH and run top at the remote end. I'm not sure dead peer detection is the reason for your problem, though.
Any clue if I needed to do something special to fix 10.6.4 to work >48 m? I hadn't used the VPN client before and recently configured it and I'm experiencing the 48m timeout today. I've only used it post 10.6.4. I'm going to try the create a new location option and see if that clears it up but looking for any other suggestions before I give that a shot tonight.
Hi, Simon, I meet a problem, I has do it step by step, but when I dial the Cisco VPN, the keychain XAUTH entry is delete by itself (the entry is delete automatic), how can I do?
My OSX is 10.6.4. Thank you!
Hi 21, I'm sorry to hear this. Unfortunately I have no idea what could be going wrong. Maybe you could try to create a new “Location” in “System Preferences” → “Network” and see if this fresh start helps?
Thanks for your reply!
eh, I'm try create a new “Location”, but it also delete the entry by itself…. sigh
I am out of ideas, sorry
I'm running 10.6.4 and have always had problems with this. Since i'm the network administrator i have full access to the other side of the configuration.
Nothing i did made any difference. Then i tried your trick on this page, and now it works like a charm.
I can now see that the tunnel lifetime is 24 hours (which i think is the Cisco IOS routers default tunnel lifetime), before key change.
It feels like there is a bug in the client not automatically sending the user login and password when the tunnel requires rekeying. This means i should get a username/password request after 24 hours.
A whole lot better then 45 min anyway.
I think there are many ways of configuring VPN with Cisco IOS
Apparently my institution uses one that Apple got to work with 10.6.4, whereas you are still stuck with a defective one. If would suggest filing a bug with Apple. Since you are in control of both ends, you might be able to provide worthwhile debugging feedback to them.
Good luck!
Also try setting dpd_delay=0 in /etc/racoon/remote/<ipaddr>.conf to turn off dead peer detection, which should mitigate idle connections being dropped and mitigate the need to run ping in the background that some people see.
That solves both issues, much appreciated!