Overview

How It Works

• The Security Processing VM instances powering the Cloud NGFW for Azure resource initiate an SSL connection to Panorama.
• Once established, this SSL tunnel is used for dynamic content downloads, policy pushes, and log collection.
• The Security Processing VM instances determine whether the Panorama IP is private or public (based on RFC-1918) and route the connection from the CIDRs associated with the corresponding subnet (private or public) you delegated to the Cloud NGFW for Azure resource.
• From Panorama's perspective, these are inbound connections. Panorama simply needs to allow inbound traffic from the CIDRs associated with the subnets you delegated to your Cloud NGFW for Azure resources.

Requirements for Healthy Connectivity

• Panorama Software: Version 11.2.7-h4 (recommended) or 11.x or later (required for configuration pruning and Zone-Mapping).
• Azure Plugin: Version 5.2.3 or later (required to enable Cloud Device Groups and registration string generation).
• VNet Configuration: The VNet must have at least two subnets (public and private). A CIDR of /10 is recommended to support auto-scaling.
• Port Access: Port 3978 must be open to allow inbound SSL management traffic to Panorama.

Troubleshooting Workflow

1. Identify the Symptom
   Check the Health Status of the Cloud NGFW for Azure resource in the Azure portal. Look for these common failure indicators:
   • Health Status shows Unhealthy or Degraded with the reason Cloud NGFW for Azure resource cannot register to Panorama.

   • No traffic from the Cloud NGFW IP appears on the Panorama console.

   • The Cloud NGFW for Azure resource is missing under Manage Devices in Panorama.
2. Address Not Applicable Status
   If the status reads Not Applicable, the Security Processing VM instances are likely still initiating. Wait for the deployment to finish. If it remains stuck indefinitely, perform a fresh deployment, as the Security Processing VM instances may have failed to provision fully.
3. Resolve Unhealthy Status (Connectivity Checks)
   If the status is Unhealthy, verify the underlying network path:
   • Port Verification: Confirm port 3978 is open.
   • Allowlisting: At the Panorama end, ensure you allowlist the CIDRs associated with the subnets (private or public) you delegate to the Cloud NGFW for Azure resource.
   • SNAT Configuration: In the Azure portal under Networking & NATSource NAT, ensure Use the above public IP addresses is selected.
   • VPN/Gateway Routing: For on-premises Panorama access via VPN, verify the VPN gateway is active and the hub VNet has a route pointing to the Panorama private IP.
4. Resolve Asymmetric Routing Issues
   Asymmetric routing occurs when return traffic from Panorama fails to reach the specific Security Processing VM instance that initiated the connection. To fix this:
   • Verify Routing Table: Look for missing User Defined Routes (UDR) in the Azure default routing table.
   • Apply UDR Host Routes: Create UDR host routes pointing to the Cloud NGFW for Azure resource for the Cloud NGFW DNAT IP addresses.
   • Direct Return Path: Define a UDR rule for the CIDRs associated with the private subnet you delegated to the Cloud NGFW for Azure resource. Set the next hop as Virtual Network to ensure return packets bypass the Internal Load Balancer (ILB) and go directly back to the source device.
5. New Validation
   Once routing and configuration issues are fixed:
   • The Cloud NGFW for Azure resource Health Status changes to Healthy in the Azure portal.
   • The device appears as connected under Panorama's Manage Devices.

Architectural Topologies for Panorama Connectivity

• Private Connectivity: The Cloud NGFW for Azure resource uses the CIDRs associated with the private subnet you delegated to it to connect to Panorama's private IP via VNet Peering, VPN, or VWAN. Test reachability by deploying a test VM in your VNet private subnet and pinging the Panorama private IP.
• Public Connectivity: If the private subnet lacks access to Panorama, the Cloud NGFW for Azure resource uses its public data interface (using the Cloud NGFW public IP) to connect to Panorama's public IP. Test reachability by deploying a test VM in the public subnet.

• Same VNet: The Security Processing VM instances can directly reach the Panorama private IP since they share the same VNet.
• Peered VNets: The Security Processing VM instances can directly reach the Panorama private IP across the VNet peering connection.

• Same VNet as VPN Gateway: The Cloud NGFW for Azure resource uses the CIDRs associated with the private subnet you delegated to it to access the Panorama private IP via the VPN connection. Configure the Virtual network gateway or Route Server in the Azure portal's VPN peerings page.
• Peered Hub VNet: The connection flows from the CIDRs associated with the private subnet you delegated to the Cloud NGFW for Azure resource, through VNet Peering to the Hub VNet, then via VPN to the on-premises network.