- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
05-08-2018 08:14 AM - edited 05-08-2018 08:18 AM
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...
..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]: ===
05-08-2018 12:47 PM
Have you verified within the XML that what's being displayed on the GUI is actually what's being read by the firewall?
05-05-2020 05:00 AM
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.
05-05-2020 07:33 AM
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.
05-26-2020 11:25 AM
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.
06-04-2020 02:22 PM
Hi @jkim12 - Why did you have to add SHA-256-GCM, did you do that in the remote side as well?
Regards!
06-04-2020 02:25 PM - edited 06-04-2020 02:30 PM
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.
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!