IKE v2 ASA vs. PA

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

IKE v2 ASA vs. PA

L1 Bithead

Hi together,

 

at the beginning of this week I ran into the following challenge.

 

I’ve to setup an IKE v2 Tunnel between a Cisco ASA and a PA-850 running on 8.0.12.

During the configuration the Cisco Partner send me the local and remote tunnel pre-shared key.

After a few seconds of confusion, we started a funny discussion and 30 minutes of try and error later, we ended with the result, that IKE v1 is safe enough at this moment and we have to do some researching how to solve this issue.

 

Does anybody have the same challenge or maybe a solution? (Replacing the ASA is NOT a solution)

 

Kind regards

Sven

1 accepted solution

Accepted Solutions

Hi together,

 

sorry for the delay. We solved the issue and it was as easy as expected.

The solution is really using the same PSK for local and peer.

After some escalation and some testing with an additional ASA, we came to that result.

Now the other reseller tries to fix this on their ASA.

So, thanks for your support.

 

Kind regards

Sven

View solution in original post

4 REPLIES 4

Cyber Elite
Cyber Elite

What do the logs say? Are you positive that the IKE Crypto maps actually matched; were you using IKEv2 only mode or IKEv2 preferred. 

Really this boils down to the logs files, you need to be able to look at those and determine why exactly it was failing fairly easily. 

Hi together,

 

sorry for being so quiet but the customer has changed prios und IKEv1 is working, so ...

Now I've some time and I'm back in this business.

We checked all proposals and reduced these to a minimum, everything fine.

We checked the ikemgr.log and see one error but for me it was very generally:

 

 

2018-10-30 07:45:31.339 +0100  [DEBG]: processing isakmp packet

2018-10-30 07:45:31.339 +0100  [DEBG]: ===

2018-10-30 07:45:31.339 +0100  [DEBG]: 798 bytes message received from 7.8.9.10[500]

2018-10-30 07:45:31.339 +0100  [INFO]: {   16:     }: received IKE request 7.8.9.10[500] to 1.2.3.4[500], found IKE gateway customer1

2018-10-30 07:45:31.340 +0100  [PNTF]: {   16:     }: ====> IKEv2 IKE SA NEGOTIATION STARTED AS RESPONDER, non-rekey; gateway customer1 <====

                                                      ====> Initiated SA: 1.2.3.4[500]-7.8.9.10[500] SPI:249143bd726de95a:71c6b29a83fbac26 SN:27 <====

2018-10-30 07:45:31.340 +0100  [PWRN]: {   16:     }: 1.2.3.4[500] - 7.8.9.10[500]:0x104ca350 vendor id payload ignored

2018-10-30 07:45:31.340 +0100  [PWRN]: {   16:     }: 1.2.3.4[500] - 7.8.9.10[500]:0x104ca350 vendor id payload ignored

2018-10-30 07:45:31.340 +0100  [DEBG]: {   16:     }: received Notify type NAT_DETECTION_SOURCE_IP

2018-10-30 07:45:31.340 +0100  [PWRN]: {   16:     }: 1.2.3.4[500] - 7.8.9.10[500]:0x104ca350 ignoring unauthenticated notify payload (NAT_DETECTION_SOURCE_IP)

2018-10-30 07:45:31.340 +0100  [DEBG]: {   16:     }: received Notify type NAT_DETECTION_DESTINATION_IP

2018-10-30 07:45:31.340 +0100  [PWRN]: {   16:     }: 1.2.3.4[500] - 7.8.9.10[500]:0x104ca350 ignoring unauthenticated notify payload (NAT_DETECTION_DESTINATION_IP)

2018-10-30 07:45:31.340 +0100  [DEBG]: {   16:     }: received Notify type 16430

2018-10-30 07:45:31.340 +0100  [PWRN]: {   16:     }: 1.2.3.4[500] - 7.8.9.10[500]:0x104ca350 ignoring unauthenticated notify payload (16430)

2018-10-30 07:45:31.341 +0100  [PWRN]: {   16:     }: 1.2.3.4[500] - 7.8.9.10[500]:0x104ca350 vendor id payload ignored

2018-10-30 07:45:31.341 +0100  [DEBG]: proposal #1 len=52

2018-10-30 07:45:31.341 +0100  [DEBG]: proposal #2 len=44

2018-10-30 07:45:31.341 +0100  [DEBG]: proposal #3 len=44

2018-10-30 07:45:31.341 +0100  [DEBG]: proposal #4 len=44

2018-10-30 07:45:31.341 +0100  [DEBG]: proposal #5 len=52

2018-10-30 07:45:31.341 +0100  [DEBG]: proposal #6 len=52

2018-10-30 07:45:31.341 +0100  [DEBG]: proposal #7 len=44

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: see whether there's matching transform

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: found same ID. compare attributes

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: OK; advance to next of my transform type

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: see whether there's matching transform

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: found same ID. compare attributes

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: OK; advance to next of my transform type

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: see whether there's matching transform

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: found same ID. compare attributes

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: OK; advance to next of my transform type

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: see whether there's matching transform

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: found same ID. compare attributes

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: OK; advance to next of my transform type

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: success

2018-10-30 07:45:31.341 +0100  [DEBG]: {   16:     }: update request message_id 0x0

2018-10-30 07:45:31.349 +0100  [DEBG]: 1.2.3.4[500] - 7.8.9.10[500]:(nil) 1 times of 312 bytes message will be sent over socket 1024

2018-10-30 07:45:31.353 +0100  [DEBG]: processing isakmp packet

2018-10-30 07:45:31.353 +0100  [DEBG]: ===

2018-10-30 07:45:31.353 +0100  [DEBG]: 348 bytes message received from 7.8.9.10[500]

2018-10-30 07:45:31.354 +0100  [PWRN]: {   16:     }: 1.2.3.4[500] - 7.8.9.10[500]:0x10332020 vendor id payload ignored

2018-10-30 07:45:31.354 +0100  [DEBG]: {   16:     }: CR received: num of CA: 3

2018-10-30 07:45:31.354 +0100  [INFO]: {   16:     }: CR hash (3) ignored, no match found.

2018-10-30 07:45:31.354 +0100  [DEBG]: {   16:     }: received notify type INITIAL_CONTACT

2018-10-30 07:45:31.354 +0100  [DEBG]: {   16:     }: received notify type ESP_TFC_PADDING_NOT_SUPPORTED

2018-10-30 07:45:31.354 +0100  [DEBG]: {   16:     }: received notify type NON_FIRST_FRAGMENTS_ALSO

2018-10-30 07:45:31.357 +0100  [PERR]: {   16:     }: 1.2.3.4[500] - 7.8.9.10[500]:0xffe401f7d0 authentication failure

2018-10-30 07:45:31.357 +0100  [INFO]: {   16:     }: 1.2.3.4[500] - 7.8.9.10[500]:0xffe401f7d0 authentication result: failure

2018-10-30 07:45:31.357 +0100  [DEBG]: 1.2.3.4[500] - 7.8.9.10[500]:(nil) 1 times of 76 bytes message will be sent over socket 1024

2018-10-30 07:45:31.357 +0100  [DEBG]: {   16:     }: update request message_id 0x1

2018-10-30 07:45:31.357 +0100  [INFO]: {   16:     }: 1.2.3.4[500] - 7.8.9.10[500]:(nil) closing IKEv2 SA customer1:27, code 15

2018-10-30 07:45:31.357 +0100  [PNTF]: {   16:     }: ====> IKEv2 IKE SA NEGOTIATION FAILED AS RESPONDER, non-rekey; gateway customer1 <====

                                                      ====> Failed SA: 1.2.3.4[500]-7.8.9.10[500] SPI:249143bd726de95a:71c6b29a83fbac26 SN 27 <====

2018-10-30 07:45:31.358 +0100  [DEBG]: {   16:     }: SA dying from state RES_IKE_AUTH_RCVD, caller ikev2_abort

2018-10-30 07:45:31.358 +0100  [DEBG]: {   16:     }: SA deleted: state DYING, caller ikev2_abort

2018-10-30 07:45:31.358 +0100  [DEBG]: {   16:     }: stop retransmit for sa 0xffe4010180 (DEAD), CID 0, child 0xffe4010180

 

Any idea?

Kind regards

Sven

 

Hi @sstein

 

What does happen when you try to initiate the tunnel? Is there also an authentication error on cisco side? What proxy IDs did you configure or do you use a route based vpn? If you have configured proxy IDs, is is possible to do another test when you delete the proxy IDs completely on the paloalto?

It looks like there is NAT in place on the way between the two gateways, did you configure the phase 1 identification accordingly?

Hi together,

 

sorry for the delay. We solved the issue and it was as easy as expected.

The solution is really using the same PSK for local and peer.

After some escalation and some testing with an additional ASA, we came to that result.

Now the other reseller tries to fix this on their ASA.

So, thanks for your support.

 

Kind regards

Sven

  • 1 accepted solution
  • 19636 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!