Hi everyone,
Has anyone here ever setup a IKEV2 site to site vpn between a Palo Alo firewall and a Cisco ASA.
I was just working with a company at setting this up. I manage the Cisco ASA and they manage the Palo Alto. I was unable to establish a successful site to site vpn using ikev2. Once we moved it to ikev1 it came up instantly.
I already have many ikev2 vpns running on my ASA to other sites successfully but none of them are to Palo Alto firewalls.
The network guys from the company I was working with told me that with Palo Alto, you keed to put in a ikev1 pre-shared key along with the remote and local authentication keys for ikev2…
I found it strange that the Palo Alto would need any ikev1 configuration if you are trying to use ikev2 as that would defeat the purpose really. Can anyone clarify what is required to setup a IKEV2 site to site vpn on a Palo Alto firewall. I have done some research but everything I find is just setting up ikev1 from what I can see.
Thanks in advance…
It’s important to know that ikev2 is not in itself more secure than ikev1. It’s got a couple new wizbang features, but using ikev1 is completely fine security wise.
I’m sorry but those guys don’t know what they’re doing.
This is PAN to a Fortigate, but IKEv2 is an either/or with IKEv1, not both. You can see the screenshots in the guide.
The only thing I’ve run into is using NGE between vendors. Sometimes a vendors implementation isn’t always “standard” and it can cause weird issues.
Also, you probably know this, but since you are setting up s2s between two different manufactures, ensure the DPD Intervals and retries match, ensure the DH (Diffie Hellman groups) match at group level), Encryption for Phase 1 and Phase 2 profiles match, and last, the lifetime of the bytes or tunnel. Working on same Manufacture on both sides make it easy because the defaults are generally the same, but when mixing vendors if the Sec Package doesn’t match or all of the settings exchanged in phase 1 don’t match, the tunnel will never come up. Also ensure the network IDs match on both side, if its 192.168.1.0/24 on the far side, your side better be 192.168.1.0/24 for the remote route incoming.
Yeah I know there’s no security benefit but we use ikev2 connection as standard so really just wanted to stick to that. I just find it odd that the Palo Alto firewall seems to ask for a ikev1 pre-shared-key and you can’t leave it blank. Every video I have seen for Palo Alto so far has been a GUI where the pre-shared-key is a mandatory requirement but it does not state whether it is ikev1 or ikev2. The below the pre-share key options there is Remote and local identity boxes which must be for ikev2.
In theory and with his hardware this is true but there was a critical vulnerability in IKEv1 across the router platforms so it’s not so clear.
Thank you for this link, this gives me a good idea of how they should be implementing it. When configuring the tunnel-group for a IKEV2 connection on a Cisco ASA, you need to specify a local and remote pre-shared key and these need to match on both sides. However the Palo Alto appears to give just pre-shared key box
So my assumption would be that on the Cisco you would make the local and remote ikev2 PSK’s exactly the same. Won’t know for sure until I test it out.
Also ensure the network IDs match on both side, if its 192.168.1.0/24 on the far side, your side better be 192.168.1.0/24 for the remote route incoming.
I find this part confusing. In the RFC documentation I’ve read it suggests that the peers will negotiate to the most restrictive peer-id’s (traffic selectors). In other words if one side has 192.168.1.0/24 and the other has 192.168.1.77/32 then it should build an SA based on the /32.
"IKEv2 allows the responder to choose a subset of the traffic proposed
by the initiator. This could happen when the configurations of the
two endpoints are being updated but only one end has received the new
information. "
In practice this doesn’t seem to work. This is unfortunate when the list of hosts on both sides grows beyond one or two, but one side or the other won’t allow the use of a larger subnet. We’ve got a tunnel with 56 pairs of peer-id’s. Each new host added requires adding a BUNCH of pairs of peer-id’s.
That’s a valid configuration, yes. You can also do asymmetrical keys, so your local would be their remote, and vice-versa. Probably better to keep in symmetrical in this case 
Ah so would you put the pre shared key on the Palo alto into the remote and local identity sections too ?
No, identity is a different authentication field. Usually it defaults to a public IP, but is selectable between IP address, FQDN, email, etc. It has to match on both sides or the phase 2 SA will not form.
