ESP TFC PADDING NOT SUPPORTED
5612
Created On 02/16/23 22:21 PM - Last Modified 04/17/26 01:19 AM
Symptom
- Ikemgr logs report "received notify type ESP_TFC_PADDING_NOT_SUPPORTED"
- VPN tunnel is working without issues.
00:26:38.108 -0600 [PWRN]: { 3: }: x.y.z.34[500] - a.b.c.13[500]:0x555555a5a060 vendor id payload ignored
00:26:38.108 -0600 [PWRN]: { 3: }: x.y.z.34[500] - a.b.c.13[500]]:0x555555a5a060 received notify type ESP_TFC_PADDING_NOT_SUPPORTED
00:26:38.108 -0600 [PWRN]: { 3: }: x.y.z.34[500] - a.b.c.13[500]:0x555555a5a060 received notify type NON_FIRST_FRAGMENTS_ALSO
00:26:38.108 -0600 [INFO]: { 3: }: x.y.z.34[500] - a.b.c.13[500]:0x7fffd00625c0 authentication result: successEnvironment
- Palo Alto Firewall.
- Supported PAN-OS.
- IPSec VPN.
Cause
PAN-OS does not support Traffic Flow Confidentiality (TFC) in ESP.
Resolution
Log Message Explanation:
The log message "Received notify type ESP_TFC_PADDING_NOT_SUPPORTED" indicates that the Palo Alto Networks firewall has received a notification from the IPsec VPN peer stating that ESP Traffic Flow Confidentiality (TFC) padding is not supported.
Background & Fix in PAN-OS 8.1.6:
- Initially, the firewall did not support ESP TFC padding but failed to notify peers, causing some to continue sending TFC-padded packets, which were then dropped.
- This issue was fixed in PAN-OS 8.1.6, where the firewall was updated to always send the ESP_TFC_PADDING_NOT_SUPPORTED notification to peers, regardless of whether it was the initiator or responder.
- If the peer follows RFC standards, it should stop sending TFC-padded packets upon receiving this notification.
- Since the firewall does not support ESP TFC padding, receiving this notification from a peer has no operational impact.
Context & Implications:
- TFC padding is an optional IPsec feature that adds random padding to ESP packets to obscure traffic patterns.
- PA firewalls will always send the ESP_TFC_PADDING_NOT_SUPPORTED notification to peers. This will not trigger any log messages.
- Peer firewalls may also send the notification to Palo Alto Networks firewall, which will trigger a log message, just like any other received notify payload.
- If both sides send the notification, the expectation is that no ESP packets will be transmitted with TFC padding from either side.
- PA firewalls still do not support TFC padding as of version 12.1, so there will be no change in behavior on the PA device.
- To reiterate, this is an expected and benign log message, not an error. It simply indicates that both firewalls will not be sending ESP TFC padded packets, which is perfectly normal.
- The message seen in the log, is not an error and is unrelated to any tunnel failure symptoms they may be observing.
Additional Information
Definitions from https://datatracker.ietf.org/doc/html/rfc5996:
- The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the sending endpoint will not accept packets that contain Traffic Flow Confidentiality (TFC) padding over the Child SA being negotiated.
- If neither endpoint accepts TFC padding, this notification is included in both the request and the response.
- If this notification is included in only one of the messages, TFC padding can still be sent in the other direction
Note:
- The design of TFC is such that some devices will not have problems processing the packets even though they do not support it.
- However, PAN-OS being a security OS has additional built-in checks on the size of packets.
- One of such checks expectedly fails to result in packets getting dropped.
- NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1 simply as "Used for fragmentation control. See [RFC4301] for an explanation.
- [RFC4301] says "Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port (or ICMP type/code or MH type) selectors MUST notify a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.
- The peer MUST reject this proposal if it will not accept non-initial fragments in this context. If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA."