Sunday, August 16, 2020

Odd VPN Issue - IKE Phase 2 Partially Establishing and Working Even With PFS Mismatch

Looking for some input on a VPN issue I fixed a little while ago. It's been bugging me how this VPN ended up in the state that it was in; everything I understand about IKE says that it shouldn't have worked at all.

Relevant pieces of the VPN config (majority of the config is irrelevant to the issue IMO):

My firewall (initiator): Cisco ASA

Their firewall (responder): Palo Alto

Encryption Domain contains multiple SAs

Using IKEv2

Issue:

I got a call that a previously working VPN to a remote location was down. I looked at the tunnel and noticed that only one SA was established, and if I bounced the tunnel, whichever SA started to initialize first would always establish and the rest of the SAs would fail with of a KE Payload error.

I got on a call with the remote side and it was quickly apparent that they had enabled PFS without telling us. I enabled it on our side, bounced the tunnel, and all was good.

What's been annoying the hell out of me is the fact that one of the SAs would always establish, and for all intents and purposes was working 100% correctly with traffic going through it.

How is it possible that anything in Phase 2 would establish if one side had PFS enabled and the other didn't? My guess is that it had something to do with my firewall (with PFS disabled) being the initiator. Perhaps for some reason, the Phase 1 DH-Key was re-used for the first Phase 2 SA, and PFS on the remote firewall didn't kick in until subsequent SAs started to negotiate. But my understanding of PFS is that a new DH-key will be negotiated for ALL Phase 2 SAs, even the first Phase 2 SA. Unless my understanding is incorrect?

I'm willing to add this to the long list of oddities for configuring VPNs between different vendors, but wanted to see if someone could enlighten me on this.



No comments:

Post a Comment