Update to 8.0.6 appears to have broken IPSec tunnel connections

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.

Update to 8.0.6 appears to have broken IPSec tunnel connections

L0 Member

Since our PA updated we've had a problem with one IPSec Tunnel not routing correctly. It appears to relate to just one Proxy ID but I've checked all and they're exactly the same as the PFSense box we're connecting to. Everything was fine until the update to 8.0.6.

 

I've followed this KB...

 

https://live.paloaltonetworks.com/t5/Management-Articles/IPSec-VPN-Error-IKE-Phase-2-Negotiation-is-...

 

..but both ProxyIDs are perfect. The message we're getting is..


IKEv2 child SA negotiation is failed as initiator, non-rekey. Failed SA: (LOCAL IP)[500]-(DEST IP)[500] message id:0x000021F0. Error code 19


If I head into "tail follow yes mp-log ikemgr.log" I get ....


2018-05-08 15:20:26.680 +0100 [PERR]: { 6: }: received Notify payload protocol 0 type TS_UNACCEPTABLE
2018-05-08 15:20:26.680 +0100 [PNTF]: { 6: }: ====> IKEv2 CHILD SA NEGOTIATION FAILED AS INITIATOR, non-rekey; gateway IKE-Harrogate <====
====> Failed SA: (LOCAL IP)[500]-(REMOTE IP)[500] message id:0x00001B7C parent SN:1450 <==== Error code 19
2018-05-08 15:20:27.793 +0100 [PWRN]: { 6: }: 38 is not a child notify type
2018-05-08 15:20:27.793 +0100 [PERR]: { 6: }: received Notify payload protocol 0 type TS_UNACCEPTABLE
2018-05-08 15:20:27.793 +0100 [PNTF]: { 6: }: ====> IKEv2 CHILD SA NEGOTIATION FAILED AS INITIATOR, non-rekey; gateway IKE-Harrogate <====
====> Failed SA: (LOCAL IP)[500]-(REMOTE IP)[500] message id:0x00001B7D parent SN:1450 <==== Error code 19
2018-05-08 15:20:27.959 +0100 [PWRN]: { 6: }: 38 is not a child notify type
2018-05-08 15:20:27.959 +0100 [PERR]: { 6: }: received Notify payload protocol 0 type TS_UNACCEPTABLE
2018-05-08 15:20:27.959 +0100 [PNTF]: { 6: }: ====> IKEv2 CHILD SA NEGOTIATION FAILED AS INITIATOR, non-rekey; gateway IKE-Harrogate <====
====> Failed SA: (LOCAL IP)[500]-(REMOTE IP)[500] message id:0x00001B7E parent SN:1450 <==== Error code 19
2018-05-08 15:20:30.758 +0100 [PWRN]: { 6: }: 38 is not a child notify type

Anyone know what I'm doing wrong here?

 

Here's the debug logs...

 

2018-05-08 16:15:05.430 +0100  [DEBG]: ===
2018-05-08 16:15:05.430 +0100  [DEBG]: 76 bytes message received from (DEST IP)[500]
2018-05-08 16:15:05.430 +0100  [DEBG]: {    6:     }: response exch type 36
2018-05-08 16:15:05.430 +0100  [DEBG]: {    6:     }: update response message_id 0x235d
2018-05-08 16:15:05.430 +0100  [DEBG]: {    6:     }: received notify type TS_UNACCEPTABLE
2018-05-08 16:15:05.430 +0100  [DEBG]: {    6:     }: ikev2_process_child_notify(0x14b8230, 0x7f6b037d8c10), notify type TS_UNACCEPTABLE
2018-05-08 16:15:05.430 +0100  [PWRN]: {    6:     }: 38 is not a child notify type
2018-05-08 16:15:05.430 +0100  [PERR]: {    6:     }: received Notify payload protocol 0 type TS_UNACCEPTABLE
2018-05-08 16:15:05.430 +0100  [PNTF]: {    6:     }: ====> IKEv2 CHILD SA NEGOTIATION FAILED AS INITIATOR, non-rekey; gateway IKE-Harrogate <====
                                                      ====> Failed SA: (LOCAL IP)[500]-(DEST IP)[500] message id:0x0000235D parent SN:1450 <==== Error code 19
2018-05-08 16:15:06.614 +0100  [DEBG]: processing isakmp packet
2018-05-08 16:15:06.614 +0100  [DEBG]: ===

 

 

6 REPLIES 6

Cyber Elite
Cyber Elite

@Andre_Magri,

Have you verified within the XML that what's being displayed on the GUI is actually what's being read by the firewall? 

Are you saying there could be a significant difference between what's being viewed in the GUI as to whats being read in the XML ?

 

I am seeing the same behavior on version 9.0.5.

The tunnel seems to run initially, but after a while the PA is unable to initiate new SA's.

@JanPou,

Could you open a new discussion with your exact issue and troubleshooting steps that you have done. If your tunnel is coming online at all, it's not the same as referenced in this post. 

had a similar issue ended up being SHA256-CBC was chosen on palo side, added / switched to SHA-256-GCM and it came right up. 

Hi @jkim12  - Why did you have to add SHA-256-GCM, did you do that in the remote side as well?

 

 

 

Regards!

AES-256 wasn't selectable in the pfsense config they showed me for CBC or GCM so just on the palo side manually selected AES-256-GCM and added AES-256-CBC as secondary ( although not needed) and it came right up. 

  • 11209 Views
  • 6 replies
  • 1 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!