IKEv2 Site to Site VPN to Cisco ASA5540

[Remo]

Hi folks,

Are there any Cisco ASA specialists out there?

We have a problem with a site to site vpn connection between paloalto and an ASA 5540. Actually the problem seems to be on the ASA side.

The proxy id's on the PA are configured like this:

Remote (ASA): 0.0.0.0/0

Local: 1 private /24 subnet

As described in the title, we use IKEv2. Now everything works as expected when the tunnel is initiated from our paloalto. Phase1 & 2 will be brought up with the configured settings and subnets.

But, when Cisco ASA is the initiator it simply ignores the configured phase 2 subnets and uses a /32 hostaddress as their local proxy id and our correct /24 subnet as remote id. Because of the fact, that palo accepts this phase 2 request with IKEv2 the vpn is connected successfully. The problem then starts when a second host behind the ASA tries to communicate over the VPN tunnel. Then the ASA tries to initiate another phase 2 with the new source host ip as phase 2 network. This is also working but then the alredy established phase 2 will be kicked away by PaloAlto and from then on the first host is no longer able to communicate over the tunnel.

Is anyone familiar with this problem or even better, knows how to fix this?

Regards,

Remo

PS: I already had exactly this issue 2 months ago with another Cisco ASA. There we went back to IKEv1 which solved the problem and the ASA was using the staticly configured subnets instead of hostaddresses ... but onfortunately this is no option for this customer ...

[ansharma · Accepted solution]

Hey vsys_remo,

Sorry to be the bearer of bad news but you are hitting a bug expected to be fixed in 8.0.3/7.1.11.

The only way to get this working would be to make PA as the initiator. The other option would have been to use IKEv1 (which can't be).

Regards,

Anurag

[Remo]

Hi @ansharma

Bad luck 😛

At least we now know, that we don't have to further troubleshoot the issue.

So I assume 8.0.3 will be released in about 2 weeks, right? (Assuming the normal releases all 6 weeks)

Do you have more technical details regarding this bug? Because so far I don't fully understand how this could be fixed from PAN, because so far it only looked like the ASA is using these host-IP's for phase 2. So if cisco is nothing doing wrong and uses 0.0.0.0/0 as local network, how can palo use the host-ip for the ipsec-sa, which it does not know at that point of the tunnel setup process? And it also looks like this problem is specifically showing up in IKEv2 tunnels to cisco ASA and no other vendors, what again makes no sense to me 😛

Anyway, thank you Anurag for the information.

Regards,

Remo

[ansharma]

vsys_remo,

I can't go into details at the moment. Haven't seen this issue with another vendor yet.

And yes, 8.0.3 should be out in the 2nd-3rd week of June. 

Regards,

Anurag

[Remo]

Hi @ansharma

I have no evidence that it is really this, but I assume this fix has now introduced other IKEv2 problems. After the upgrade to Version 8.0.3 we started seeing other IKEv2 problems, so far "only" with PFSense firewalls. As I have seen the problem happens at rekey time. So there was an existing tunnel, but when the other side tries to renogotiate everything PaloAlto cannot match the proposed phase 2 networks to the configured one, even the proposal and the configuration have exactly the same parameters.

--> The tunnel ONLY comes up when the existing SA's are manually cleared.

Regards,

Remo

[ansharma]

Hi @Remo ,

Sorry for the late reply, I have been busy with other things. I've not yet come across issues with 8.0.3 pertaining to IKEv2. I'd suggest you get a case open with TAC and we can have a look at the issue.

Regards,

Anurag

[Remo]

Hi @ansharma

Thanks for the reply. I would have done that ... but the impact on existing tunnels (not to Cisco ASA firewalls) was just too big, so we had to downgrade pretty fast. So unfortunately we're not able to provide logs/techsupportfiles ...

I already told @reaper about this so PAN at least somehow already knows about this, but I understand without actual logs it is difficult to troubleshoot ... the only way is to reproduce the issue.

Regards,

Remo