IPSEC interoperability - PAN-VM-200 to CISCO ASA 5505

[burtond]

Good Day

First - Do you need a IPSEC license for a PAN-VM?

Second - Can I follow the PAN guide for - "IPSEC interoperaability between Palo Alto Firewalls and CISCO ASA"? The reason I ask is the guide show conifguration between a PAN-5060 and a ASA 5505.

Third - Has anyone done this configuration? and are there things to watch for?

Thanks

Dana

[reaper]

Hi There

no license is needed to be able to support IPSEC on any firewall platform

all firewalls share the same functionality, the only difference is capacity based on the platform (amount of sessions and throughput basically) so that guide will apply to the PA-VM as well

regards

Tom

[Raido_Rattameister]

Hi,

First - Palo has no IPSec license so not needed.

Second - Palo supports standards based IPSec so you can do vpn with pretty much every other box out there.

If you configure "passive mode" on IKE gateway and ask other end to connect to you then you see exactly what does not match in Monitor > System log 

[burtond]

Thanks, I try it and get back to you.

Dana

[syadav]

Hi Burtond,

As others have mentioned, NO license is required for setting up IPSEC VPN on Palo alto firewalls.

Regarding setting up a VPN with Cisco, I would advise you to keep in mind that the "proxy-IDs" match (vice-versa) exactly as on Cisco since Cisco doesnt like 0/0 proxy IDs. This is a common gotcha when dealing with IPSEC between Cisco and other vendors (which support 0/0 proxy IDs)

[pankaku]

Phase 1 and phase 2 life time should be checked.

[burtond]

Thanks for updates... I will pass them on....

The PAN document doesn't show how to config IKE 2 for certificates.... does anyone have a document showing it? or has anyone done this? 

We are getting "peer not matching error" on CISCO

Dana

[OtakarKlier]

Hello,

While I have not used certificates, I have built many tunnels between Cisco and a PAN, same on all version i have worked on so far. As stated before, make sure phase 1 and 2 are identical, also check the 'interesting' traffic, 'Proxy ID's' on the PAN and they must match the 'Crypto map' on the Cisco side.

Hope this helps.

[OtakarKlier]

Also I got this from a Cisco TAC engineer a long time ago....

ADAPTIVE SECURITY APPLIANCE ISAKMP STATES:

MM_WAIT_MSG2: Initial DH public key sent to responder. Awaiting initial contact reply from other side. If stuck here it usually means the other end is not responding. This could be due to no route to the far end, the far end does not have ISAKMP enabled on the outside, the far end is down or DES isn't accepted as the encryption algorithm of the ISAKMP policy.

MM_WAIT_MSG3: Both peers have agreed on the ISAKMP policies. Awaiting exchange of keyring information. Hang up’s here may be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.

MM_WAIT_MSG4: In this step the pre-share key hashes are exchanged. They are not compared or checked, only sent. If one side sends a key and does not receive a key back, this is where the tunnel will fail. I have seen the tunnel fail at this step due to the remote side having the wrong Peer IP address. Hang up’s here may also be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.

MM_WAIT_MSG5: This step is where the devices exchange pre-shared keys. If the pre-shared keys do not match it will stay at this MSG. I have also seen the tunnel stop here when NAT Traversal was on when it needed to be turned off.

MM_WAIT_MSG6: This step is where the devices exchange pre-shared keys. If the pre-shared keys do not match it will stay at this MSG. I have also seen the tunnel stop here when NAT Traversal was on when it needed to be turned off. However, if the state goes to MSG6 then the ISAKMP gets reset that means phase 1 finished but phase 2 failed. Check that IPSEC settings match in phase 2 to get the tunnel to MM_ACTIVE.

AM_ACTIVE / MM_ACTIVE: The ISAKMP negotiations are complete. Phase 1 has successfully completed.

MM_NO_STATE: ISAKMP SA has been created but nothing else has happened yet.

MM_SA_SETUP: The peers have agreed on parameters for the ISAKMP SA.

MM_KEY_EXCH: The peers have exchanged Diffie-Hellman public keys and have generated a shared secret. The I SAKMP SA remains unauthenticated.

MM_KEY_AUTH: The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to QM_IDLE and a Quick mode exchange begins.

AG_NO_STATE: The ISAKMP SA has been created but nothing else has happened yet.

AG_INIT_EXCH: The peers have done the first exchange in Aggressive mode but the SA is not authenticated.

AG_AUTH: The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to QM_IDLE and a Quick mode exchange begins.

QM_IDLE: The ISAKMP negotiations are complete. Phase 1 successfully completed. It remains authenticated with its peer and may be used for subsequent Quick mode exchanges.

[burtond]

Thanks I'll look these over and pass them on.

[burtond]

It was the Crypto Map and Proxy ID config.... all is working, not with certificates yet but, tunnel is up.

Thanks

Dana

[woolp4]

Hiya, Have you managed to get certificates working between ASA and Palo Alto? We are getting the following error messages. Thanks, Paul

2016-08-08 12:44:02 [PROTO_ERR]: RSA_verify failed: 4112512720:error:04091064:rsa routines:INT_RSA_VERIFY:algorithm mismatch:rsa_sign.c:269:

2016-08-08 12:44:02 [PROTO_ERR]: Invalid SIG.

2016-08-08 12:44:02 [PROTO_ERR]: 30779:y.y.y.y[500] - x.x.x.x[500]:0x8a44598:authentication failure