This Nominated Discussion Article is based on the post "Action=Allow while NATDestinationIP=0.0.0.0" by @JuanLondono1  and answered by @BPry .   Hello,   I am not a firewall administrator I am an analyst who reports alerts on suspicious behavior based on indicators of compromise matches, mostly related to ransomware and IP addresses with bad reputation.   I have a big doubt because I always generate the alerts from the SIEM starting from the Action=allow field but I have noticed as you can see in the image that there are fields like "NATDestinationIP=0.0.0.0", "Application=incomplete", "SessionEndReason" or that simply from that malicious source Zero bytes were received. Is it a false positive to report an Action=allow and NATDestinationIP=0.0.0.0? or is it something for the firewall administrators to check anyway? Remember that I am not a firewall administrator nor an expert on them, I would appreciate your opinion in the clearest and least technical way possible.   Thanks         The NATDestinationIP being 0.0.0.0 just means NAT isn't being applied, it shouldn't be utilized as any sort of guidance as far as whether something is a false-positive or not. The example that you provide simply indicates that the source IP was attempting to reach endpoints in your network that are public facing, but everything was either denied or it didn't receive any sort of response from the endpoint.   It seems likely from the logs that you've shared that you simply receive session-start and session-end logs and that there's an external security rule base entry that utilizes app-id that's set to service any. Not a best practice for external connections, but sometimes best practice and the real world don't match.     

This Nominated Discussion Article is based on the post "B2B VPN IKEv2 Fail with Amazon Private Cloud Peer" by @pnelson which he answered himself.  Thanks for sharing your experience with the community !   Setting up a VPN with a vendor. It came up the first time and test data was passed. It was a couple of weeks after testing before the tunnel would actually be used. When that time came we could not get the tunnel up. IKEv2 fails. I know nothing changed on my end and the vendor makes the same claim. The vendor is using Amazon virtual private cloud firewall. I am using an on-prem PA-3250 HA pair (active/passive) inside of my Internet perimeter with 96 perfectly happy B2B VPNs running. We have tried everything to get the tunnel back up including tearing down the config on both peers and rebuilding from scratch, my side using a new tunnel interface.   The vendor has to initiate the tunnel as the tunneled host on my side only sends stateful replies, the vendor always sends the SYN, so my side is always the IKEv2 responder.   The IKEv2 initiator request comes in and my side responds. SPIs are established so we have peer-to-peer communication. No issues with NAT-T.   I have attached a packet capture of an IKEv2 exchange (4 packets) and a system log of the failure (2 lines). Digging into the packets I see key exchange and it looks like the Phase 1 proposal is correct. Would someone take a look and educate me on what I'm missing?   I think I have found the issue. The initiating peer has an incorrect peer ID for my side (responder) as revealed by CLI 'less mp-log ikemgr.log'. It gives more detail than the GUI system log. My vendor counterpart is on the other side of the globe so I'm not sure when he will be attempting the correction.   This issue has been resolved. On my side I had to set the local peer ID to my firewall interface's public NAT address, not the native address. IKEv2 still wouldn't come up so the vendor changed his proposal from being specific to throwing many combinations my way. After that Phase 1 & Phase 2 came up instantly.  

This Nominated Discussion Article is based on the post "Test command does not work".

You can use debug filters to enable the Palo Alto Networks firewall to collect packet captures for troubleshooting purposes.  

This Nominated Discussion Article is based on the post "Bring Down IPsec Tunnel Manually" by @j.nepomuceno and responded to by @TomYoung and @Raido_Rattameister . Read on to see the discussion and solution!     I am troubleshooting an issue where I need to bring down the IPsec tunnel manually, what is the best way to do this in GUI or CLI? Thanks   Depending on whether you want to bounce the tunnel or actually disable it, you have different options.   The following CLI commands will tear down the VPN tunnel (phase1 & phase2 respectively): Phase 1 > clear vpn ike-sa gateway <gw-name>​ Phase 2 > clear vpn ipsec-sa tunnel <tunnel-name>​   Follow these steps to clear (bounce) a tunnel using the GUI: Phase 1 Goto Network > IPsec tunnels and select your tunnel Click IKE-Info At the bottom, click the action you want (Refresh or Restart)   Phase 2 Goto Network > IPsec tunnels and select your tunnel Click Tunnel-Info At the bottom, click the action you want (Refresh or Restart)   Instead of bouncing, you can also choose to disable/enable IKE gateways or IPsec tunnels.   Enable/Disable an IKE Gateway Go to Network  > Network Profiles > IKE Gateways and select the gateway in question.   Click Enable/Disable at the bottom of the screen   Enable/Disable an IPsec tunnel Go to Network  > IPSec Tunnels and select the tunnel in question Click Enable/Disable at the bottom of the screen   For more information: Refresh or Restart an IKE Gateway or IPSec Tunnel How to check Status, Clear, Restore, and Monitor an IPSEC VPN Tunnel Enable or Disable an IKE Gateway or IPSec Tunnel How to Troubleshoot IPSec VPN connectivity issues