Where does the space go? A log collector is deployed with 4 1TB disk pairs. The GUI reports 3.23 TB of total space that can be allocated via quota. Various CLI commands show different values from the GUI. What is going on here? How much space do you actually have for logs?
While configuring firewalls to forward logs to the logging service based on the steps provided in the following document, you might run into an issue where the drop-down for 'Region' is empty and won't display the region on the Panorama and the firewall.
This is a mandatory step in the configuration to enable log forwarding to the logging-service [Step 4] :-
The firewall will show the following error when you attempt to see customerinfo :
lcaas_agent.log for logging-service shows '502 Bad Gateway' error :
To fix this :
You will need to enable the 'Region' on the Panorama CLI using the following command :-
> Login to Panorama CLI > enter configure mode using the command ">configure" > run "set template <template_name> config deviceconfig setting logging logging-service-forwarding enable yes logging-service-regions <region>" > commit
<template_name> is the template the device is part of.
<region> can be americas, europe, etc
> Then, push the changes to the firewall. Verify Device > Setup > Management page to make sure the Region populates correctly.
User-created disk-image/machine-image backups to restore a VM-series firewall instance are not supported across all hypervisors, including public cloud platforms. This includes all functions that allow creating a copy of the disk and memory state of the instance.
To restore a VM-Series firewall, import a backup of the PAN-OS configuration on to a newly deployed VM-series firewall instance from a base image file or from the public cloud marketplace.
Palo Alto Networks firewalls being deployed on AWS and managed by Panorama.
After performing the following steps, the commit fails as a result of an invalid reference to the cert from templates for the decryption policy in DG (Device Group). Cross-references between DG and template are based on common devices being present in both. If changes are made, then commit is expected to fail. At least one device needs to be common.
Note: The firewalls are auto-scaled on an as-needed basis, so they may end up deleting all instances of firewalls at a single point of time.
Add a few firewalls to device group and template, configured a bunch of policies: NAT rules and decryption policy referencing a certificate from a Template.
Commits the changes and pushes them to the devices. Works fine.
Later, due to the auto-scaling all the devices from the device group and template are deleted, after which the user cannot commit to Panorama due to an invalid reference to the cert from Templates for the Decryption policy in DG (Device Group).
Cross-references between DG and template are based on common devices being present in both. If changes are made such that there are no common devices, then commit is expected to fail. At least one device needs to be common in both configs.
We recommend that you create a dummy device in the device group or always have a single firewall instance running, in order to avoid the commit error.
When Aperture analyzes a file, it will first query WildFire to check if the file has been seen before. If not, it will check its WildFire policy to determine whether or not to forward the file to WildFire for malware analysis. When this happens, the WildFire cloud retention policies are still applicable. Note that it is a policy decision in Aperture to forward files to WildFire, not an “always on” function.
For data analysis, access, and exposure controls, Aperture examines files in memory only. What this means is that no customer files are copied to Aperture's storage. When the analysis queue is complete, the compute nodes that analyzed the files are destroyed and the memory is wiped in accordance with AWS data destruction terms and policies. Aperture will retain metadata — information about the files (file size, creator, modification data, etc.), but not the files themselves. Aperture doesn’t currently offer any SLA on how long this this metadata is retained, but currently it is not capped and is held for up to 90 days following termination of service in case service is resumed.
Even though the Palo Alto Networks firewall is not configured with the WildFire feature, it automatically does WildFire public cloud registration when passive DNS monitoring is enabled in the Anti-Spyware profile.
Overview This document describes the CLI commands to verify connectivity to the Wildfire cloud and the status of files being uploaded to it. Details Once the basic configuration is complete, the following command provides the details of the best server selected: > test wildfire registration This test may take a few minutes to finish. Do you want to continue? (y or n) Test wildfire wildfire registration: successful download server list: successful select the best server: va-s1.wildfire.paloaltonetworks.com Note: Do not use PING to test connectivity to the server. Ping requests are disabled on the Wildfire server. Best practice to test connectivity is to Telnet to the server on port 443. To verify, if any files have been forwarded to the server, enter the following command: > show wildfire status Connection info: Wildfire cloud: default cloud Status: Idle Best server: va-s1.wildfire.paloaltonetworks.com Device registered: yes Service route IP address: 192.168.1.1 Signature verification: enable Server selection: enable Through a proxy: no Forwarding info: file size limit (MB): 2 file idle time out (second): 90 total file forwarded: 0 forwarding rate (per minute): 0 concurrent files: 0 The total file forwarded counter will provide the number of files being forwarded to the server. Data filtering logs can be used to check the status of the file. Here are the three actions available: Forward but no wildfire-upload-success or wildfire-upload-skip, means the file is either signed by a trusted file signer, or it is a benign sample that the cloud has already seen. Below is an explanation of the different status possibilities. Forward - Data plane detected a PE (Potentially Executable) file on a WildFire-enabled policy. The PE file is buffered in the management plane. If only forward is displayed for a specific file, it is either signed by a trusted file signer, or it is a benign sample that the cloud has already seen. In either case, no further action is performed on the file, and no further information is sent to the cloud (not even session information is sent for previously seen benign files). There will not be an entry in the WildFire Web portal for these files. To view the count of how many PE files have been checked, found to be clean or uploaded, issue the command: >show wildfire statistics wildfire-upload-success This means that the file wasn't signed by a trusted signer, and the file hasn't yet been seen by the cloud. In this case, the file (and session info) was uploaded to the cloud for analysis. wildfire-upload-skip PAN-OS 5.0: The wildfire-upload-skip message will appear for all files identified and eligible to be sent to WildFire (i.e. they show the forward action), which are not sent because they have already been seen. This includes both benign and malware. You should see a 1-to-1 relationship between forward logs and one of: wildfire-upload-success or wildfire-upload-skip . Either of the two above Wildfire actions, should result in a corresponding report in the WildFire Web portal. See Also Uploading Multiple Files to Wildfire owner: mvenkatesan