Why should tunnel monitoring be considered when there is already a predefined tunnel status report available in Prisma Access?

[AkashThangavel]

Hi team,

Why should tunnel monitoring be considered when there is already a predefined tunnel status report available in Prisma Access?

The setup is already predefined; you just need to input the respective email IDs to ensure the timely delivery of the reports.

Tunnel monitoring aims to generate critical logs, a task that is already accomplished through the use of these predefined alert codes.

Please distinguish this variation

regards,

Akash Thangavel

Network Security Engineer

[aleksandar.astardzhiev]

Hi @AkashThangavel ,

Please note that I don't have any experience with Prisma Access, but I can make an educated guess:"

- I would assume Prisma Access "Tunnel Monitoring" to work exactly the same way as self-hosted/managed Palo Alto firewall. When tunnel monitor is enabled, firewall will generate ping probe packets to the destination IP, and if there is no reply firewall will consider this tunnel as down, even if the IPsec SA (phase1 and phase2) are actually still up. One of the use case of such monitor is to "disable" any static or policy based routes associated with that tunnel and failover the traffic to redundant path. Another benefit is that the constant ping will keep the tunnel up even if there is no actual traffic, which is equivalent to "aways-up" for the VPN tunnel.

- While the email alert will only indicate that the tunnel is down and most importantly to trigger such alert, IPsec SAs needs to be down (no phase1 or phase2).

You  are correct that both can triggers an alert event indicating issues with the tunnel, but tunnel monitor take a step further by verifying of the layer3 path over that tunnel is indeed working and provide a way to dynamically switch to redundant path (if you have such in your setup).