ESP_TFC_PADDING_NOT_SUPPORTED

cancel
Showing results for 
Search instead for 
Did you mean: 

ESP_TFC_PADDING_NOT_SUPPORTED

L2 Linker

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

 

 

 

6 REPLIES 6

L7 Applicator

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

Tom Piens
Like my answer? check out my book! https://bit.ly/MasteringPAN

L7 Applicator

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

 

 

Tom Piens
Like my answer? check out my book! https://bit.ly/MasteringPAN

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

 

@vnt90,

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? 

L1 Bithead

We're running into this problem now between a PA-220 and a ASA using IKEv2. 

 

Were you able to identify the problem?

L1 Bithead

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..

 

 

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!