Issue with IPSec Client after ASA upgraded to 8.4(3)

shihabhamsa · ‎04-09-2012

Hi,

We were running on ASA 5540, 8.2(1) in active/standby mode.

Now we have upgraded standby box to 8.4(3) and it is active now.

There are few L2L, one EazyVPN, anyconnect and Remote IPsec configured in the ASA from previously. After the upgrade my ASA started behaving wierd. L2L, EazyVPN are working perfect without any hitch. But my anyconnect and Remote IPsec is having problem.

The issue is that sometimes there will not be any issue, both will work perfect. But other times clients will not be able to connect giving error 412 remote peer is no longer responding. I will not get any log in my client for the connection as well as in my ASA.

If that issue happens both Remote IPsec and AnyConnect will not connect giving the error 412.

At that time if I fail back to old 8.2(1) clients will be prompted for user authentication and VPN will work fine.

After a client connects successfully and I fail over to the new 8.4(3) box, the issue will be solved temporarily. From then every client will be able to connect to the vpn and works perfect.

This is giving me a hard time.

But in any case clientless is not having any issue.

Guys can you please help me with this. I have attached relevant running config from 8.4(3)

david.g.white · ‎04-13-2012

This situation may arise when the option to send certificate chain is selected on the VPN client?

This issue worked like a 'creeping death' situation where devices that worked fine for months just stopped.

Check your client config and un-select the send cert chain option

Sent from Cisco Technical Support iPad App

shihabhamsa · ‎04-14-2012

I am never using the certificates and there is no command that I have issued in the client related to certificates.

Jouni Forss · ‎04-14-2012

Hi,

From your original post I get the picture that your other firewall is running 8.2 and the other one 8.4?

You are running a pair of ASAs in failover with missmatched software versions?

Atleast this is not suggested as a long term solutions but for the actual update process.

Though as I have not used a failover pair in this manner I can't really say if this would be one of the problems of running such a setup.

Then again I might have gotten your original post wrong but it does seems like you arent running an indentical Failover pair?

- Jouni

shihabhamsa · ‎04-14-2012

Yes, I was in real time migration. That is why one box I (Primary/standby) running on 8.2(1) and the Secondary/Active running on 8.4(3).

Many a suggested it might be an issue of the mismatched versions of OS. Because of that I upgraded both the boxes to 8.4(3). Now the cluster is in 8.4(3) without any issue running smooth. BUT NOT PREDICTABLE in the case of IPSec remote vpn. Still I am facing the same issue. Now the case is most of the time there is no problem at all. Every user can get connect to the vpn. But sometimes no way. Whenever client try to connect, it will just give Error:412 Remote peer is not responding. I will not get any debug message on my ASA that time. But if I failover the box it will start working again.

Killing all my patience. Thinking might be an issue with 8.4(3) I tried 8.4(2). I got the same issue there too :-(

shihabhamsa · ‎04-17-2012

One more interesting point to this thread.

The issue happens only when the secondary becomes active.

I have switched my primary to be active and no one has reported the issue for the past few days.

i had upgraded the secondary/standby unit first. Since then it was the active device.

Whenever the issue happened and I switch my primary to be active the issue seems to be solved, but for no reason I will then revert the secondary to be active. So for that time I will get a workaround.

Now I have switched back to my primary to active for ever and it seems issue has been moved out completely. Anyway not for sure untill the issue comes up next time.

Might be a active/standby failover bug with 8.4 updates for the ikev1?

shihabhamsa · ‎04-19-2012

I got the problem Analyzed now. Cisco TAC has confirmed it as bug

It was first found in 8.4(1).10 and the bug id is

CSCtq32213 VPN ports not removed from pat port pool when crypto map is applied.

The issue is that if you have a client which uses outside vpn other through your ASA (like one of your consultant from your network trying to connect to his company vpn),

it will create an xlate for 4500 udp port, if you have the dynamic NAT given for your outside interface IP.

This will engage the 4500 UDP port on ASA and will not release this xlate entry and will remain there. This will limit users from connecting to our vpn where the gateway is our ASA's outside IP