- Products
- Learn
- Local User Groups
- Partners
-
More
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
IDC Spotlight -
Uplevel The SOC
Important! R80 and R80.10
End Of Support around the corner (May 2021)
Hi all,
Hi to all, anyone familiar with this drop (fw ctl zdebug + drop)
When I ping thru VPN s2s I get latency on the traffic (around 360ms on each ping)
On #fw ctl zdebug + drop is see this drop continually.
;[cpu_1];[fw4_0];update_narrowed_mspi_on_enc_opaque: Connection <dir 1, 192.168.1.1:2 -> 172.16.20.10:0 IPP 1> does not have an opaque;
anyone is familiar with this?
Thank you.
Hi @Pavel88,
MSPI is a tunnel identifier. It is a local counter that uniquely identifies a tunnel on the given machine. MSPI is an index to the MSA (Meta SA), which contains fields common to all SAs with the same peer, methods, and IDs. When a new IPsec tunnel is established, a new MSPI is created by it, and it gets the next free MSPI number. The MSPI counter is then increased.
I think there is something incorrect with the MSPI update in the encryption process.
I would open a TAC case.
Hi @Pavel88,
MSPI is a tunnel identifier. It is a local counter that uniquely identifies a tunnel on the given machine. MSPI is an index to the MSA (Meta SA), which contains fields common to all SAs with the same peer, methods, and IDs. When a new IPsec tunnel is established, a new MSPI is created by it, and it gets the next free MSPI number. The MSPI counter is then increased.
I think there is something incorrect with the MSPI update in the encryption process.
I would open a TAC case.
Open a TAC case, this is a clear support issue
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY