Cisco ASA 5555 recommended software version?

[milos_p]

Hi guys,

Can someone point me to recommended ASA version for ASA 5555, as I don't see any version being starred in the download section?

Thanks a lot!

Milos

[balaji.bandi]

Latest you can go upto 9.14.4

as per my testing 9.12.4 was good and stable.

[milos_p]

Is there any Cisco document stating TAC recommended versions?

Unfortunate, I cannot find anything.

[balaji.bandi]

Most of the new version are Itnerim or MD, as you see,

as we see due to many bugs around cisco releases Interim version to fix. (if you are effected with bugs, or any feature missing in your version ?) or you looking TAC support you need to get upto level

as i mentioned 9.12.4 running more than year no issue found.

If you have support raise TAC case for additional assurance.

[milos_p]

Well, from time to time I am experiencing some IPsec issues with few site to site tunnels, and clearing tunnel fix the issue.

This is happening in rekey phase generally, and I hope newer version can sort this out.

Btw, currently running on 9.6(4)41 so looking to jump to 9.14.4.

[Rob Ingram]

@milos_p your issue might not be a bug and not resolvable by an upgrade. If using IKEv1 it could just be a timer mis-match, you may also want to check you have DPD keepalives configured.

[Marius Gunnerud]

I agree with Rob here, This is most likely a rekey timer mismatch.  I have also seen similar issues between Cisco and third party vendor equipment where there is a mismatch in diffie hellman configuration.

[itsec_cisco]

Hi guys,

So to be precise, what you mean when you say "rekey timer mismatch"? You mean lifetime for phase2? This is the same, double checked.

If you mean something else, please reference the command for it, so we will be on the same page.

If you have DH mismatch, there is no way to bring the tunnel up, either phase1 if there is mismatch there, or phase2 (if PFS is used), so this MUST be the same 100%.

In my day-to-day experience with VPN tunnels, 3rd party VPN can be challenging sometimes. I tried adjusting quite a lot of parameters to overcome this issue when it was happening, but in the end, clear tunnel command is what solves the problem, which was always in phase2 re-key moment.

This was happening occasionally with other vendors like Juniper or Mikrotik. Cisco to Cisco generally works without any issue.

Also in my case, moving back to IKEv1 from IKEv2 helped to resolve those re-keying issues.

Thanks a lot!

Milos

[Marius Gunnerud]

If you have DH mismatch, there is no way to bring the tunnel up, either phase1 if there is mismatch there, or phase2 (if PFS is used), so this MUST be the same 100%.

Yes, one would think so.  However, I have done this successfully quite a few times which has lead to difficulty troubleshooting issues as one side is able to establish the VPN while the remote side is not able to.  I have done this with Firepower, ASA, Checkpoint, to name a few.  Now there might be some process in the background that matches on DH but if there is I am unaware of it.  In all instances I experienced the issue I was running IKEv2.  And not having access to the remote side makes it even more difficult when you see the tunnel comes up but is unstable.

I have also seen this between Cisco ASR 1000 router and CheckPoint...exact same issue with PFS being enabled on CheckPoint side but not on ASR1000 side.  Tunnel comes up but drops out after a while and then comes up again once ASR1000 initiates traffic.

[milos_p]

Well, this is quite interesting!

I never managed to get tunnel up with DH mismatch, guaranteed. There is no process to match DH, It's part of negotiation process, so what happened in your case, I guess, is that maybe you have proposed multiple ones (possible with IKEv2) and one was chosen that matches the other side. If DH is different, you cannot calculate same shared secret, simple as that, tunnel cannot go up, no way.

I am talking about Phase1 here.

Now for Phase2, maybe some vendor implementation will build Phase2 with misconfigured DH group or no group at all on one side (no PFS). I cannot remember to have any case like this, as I double check parameters (although I am not configure remote end).

Either way, my case is that after successful establishment of the tunnel (both phase1/phase2, all parameters are the same) tunnel is working fine and then during re-key, rarely but it happens for some VPN tunnels, it won't re-build phase2 SA, and get stuck there. A simply clear tunnel resolves it.

Thanks a lot to everyone replying!

[Marius Gunnerud]

It is possible that the remote side for the ASA and Firepower  setups I have seen that there were multiple DH parameters configured.  For the ASR1000 to  CheckPoint VPN setup I know for a fact that only one perameter was configured at both sides.  

Anyway, have SAs just timed out (no longer valid) or is there infact a mismatch? I am wondering if the ingress and egress SAs match at both sides when the issue is happening.

[milos_p]

Hi,

Well, Phase2 SA just times out, and when re-key should happen, it cannot, it's getting rejected.

So I am stuck in a state where I have valid and working Phase1 SA, but I cannot form Phase2 SA anymore, until I clear the that tunnel.

Also, as this is production and I don't have access to the remote side, I was limited in troubleshooting (only show/debugs on my side), and I couldn't catch something to guide me in good direction. I double checked all the parameters, and they are exactly the same on both sides, and tunnel comes up (fresh or cleared) but re-keying is the problem, again, not always, but from time to time with certain vendors and mostly on IKEv2. That forced me to re-configure those tunnels as IKEv1 and problem stopped.

Thanks a lot for great discussion!

Regards,

Milos

[milos_p]

Update:

Last stable release 9.14.4 installed and produced two problems after upgrade and reload of ASA:

1. Without being written in release notes, default PFS DH group changed from 2 to 14, so if you had in your configuration command with "crypto ... set pfs" which was actually group 2 (visible with show run all), after upgrade it didn't translate to "crypto... set pfs group2" but stayed exactly the same "crypto ... set pfs" meaning it is now PFS DH GROUP 14 (again visible with show run all), so in my case, two tunnels who were with PFS DH Group2 failed to negotiate phase2 SA.

2. Recommended ASDM (7.17.1.152) for me doesn't work correctly, it shows a lot of errors for device state, interfaces etc, so I had to use 7.14.1.48 to have ASDM fully functional.

Apart from that, no problems so far.

I am waiting to see if occasional issue I had with re-keying is solved.