Simon Heimlicher
 
  
 

Save Password of Cisco VPN in Mac OS X 10.6

Snow Leopard brought built-in support for Cisco VPN over TCP (but not over UDP). However, as of 10.6.6, there is still one issue: While the password can be saved in the keychain, the daemon configd is not granted access, causing the user to be bothered to enter the password every time upon initiating a connection

(If you are running Mac OS X 10.6.0–10.6.3 and experience unexpected disconnections when the phase 1 key should be renegotiated (after 48 minutes), there is a work-around here.

The password issue can be solved as follows

  1. Open “Keychain Access” (use Spotlight)
  2. Find the entry corresponding to the XAUTH password using the search field
  3. Click the “Access Control” tab, then the ”+” button and add /usr/libexec/configd to the list of applications that are allowed to access the keychain entries. To navigate to this directory, just start typing /usr/libexec/ and then select configd.

Common problems

  • Whenever you change the slightest detail of your VPN configuration, you will have to do this again.
  • If you are still being asked for your password when using the VPN menu item to initiate a connection, try disabling and subsequently re-enabling the VPN menu (“Show VPN status in menu bar”), then repeat the above.
  • If you get an error message about a “configuration problem” when initiating the connection, it is typically due to racoon being running when it should not be. To kill this daemon, proceed as follows:
    1. Be sure to be logged in as administrator.
    2. Open the “Terminal” application
    3. Type sudo killall racoon and press the “Return” key
    4. When asked for a password, enter your login password.

Navigating to '/usr/libexec/configd'

'/usr/libexec/configd' added

Discussion

Mike, 2012/01/05 18:22

Great tip. You just saved me several headaches. Thanks so much.

Roger Bannister, 2011/09/10 10:05

Lamont or anyone.

could anyone please give instructions of how to change the <ipaddr>.conf - where it is etc….

I have found the etc folder and the racoon folder but in there is only a racoon.conf and a psk.txt

Andreas, 2011/09/03 16:14

I can confirm that adding /usr/libexec/configd in the XAUTH keychain (by pressing Command-Shift-G to enter /usr/libexec) still solves the first issue in Lion (10.7.1).

I don't have a solution for the second issue with the disconnections after about 48 Min. I have the folder /etc/racoon/remote/ with a racoon.conf in it. I can't edit that and it seem to be connected to an old VPN I was using. My current IP Secc VPN connection (SIPGATE VPN) isn't listed there.

Any ideas ?

Dirk Staupendahl, 2011/09/10 16:25

Hi Andreas,

I don´t find any XAUTH Keychain in my keychain, normally it is deleted after closing the VPN connection. Where and how did you find yours?

Kind regards, Dirk

Dirk Staupendahl, 2011/07/29 17:42

Hi there,

I spend hours and nights on this problem, scanning hundreds of internet pages regarding this problem. Even called Apple support. Finally I think, there is now workaround at this moment. I use OS 10.6.8. The racoon conf-File is initiated “on the fly” in the folder ”/var/run/racoon/<ipaddr>.conf”. This file holds the timeout information. It also disappears when ending the VPN connection. The timeout value is some kind of hard-coded to 3600 sec. (see here ⇒ https://discussions.apple.com/message/13035161#13035161). Due to Apple support, this is fixed for security reasons and can not changed or edited by the user. Even modifying the racoon file in ”/etc/racoon/racoon.conf” with any kind of additional phrase at the end (“include /var/run/racoon/xxx.conf ;” etc. didn´t change anything, just broke the ability of the VPN connection. Saving the password to the keychain also doesn´t work in OS 10.6.8.. The “IPsec Xauth Password” is deleted in the moment, the VPN is used for the first time. I even tried to change the just build ”/var/run/racoon/<ipaddr>.conf”-File with the password window staying open during the VPN login, by substitute “3600 sec.” with “24 hours” with TextEdit and copying the file back to its original place in ””/var/run/racoon/…”. But after around 52 min, the Login-Windos for the VPN password reappeared. I think, Apple finally shot every backdoor and made every known workaround from earlier MacOS 10.6.x impossible. Is there anyone out there, who is smarter than Apple ;-)

Rick Abegglen, 2011/05/07 05:27

Hi Simon - My Macbook Pro is running 10.6.7. I followed your excellent instructions re Keychain Access to the letter, adding configd to access the VPN Xauth key. The VPN Xauth key had the right password stored in it.

But the strangest thing happened, the first time I connected to the VPN I was prompted to enter the password anyway, and before my eyes (since Keychain Access was still up) the VPN Xauth key was deleted. I still have to enter my password every time.

Any tips?

Someone or Other, 2011/03/05 23:14

I came to this site googling for solutions to a related problem. I'm posting my solution, maybe it will be helpful to someone:

The first time I configured the VPN client in OS 10.6.6 it connected fine. I disconnected and tried to reconnect. I got an error saying “Configuration error. Check settings and try to reconnect.” (I got the error in German, I include it here for everybody googling that error message: “Ein Konfigurationsfehler ist aufgetreten. Überprüfen Sie die Einstellungen und versuchen sie erneut, eine Verbindung herzustellen”).

The VPN client connected fine after each boot up, and returned the same error after disconnect/re-connect.

I solved the problem by changing the settings in the “Access Control” tab (see image in article at top of this page) from “Confirm before allowing access” to “Allow all applications to access this item”. I have never seen the error since.

Duane Murphy, 2011/02/04 19:39

I wanted to confirm that at least the second problem (password verification after 48m minutes) still exists in Snow Leopard 10.6.6.

Dima Ulberg, 2011/02/08 20:53

This is even more bizarre. I have two ISP connections at my house. Cable modem via Comcast and DSL over AT&T. Comcast is my primary connection and AT&T is used as backup when Comcast goes down (which happens not very often but takes long time for them to fix). If am on the Comcast VPN client will prompt me for password around 48th or 49th minutes of the connection. When I am on the AT&T VPN stays on for at least 24 hours with no problem or prompt for reconnect. I tried to switch routers/firewalls on both subnets with no success. I am fresh out of ideas. I tried approach described on this page with different permutation - connection (on Comcast) stays up but routing will stop working around 48th minute of the connection. I would appreciate any suggestions.

Ansgar Asseburg, 2011/02/09 17:16

@Duane Murphy Did you get the password storage working under 10.6.6? My keychain seems to 'forget' the password entry every time I connect to the server. Once I enter another VPN connection under network the password entry shows up again.

I just can't figure this out…

Fabian Jäger, 2010/11/30 07:32

I am looking for someone who successfully connected with racoon/setkey to a Cisco concentrator via the command line. Please let me know as I have some questions regarding a software project. Thanks!

Bruno Weber, 2010/09/23 10:38

Hi Simon, We are experiencing a strange thing here among the mac users. Under 10.6.4, I started to have hangs of the vpn after about 45 min with the built-in client, and after about 7h36min using the application Cisco VPN client (both ways, the client still appears to be ok, but the connection is gone). You say that the rekeying issue was solved in 10.6.4., but we experience this problem only since the last OS update! Any hint how we can identify the problem? Bruno

Simon Heimlicher, 2011/02/14 15:15

@Bruno: I don't use Cisco's VPN client and unfortunately cannot be of help with your issue

Juda Meg, 2010/08/06 19:46

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

Simon Heimlicher, 2011/02/14 15:19

@Juda: Unfortunately I have no experience with the server end. It might be that Apple's configuration tools do a checksum of their config files and don't like if you change them. On top of that, I assume the file at /var/run/racoon is created dynamically (at least on the client), hence modifying it may not be of use anyway.

Scott, 2010/08/06 06:12

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!

ernie, 2010/07/19 23:08

press Command-Shift-G, enter /usr/libexec

SubaruWRC, 2010/07/18 21:48

How do you add ”/usr/libexec/configd” to the Keychain?

Tony, 2011/05/05 23:01

Hi SubaruWRC, did you get an answer to your questions. I too can't figure out how to add /usr/libexec/configd. I used the spotlight but it can't find it. In fact, I can't even find the /usr directory.

Mike Ryan, 2010/07/08 17:50

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”.

Tom Boucher, 2010/07/08 04:17

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?

Simon Heimlicher, 2010/07/24 01:36

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.

Tom Boucher, 2010/07/07 17:24

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.

21, 2010/07/07 14:33

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!

Simon Heimlicher, 2010/07/07 14:39

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?

21, 2010/07/07 15:26

Thanks for your reply!

eh, I'm try create a new “Location”, but it also delete the entry by itself…. sigh

Simon Heimlicher, 2010/07/24 01:32

I am out of ideas, sorry :-(

Joakim Eriksson, 2010/06/28 15:20

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.

Simon Heimlicher, 2010/07/06 23:46

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!

Lamont Granquist, 2010/03/19 15:58

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.

Thomas Scheiwiller, 2010/03/04 08:57

That solves both issues, much appreciated!

Enter your comment
DUKCF