|
In some situations, when ESP packets may have large amounts of layer 2 padding, the NP6 IPSec engine may not be able to process them and the session may be blocked.
Normally, The L2 length is equal to the L3 length + length of the L2 header, but the L2 padding's packet will be that the L2 length is larger than the L3 length + length of the L2 header.
A simple example is TCP-ACK. The packet can become a big L2 padding packet. IP length is 20 bytes. L2 length could be 1500 bytes.
The NP6 is in trouble after the padding packet is processed and the FortiGate does not generate the packet.
If an ESP packet with a big padding of layer 2 is injected into the IPSec engine, the IPSec engine will be stuck.
It is straightforward to tell if the PBA has a leak. The 'PBA' value below should never be larger than 3001. If it is, there is a leak.
This is seen when running the following command, where 'x' is the NPU ID (try 0-3): diagnose npu np6 sse-stats x
Example:
From the NP6 drop counter, the IPSEC engine drops have been found:
FW # dia npu np6 dce 0
IHP1_PKTCHK :0000000000000022 [5b] IPSEC0_ENGINB7 :0000000000000901 [87]
IPSEC1_ENGINB0 :0000000000002380 [89] IPSEC1_ENGINB1 :0000000000000321 [8a]
IPSEC1_ENGINB2 :0000000000000009 [8b]
FW # dia npu np6 dce 0
IPSEC0_ENGINB7 :0000000000000026 [87] IPSEC1_ENGINB0 :0000000000000061 [89]
IPSEC1_ENGINB1 :0000000000000005 [8a]
FW # dia npu np6 dce 0
IPSEC0_ENGINB7 :0000000000000028 [87] IPSEC1_ENGINB0 :0000000000000048 [89]
IPSEC1_ENGINB1 :0000000000000002 [8a]
FW # dia npu np6 dce 0
IPSEC0_ENGINB7 :0000000000000018 [87] IPSEC1_ENGINB0 :0000000000000035 [89]
IPSEC1_ENGINB1 :0000000000000006 [8a]
FW # dia npu np6 dce 0
IPSEC0_ENGINB7 :0000000000000035 [87] IPSEC1_ENGINB0 :0000000000000067 [89]
IPSEC1_ENGINB1 :0000000000000009 [8a]
FW # dia npu np6 dce 0
IPSEC0_ENGINB7 :0000000000000023 [87] IPSEC1_ENGINB0 :0000000000000043 [89]
IPSEC1_ENGINB1 :0000000000000003 [8a]
FW# dia npu np6 dce 0
IPSEC0_ENGINB7 :0000000000000028 [87] IPSEC1_ENGINB0 :0000000000000040 [89]
IPSEC1_ENGINB1 :0000000000000003 [8a]
FW# dia npu np6 dce 0
IPSEC1_ENGINB0 :0000000000000002 [89] IPSEC1_ENGINB1 :0000000000000001 [8a]
FW # dia npu np6 dce 0
IPSEC0_ENGINB7 :0000000000000002 [87] IPSEC1_ENGINB0 :0000000000000001 [89]
FW# dia npu np6 dce 0
IPSEC0_ENGINB7 :0000000000000040 [87] IPSEC1_ENGINB0 :0000000000000055 [89]
IPSEC1_ENGINB1 :0000000000000001 [8a]
FW # dia npu np6 dce 0
IPSEC1_ENGINB0 :0000000000000001 [89] IPSEC1_ENGINB1 :0000000000000001 [8a]
FW # dia npu np6 dce 0
IPSEC0_ENGINB7 :0000000000000001 [87] IPSEC1_ENGINB0 :0000000000000002 [89]
FW # dia npu np6 dce 0
IPSEC0_ENGINB7 :0000000000000023 [87] IPSEC1_ENGINB0 :0000000000000042 [89]
The NPU could not handle some packets with special padding directly.
NP6 can strip extra padding in cleartext and ciphertext packets in order to avoid IPsec engine lock-up.
'strip-esp-padding' and 'strip-clear-text-padding' were added for that case.
This traffic goes to another NP module for the padding strip first to make it work.
So it is esp padding case. Configure 'strip-esp-padding' and 'strip-clear-text-padding' enable are needed for npu-offload.
Solution Description:
Re-route the ESP packet into the IP tunnel's module before injecting it into the IPSec engine and then big padding can be removed inside the IP tunnel.
The fix for this issue is enabled by a command line setting, which is disabled by default.
Use the following CLI options to cause the NP6 processor to strip clear text padding and ESP padding before sending the packets to the IPsec engine.
A reboot is required after changing these NP6 settings:
strip-esp-padding enable
strip-clear-text-padding enable
With padding stripped, the session can be processed normally by the IPsec engine.
Check this related article to make these changes:
Technical Tip: VPN (ESP) traffic dropped due to NP6 PBA leak
Recommendations:
To be sure what is happening with VPN communication issues, contact the TAC Support Team to do a complete VPN/ESP troubleshooting.
|
