- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-28-2021 11:50 AM
Working with PA 5250 and ASA on the other end. The tunnel between is up and communication flows across however we are seeing constant system errors being logged.
When we enable the tunnel we get the following.
IKEv2 child SA negotiation is succeeded as initiator, non-rekey. Established SA: x.x.x.x[500]-y.y.y.y[500] message id:0x00000C44, SPI:0xDB7C2CCE/0x2C52FBD3.
IKEv2 child SA negotiation is failed as initiator, non-rekey. Failed SA: x.x.x.x[500]-y.y.y.y[500] message id:0x00000B7A. Error code 19
The failed message keeps repeating approx. every 8 sec. In examining the ikev2 settings we do not see any disparities between the two routers--
We have seen these messages however between these two peers
IKEv2 SA negotiation is failed, received notify type ESP_TFC-PADDING_NOT_SUPPORTED
IKEv2 SA negotiation is failed, received notify type NON_FIRST_FRAGMENTS_ALSO
Can anyone shed some light?
Thanks in Advance
01-31-2021 03:46 PM
did you enable a DH group in the phase-2 crypto profile?
if you have (not set nopfs), could you share some of the config to help shed some light on what you are trying to negotiate
01-31-2021 04:12 PM
I've run a couple of tests and i get that error message (tfc padding) all the time when running IKEv2, so it may just be 'expected'
you may need to doublecheck your ProxyIDs to see why one child SA is failing
the remote end should see logging that match the message ID and have more detailed logging to indicate why it fails
02-26-2021 08:46 AM
Checked the proxy id's are the same on both ends. What is causing the error is the fact that I have tunnel monitor turned on and set to a resource on their end (ex. 172.30.21.5) Their ASA flags an error that they are receiving a ping from 172.30.21.1 to 172.30.21.5. 172.30.21.1 is their gateway addr. I don't know what address is used by the Palo to generate the "tunnel monitor ping" but I would not expect it to be their gateway addr . Since the gateway address is not in the proxy id list the ASA flags it.
IKE Receiver: Packet received on a.b.c.d from 1.2.3.4
IPSEC: Received on ESP packet (SPI=0x1234567,sequence number=0x123444354)from 1.2.3.4(user=1.2.3.4)to a.b.c.d The decapsulate inner packet doesn’t match the negotiated policy in the SA. The packet specifies its destination as 172.30.21.5 its source as 172.30.21.1, and its protocol as icmp. The SA specifies its local proxy as 172.30.21.5/255.255.255.255/ip/0 and its remote_proxy as (the list of agreed ips for our side).
Local:a.b.c.d:500 Remote:1.2.3.4:500 Username 1.2.3.4 IKEv2 Negotiation aborted due to ERROR: Create child exchange failed.
I assume that their gateway is proxing the ping from our end. Don't know how to resolve this. 1) what palo address is used to generate the ping for "tunnel monitoring" 2) is there a setting in the ASA to stop the proxying of the ping?
Thnks for the help
02-26-2021 01:09 PM
When you enable tunnel monitoring the tunnel interface IP is used for the ICMP request to the monitored IP. On the ASA, do you have ICMP inspection enabled at all?
04-16-2021 09:00 AM
We're running into this problem now between a PA-220 and a ASA using IKEv2.
Were you able to identify the problem?
06-09-2021 09:51 AM
I just started this problem between two PA
PA-220 and VM-100
No network changes done,
31st of May ESP_TFC_PADDING_NOT_SUPPORTED in System Log , first event and suddenly customer starts to report the issues with dropping tunnels..
08-22-2022 02:14 PM
Hi,
Does anyone have the solution to the problem?
The same thing is happening to me. 😞
08-24-2022 01:35 AM
Hi @EmilianoMedinaC ,
Are you using IKEv1 or IKEv2 ?
Can you perform some VPN debugging and get some logs to help us further ?
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClivCAC
Best,
-Kiwi.
08-11-2024 10:01 PM
Hello,
We are also facing this problem between two PA-3220 and VM-300.
No network changes done, and both phases are up only.
ESP_TFC_PADDING_NOT_SUPPORTED in System Log , first event and suddenly customer starts to report the issues with dropping tunnels.
Please share any solutions.
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!