Cisco VPN Client issues with PIX 506e

Next time, try

clear ipsec sa

Is it possible that those clients are having their IP address changed by their ISP in the middle of a session? If so then change to isakmp identity hostname on the PIX, and make sure that all of the PCs have distinct internal names. If a client is identifying itself to the PIX by IP address ("Hello, my name is 24.25.26.27!") and the IP address changes then when it reconnects it would send the new IP ("Hello, my name is 24.38.149.5!") and the PIX wouldn't know to say, "Oh, Hi, I know you; hold on a second while I clear out the old connections I have for you and build up some new ones."

Thank you for your response.

I don't believe that the clients are having their IPs changed in the middle of a session as 99% of the clients are through broadband....although I guess it's surely possible.

So you are saying, I would have to give each client PC a distinct name on the PIX? How would the PIX know which is which? If Client_27 is logging into the VPN from home today, and he's running Windows XP through a cable modem, how would the PIX know who is what other than by IP?

Walter Robers> > >For some odd reason, our remote users who use the Cisco VPN client

Not a unique name on the PIX: a unique name in the XP "Computer Name" control panel. I've noticed that on most Dell systems that the default computer name comes out something akin to Dell_ followed by the hex of most of the MAC address of the system; that's certainly unique enough. But for a lot of other systems, the name ends up as "HOME" or "WORK" or "MY PC", or someone's first name, and those all need to be uniquified in order for "isakmp identity hostname" to work.

For this purpose, it doesn't matter what the name -is-, only that it is unique amongst all of your VPN users, so that when the connecting PC reaches the PIX and sends the PC's name, the PIX can immediately recognize that it already has Security Associations under that name.

The problem, you see, is that if a VPN host leaves a connection except through a session-lifetime timeout or formal disconnect, then the security associations (SAs) are left intact, because TCP/IP cannot inherently tell the difference between a connection that vapourized and a connection that is just slow (or a connection that get fouled up but will be put back together exactly the same way, allowing the communications to resume right where they left off.) When the client disconnection leaving SA's there, and then calls up and presents itself by IP and that IP isn't the same one as is listed against the previous time, then as far as the PIX can tell this is a -new- connection for someone different. But the old Security Associations are still there and still intercepting the traffic for that destination, still expecting that old connection to come back to life, so packets don't reliably get delivered back to the client (they get queued for the old Security Association instead.)

When, though, a client with a unique name (or a fixed and unchanging IP address) reconnects, it sends an ISAKMP token that means "I'm back, throw away all the old Security Associations that are listed against my ID". The PIX looks through the SA table, sees the old ones with the matching ID, clears them out, and then the new SAs are negotiated. Traffic can start flowing immediately because there is no old SA hanging around intercepting the traffic and trying to send it to the old address.

But this only works if the clients have unique fixed IP addresses (isakmp identity address), or have unique fixed internal hostnames (isakmp identity hostname): otherwise on the recall, the new ID doesn't match and the old cruft stays around until it times out.

Thanks again for your detailed and very informative response.

I called up all of our VPN users, and confirmed that all of their home PCs indeed are unique from one another. So there is no conflict of names happening.

I also got a call from a VPN user a little bit ago complaining about their inability to access the network through the VPN. So instead of doing a 'reload', I followed your suggestion and did a 'clear ipsec sa'.

I have yet to hear from them, but hopefully that did the trick.

Unfortunately, if that did work, I am still stuck logging into the PIX and typing in a command everytime a user can't connect.

Walter Robers> > >I don't believe that the clients are having their IPs changed in the

okay, now configure isakmp identity hostname and then clear ipsec sa when it isn't busy.

It is also possible to clear a particular SA, but I always have trouble finding the command when I want it.

Well I tried the 'clear ipsec sa' and it didn't work. I had to do a 'reload' and then the client was able to log in again and use the VPN.

I am not sure what could be going on here. I am coming from a Linux IP Tables background to this Cisco PIX. The PIX command set seems simple enough, but I see no logs or even logging options to even begin an investigation as to what could be causing this.

So I should still do the 'configure isakmp identity hostname'?

Walter Robers> > >I called up all of our VPN users, and confirmed that all of their home

try:logging

Use these commands to enable logging, view logs, and view configuration settings.

logging enable ?Enables the transmission of syslog messages to all output locations. *

no logging enable ?Disables logging to all output locations. *

show logging ?Lists the contents of the syslog buffer and the current logging configuration.

PIX can send syslog messages to various destinations. for instance: Internal Buffer

logging buffered severity_level

and debug:

debug crypto ipsec - View the IPSec negotiations of phase 2. *

debug crypto isakmp - View the ISAKMP negotiations of phase 1. *

debug crypto engine - View the traffic that is encrypted.

I did a 'sh running config' command and I see that I have: isakmp identity address

I imagine my VPN issues may clear up if I change it to 'isakmp identity hostname'

Should I do: no isakmp identity address isakmp identity hostname wr mem reload

That's all I need to change, right?

Thanks!

I am facing similar issue. Your issue resolved after you changed it to isakmp identity hostname? do isakmp identity address and hostname commands work together/? I am anxious as I am already running almost 20 site to site tunnels in my firewall.

snipped-for-privacy@gmail.com wrote: