Management Articles

Featured Article
This article has been deprecated, please follow this link instead: Transition From an Evaluation to a Paid License  
View full article
bfrentz ‎09-19-2018 02:41 PM
1,937 Views
0 Replies
1 Like
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] :-   https://www.paloaltonetworks.com/documentation/10/cloud-services/logging-service-gsg/get-started-with-logging-service/configure-the-firewalls-to-forward-logs-to-the-logging-service#id177S00F0R2G       Logs :   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.    
View full article
ptarra ‎09-12-2018 08:49 AM
2,451 Views
0 Replies
Requirements VM Panorama running on ESXi Panorama running in 'system-mode: panorama'. Check the system mode using either of the following methods: From the CLI, issue the '> show system info' command. From the GUI, check the 'General Information' widget on the Dashboard. PAN-OS 8.0.0 or later   Add interface to VM in Vsphere Log into Vsphere. Right-click the VM Panorama guest and select 'Edit Settings'. In the settings window add a new network device and select the appropriate port group. Click 'OK'. Wait until Vsphere reports that reconfiguring the virtual machine is complete. Reboot Panorama (may be done now, or at the end of the procedure).    Configure interface in Panorama Choose an IP address that is not in use. This example will use 10.8.56.6:   Log into Panorama and click on the Panorama tab. Configure ethernet1/1 under Panorama->Setup->Interfaces:    NOTE: The interfaces will show up in Panorama in the order in which they are added to the VM in ESXi. For example, the second interface added to VM will be presented in Panorama as ethernet1/1. Subsequent interfaces will be presented as ethernet 1/2, ethernet 1/3, etc,             4. Click 'OK'.           5. Ensure the local Panorama is configured as a log collector and is a member of a collector group. It doesn't need to actually be collecting logs but does need to be a member of a collector group. For instructions on configuring a log collector and log collector group, see the Panorama admin guide.             6. Commit to Panorama.           7. Perform a collector group commit.           8. Reboot Panorama if you haven't earlier.    At this point, the interface should respond to the configured services:  
View full article
cstancill ‎08-21-2018 07:54 AM
989 Views
0 Replies
This article can assist you in importing the policies of an existing Palo Alto Networks firewall into Panorama.   Assumptions You have a configuration on your Palo Alto Networks firewall. An instance of Panorama is up and running with the same version of PAN-OS (or higher). You have Web and CLI administrator access to both the firewall and Panorama. The firewall has been configured to connect Panorama in Device > Setup > Management > Panorama Settings The firewall's serial number has been added to Panorama and a Panorama commit has been completed Panorama shows that the firewall is connected in Panorama > Managed Devices Steps On the Panorama, navigate to Panorama > Setup > Operations Click "Import device configuration to Panorama." Select the appropriate device and name the template and Device Group Name accordingly. For each virtual system (vsys) on the firewall, Panorama automatically creates a device group to contain the policy and object configurations. Once you click “OK” the configuration of the firewall will be imported to the Panorama.       Commit locally to Panorama to save the new Device Group and Template created by the import. Push the imported configuration back to the firewall. On the Panorama, navigate to Panorama > Setup > Operations Click on "Export or push device config bundle" Choose either "Push & Commit" or "Export."    Push & Commit. This option will overwrite any local configuration on the firewall with the firewall configuration stored on the Panorama. This will succeed where a normal commit will generate errors associated with objects and rules existing both in Panorama and the firewall. When you choose "Push & Commit" you will see a job triggerred on the Panorama and will see Job Status details as shown below:   Export: This option will export the configuration to the firewall but not load it. You should manually load the configuration from the CLI by running the command "load device-state." Then the configuration should be committed. When you choose "Export" option you will see a job triggered on the Panorama and see details as shown below:   Note:  The above two options,  ("Push & Commit" & "Export")  are available only for firewalls running PAN-OS 6.0.4 and later releases. After this is performed, you should Push to Devices and select the options  "Merge with Device Candidate Config", "Include Device and Network Templates", and "Force Template Values”.     Caveats and important notes: -If you had previously broken a firewall off from Panorama support under Device > Setup > Panorama Settings > Disable Panorama Policy and Objects/Disable Device and Network Template and were now re-importing it into the same or another Panorama, you WILL have to ensure those options are enabled again to receive the Push and Commit or Export. The Push and Commit would delete all local information but leaving the options to Disable Panorama's config will prevent Panorama from giving it any configuration, including management IP and default gateway (so only Console access would be possible at that time.)   -If multiple devices are being imported and then moved to one device group, they MUST be imported into their own new Device Group/Template and follow steps as mentioned above. Only once they are showing properly in their own Device Groups/Templates and have received all configuration pushed from Panorama can you place them into a single Device Group/Template, after which you must Commit locally to Panorama and then Push to Devices while  selecting "Merge with Device Candidate Config", "Include Device and Network Templates", and "Force Template Values”.   -If importing a new device into Panorama via the Import Device Configuration to Panorama option, after adding it's serial number to Panorama's Managed Devices you must ensure it is NOT a part of a Device Group/Template before performing the import, as it will not show as an available device to import the configuration   -When performing the Import, ONLY the Running Config on the firewall is imported. If any changes were made and are only in the Candidate Config (not pushed to the firewall) then they will NOT be imported.
View full article
achalla ‎08-07-2018 05:36 AM
35,066 Views
6 Replies
3 Likes
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?
View full article
cstancill ‎07-30-2018 12:14 PM
2,363 Views
1 Reply
3 Likes
Panorama Management and Logging Overview           The Panorama solution is comprised of two overall functions: Device Management and Log Collection/Reporting. A brief overview of these two main functions follow:   Device Management: This includes activities such as configuration management and deployment, deployment of PAN-OS and content updates. Log Collection: This includes collecting logs from one or multiple firewalls, either to a single Panorama or to a distributed log collection infrastructure. In addition to collecting logs from deployed firewalls, reports can be generated based on that log data whether it resides locally to the Panorama (e.g single M-series or VM appliance) for on a distributed logging infrastructure.   The Panorama solution allows for flexibility in design by assigning these functions to different physical pieces of the management infrastructure. For example: Device management may be performed from a VM Panorama, while the firewalls forward their logs to colocated dedicated log collectors:         In the example above, device management function and reporting are performed on a VM Panorama appliance. There are three log collector groups. Group A, contains two log collectors and receives logs from three standalone firewalls. Group B, consists of a single collector and receives logs from a pair of firewalls in an Active/Passive high availability (HA) configuration. Group C contains two log collectors as well, and receives logs from two HA pairs of firewalls. The number of log collectors in any given location is dependent on a number of factors. The design considerations are covered below. Note: any platform can be a dedicated manager, but only M-Series can be a dedicated log collector.     Log Collection   Managed Devices   While all current Panorama platforms have an upper limit of 1000 devices for management purposes, it is important for Panorama sizing to understand what the incoming log rate will be from all managed devices. To start with, take an inventory of the total firewall appliances that will be managed by Panorama.   Use the following spreadsheet to take an inventory of your devices that need to store logs: MODEL PAN-OS (Major Branch #)  Location Measured Average Log Rate   Ex: 5060    Ex: 6.1.0 Ex: Main Data Center   Ex. 2500 logs/s                                      Logging Requirements   This section will cover the information needed to properly size and deploy Panorama logging infrastructure to support customer requirements. There are three main factors when determining the amount of total storage required and how to allocate that storage via Distributed Log Collectors. These factors are: Log Ingestion Requirements: This is the total number of logs that will be sent per second to the Panorama infrastructure. Log Storage Requirements: This is the timeframe for which the customer needs to retain logs on the management platform. There are different driving factors for this including both policy based and regulatory compliance motivators. Device Location: The physical location of the firewalls can drive the decision to place DLC appliances at remote locations based on WAN bandwidth etc.   Each of these factors are discussed in the sections below:   Log Ingestion Requirements   The aggregate log forwarding rate for managed devices needs to be understood in order to avo id a design where more logs are regularly being sent to Panorama than it can receive, process, and write to disk. The table below outlines the maximum number of logs per second that each hardware platform can forward to Panorama and can be used when designing a soluti on to calculate the maximum number of logs that can be forwarded to Panorama in the customer environment.            Device Log Forwarding Platform  Supported Logs per Second (LPS)  PA-200 250 PA-220 1,200 PA-500 625 PA-820/850 10,000 PA-3000 series 10,000 PA-3220 7,000 PA-3250 15,000 PA-3260 24,000 PA-5050/60 10,000 PA-5220 30,000 PA-5250 55,000 PA-5260 To Be Tested PA-7050/7080 70,000 VM-50 1,250 VM-100/200 2,500 VM-300/1000-HV 8,000 VM-500 8,000 VM-700 10,000                                                             The log ingestion rate on Panorama is influenced by the platform and mode in use (mixed mode verses logger mode). The table below shows the ingestion rates for Panorama on the different available platforms and modes of operation.  The numbers in parenthesis next to VM denote the number of CPUs and Gigabytes of RAM assigned to the VM.              Panorama Log Ingestion Platform  Mixed Dedicated  VM (8/16) 10,000 18,000 M-200 10,000 28,000 M-500 15,000 30,000 M-600 25,000 50,000   The above numbers are all maximum values. In live deployments, the actual log rate is generally some fraction of the supported maximum. Determining actual log rate is heavily dependent on the customer's traffic mix and isn't necessarily tied to throughput. For example, a single offloaded SMB session will show high throughput but only generate one traffic log. Conversely, you can have a smaller throughput comprised of thousands of UDP DNS queries that each generate a separate traffic log. For sizing, a rough correlation can be drawn between connections per second and logs per second.     Methods for Determining Log Rate New Customer: Leverage information from existing customer sources. Many customers have a third party logging solution in place such as Splunk, ArcSight, Qradar, etc. The number of logs sent from their existing firewall solution can pulled from those systems. When using this method, get a log count from the third party solution for a full day and divide by 86,400 (number of seconds in a day). Do this for several days to get an average. Be sure to include both business and non-business days as there is usually a large variance in log rate between the two. Use data from evaluation device. This information can provide a very useful starting point for sizing purposes and, with input from the customer, data can be extrapolated for other sites in the same design.  This method has the advantage of yielding an average over several days. A script (with instructions) to assist with calculating this information can be found is attached to this document. To use, download the file named "ts_lps.zip". Unpack the zip file and reference the README.txt for instructions. If no information is available, use the Device Log Forwarding table above as reference point. This will be the least accurate method for any particular customer. Existing Customer:     For existing customers, we can leverage data gathered from their existing firewalls and log collectors: To check the log rate of a single firewall, download the attached file named "Device.zip", unpack the zip file and reference the README.txt file for instructions. This package will query a single firewall over a specified period of time (you can choose how many samples) and give an average number of logs per second for that period. At minimum this script should be run for 24 consecutive hours on a business day. Running the script for a full week will help capture the cyclical ebb and flow of the network. If the customer does not have a log collector, this process will need to be run against each firewall in the environment. If the customer has a log collector (or log collectors), download the attached file named "lc_lps.zip", unpack the zip file and reference the README.txt file for instructions This package will query the log collector MIB to take a sample of the incoming log rate over a specified period.   Log Storage Requirements   Factors Affecting Log Storage Requirements There are several factors that drive log storage requirements. Most of these requirements are regulatory in nature. Customers may need to meet compliance requirements for HIPAA, PCI, or Sarbanes-Oxely.     PCI DSS requirement 10.7 Sarbanes-Oxley Act, Section 802 HIPAA - § 164.316(b)(2)(i)   There are other governmental and industry standards that may need to be considered. Additionally, some companies have internal requirements. For example: that a certain number of days worth of logs be maintained on the original management platform. Ensure that all of these requirements are addressed with the customer when designing a log storage solution.   Focus is on the minumum number of days worth of logs that needs to be stored. If there is a maximum number of days required (due to regulation or policy), you can set the maximum number of days to keep logs in the quota configuration.   Calculating Required Storage Calculating required storage space based on a given customer's requirements is fairly straight forward process but can be labor intensive when achieving higher degrees of accuracy. With PAN-OS 8.0, the aggregated size of all log types is 500 Bytes. This number accounts for both the logs themselves as well as the associated indices. The Threat database is the data source for Threat logs as well as URL, Wildfire Submissions, and Data Filtering logs.     Note that we may not be the logging solution for long term archival.  In these cases suggest Syslog forwarding for archival purposes.        The equation to determine the storage requirements for particular log type is:   Example: Customer wants to be able to keep 30 days worth of traffic logs with a log rate of 1500 logs per second:             The result of the above calculation accounts for detailed logs only. With default quota settings reserve 60% of the available storage for detailed logs. This means that the calculated number represents 60% of the total storage that will need to be purchased. To calculate the total storage required, devide this number by .60:       Default log quotas for Panorama 8.0 and later are as follows:   Log Type % Storage Detailed Firewall Logs 60 Summary Firewall Logs 30 Infrastructure and Audit Logs 5 Palo Alto Networks Platform Logs .1 3rd Party External Logs .1      The attached worksheet will take into account the default quota on Panorama and provide a total amount of storage required.       Calculating Required Storage For Logging Service   There are three different cases for sizing log collection using the Logging Service. For in depth sizing guidance, refer to Sizing Storage For The Logging Service.   Log collection for Palo Alto Networks Next Generation Firewalls Log collection for GlobalProtect Cloud Service Mobile User Log collection for GlobalProtect Cloud Service Remote Office     Log Collection for Palo Alto Next Generation Firewalls The log sizing methodology for firewalls logging to the Logging Service is the same when sizing for on premise log collectors. The only difference is the size of the log on disk. In the Logging Service, both threat and traffic logs can be calculated using a size of 1500 bytes.    Log Collection for GlobalProtect Cloud Service Mobile User Per user log generation depends heavily on both the type of user as well as the workloads being executed in that environment. On average, 1TB of storage on the Logging Service will provide 30 days retention for 5000 users. An advantage of the logging service is that adding storage is much simpler to do than in a traditional on premise distributed collection environment. This means that if your environment is significantly busier than the average, it is a simple matter to add whatever storage is necessary to meet your retention requirements.   Log Collection for GlobalProtect Cloud Service Remote Office GlobalProtect Cloud Service (GPCS) for remote offices is sold based on bandwidth. While log rate is largely driven by connection rate and traffic mix, in sample enterprise environments log generation occurs at a rate of approximately 1.5 logs per second per megabit of throughput. The attached sizing work sheet uses this rate and takes into account busy/off hours in order to provide an estimated average log rate.           LogDB Storage Quotas   Storage quotas were simplified starting in PAN-OS version 8.0. Detail and summary logs each have their own quota,  regardless of type (traffic/threat):   Log Type Quota (%) Detailed Firewall Logs 60 Summary Firewall Logs 30 Infrastructure and Audit Logs 5 Palo Alto Networks Platform Logs .1 3rd Party External Logs .1 Total 95.2       Device Location The last design consideration for logging infrastructure is location of the firewalls relative to the Panorama platform they are logging to. If the device is separated from Panorama by a low speed network segment (e.g. T1/E1), it is recommended to place a Dedicated Log Collector (DLC) on site with the firewall. This allows log forwarding to be confined to the higher speed LAN segment while allowing Panorama to query the log collector when needed. For reference, the following tables shows bandwidth usage for log forwarding at different log rates. This includes both logs sent to Panorama and the acknowledgement from Panorama to the firewall. Note that for both the 7000 series and 5200 series, logs are compressed during transmission.           Log Forwarding Bandwidth Log Rate (LPS)  Bandwidth Used 1300 8 Mbps 8000 56 Mbps 10000 64 Mbps 16000 52.8 - 140.8 Mbps (96.8)      Log Forwarding Bandwidth - 7000 and 5200 Series Log Rate (LPS)  Bandwidth Used 1300 .6 Mbps 8000 4 Mbps 10000 4.5 Mbps 16000 5 - 10 Mbps           Device Management There are several factors to consider when choosing a platform for a Panorama deployment. Initial factors include: Number of concurrent administrators need to be supported? Does the Customer have VMWare virtualization infrastructure that the security team has access to? Does the customer require dual power supplies? What is the estimated configuration size? Will the device handle log collection as well?   Panorama Virtual Appliance This platform operates as a virtual M-100 and shares the same log ingestion rate. Adding additional resources will allow the virtual Panorama appliance to scale both it's ingestion rate as well as management capabilities. The minimum requirements for a Panorama virtual appliance running 8.0 is 8 vCPUs and 16GB vRAM.           When to choose Virtual Appliance? The customer has large VMWare Infrastructure that the security has access to Customer is using dedicated log collectors and are not in mixed mode When not to choose Virtual Appliance? Server team and Security team are separate and do not want to share Customer has no virtual infrastructure   M-100 Hardware Platform This platform has dedicated hardware and can handle up to concurrent 15 administrators. When in mixed mode, is capable of ingesting 10,000 - 15,000 logs per second. When to choose M-100? The customer needs a dedicated platform, but is very price sensitive Customer is using dedicated log collectors and are not in mixed mode but do not have VM infrastructure When not to choose M-100? If dual power supplies are required Mixed mode with more than 10k log/s or more than 8TB required for log retention Has more than 15 concurrent admins   M-500 Hardware Platform This platform has the highest log ingestion rate, even when in mixed mode. The higher resource availability will handle larger configurations and more concurrent administrators (15-30). Offers dual power supplies, and has a strong growth roadmap. When to choose M-500? The customer needs a dedicated platform, and has a large or growing deployment Customer is using dual mode with more than 10k log/s Customer want to future proof their investments Customer needs a dedicated appliance but has more than 15 concurrent admins Requires dual power supplies When not to choose M-500? If the customer has VM first environment and does not need more than 48 TB of log storage The customer is very price sensitive   High Availability This section will address design considerations when planning for a high availability deployment. Panorama high availability is Active/Passive only and both appliances need to be fully licensed. There are two aspects to high availability when deploying the Panorama solution. These aspects are Device Management and Logging. The two aspects are closely related, but each has specific design and configuration requirements.   Device Management HA: The ability to retain device management capabilities upon the loss of a Panorama device (either an M-series or virtual appliance). Logging HA or Log Redundancy: The ability to retain firewall logs upon the loss of a Panorama device (M-series only).   Device Management HA When deploying the Panorama solution in a high availability design, many customers choose to place HA peers in separate physical locations. From a design perspective, there are two factors to consider when deploying a pair of Panorama appliances in a High Availability configuration. These concerns are network latency and throughput.   Network Latency The latency of intervening network segments affects the control traffic between the HA members. HA related timers can be adjusted to the need of the customer deployment. The maximum recommended value is 1000 ms. Preemption Hold Time: If the Preemptive option is enabled, the Preemption Hold Time is the amount of time the passive device will wait before taking the active role. In this case, both devices are up, and the timer applies to the device with the "Primary" priority. Promotion Hold Time: The promotion hold timer specifies the interval that the Secondary device will wait before assuming the active rote. In this case, there has been a failure of the primary device and this timer applies to the Secondary device. Hello Interval: This timer defines the number of milliseconds between Hello packets to the peer device. Hello packets are used to verify that the peer device is operational. Heartbeat Interval: This timer defines the number of milliseconds between ICMP messages sent to the peer. Heartbeat packets are used to verify that the peer device is reachable. Relation between network latency and Heartbeat interval Because the heartbeat is used to determine reachability of the HA peer, the Heartbeat interval should be set higher than the latency of the link between the HA members.   HA Timer Presets While customers can set their HA timers specifically to suit their environment, Panorama also has two sets of preconfigured timers that the customer can use. These presets cover a majority of customer deployments   Recommended: Timer Setting Preemption Hold TIme 1 Hello Interval 8000 Heartbeat Interval 2000 Monitor Fail Hold Up Time 0 Additional Master Hold Up Time 7000   Aggressive: Timer Setting      Preemption Hold TIme 500 Hello Interval 8000 Heartbeat Interval 1000 Monitor Fail Hold Up Time 0 Additional Master Hold Up Time  5000     Configuration Sync                                                                              HA Sync Process     The HA sync process occurs on Panorama when a change is made to the configuration on one of the members in the HA pair. When a change is made and committed on the Active-Primary, it will send a send a message to the Active-Secondary that the configuration needs to be synchronized. The Active-Secondary will send back an acknowledgement that it is ready. The Active-Primary will then send the configuration to the Active-Secondary. The Active-Secondary will merge the configuration sent by the Active-Primary and enqueue a job to commit the changes. This process must complete within three minutes of the HA-Sync message being sent from the Active-Primary Panorama. The main concern is size of the configuration being sent and the effective throughput of the network segment(s) that separate the HA members.     Log Availability The other piece of the Panorama High Availability solution is providing availability of logs in the event of a hardware failure. There are two methods for achieving this when using a log collector infrastructure (either dedicated or in mixed mode).   Log Redundancy PAN-OS 7.0 and later include an explicit option to write each log to 2 log collectors in the log collector group. By enabling this option, a device sends it's log to it's primary log collector, which then replicates the log to another collector in the same group:     Log duplication ensures that there are two copies of any given log in the log collector group. This is a good option for customers who need to guarantee log availability at all times. Things to consider:   1. The replication only takes place within a log collector group. 2. The overall available storage space is halved (because each log is written twice). 3. Overall Log ingestion rate will be reduced by up to 50%.    Log Buffering Firewalls require an acknowledgement from the Panorama platform that they are forwarding logs to. This means that in the event that the firewall's primary log collector becomes unavailable, the logs will be buffered and sent when the collector comes back online. There are two methods to buffer logs. The first method is to configure separate log collector groups for each log collector:         In this situation, if Log Collector 1 goes down, Firewall A & Firewall B will each store their logs on their own local log partition until the collector is brought back up. The local log partition for current firewall models are:   Model Log Partition Size (GB)  PA-200 2.4 PA-220 32 PA-800 Series 172 PA-3000 Series    90 PA-3200 Series 125 PA-5000 Series 88 PA-5200 Series 1800   The second method is to place multiple log collectors into a group. In this scenario, the firewall can be configured with a priority list so if the primary log collector goes down, the second collector on the list will buffer the logs until all of the collectors in the group know that the primary collector is down at which time, new logs will stop being assigned to the down collector.   In the architecture shown below, Firewall A & Firewall B are configured to send their logs to Log Collector 1 primarily, with Log Collector 2 as a backup. If Log Collector 1 becomes unreachable, the devices will send their logs to Log Collector 2. Collector 2 will buffer logs that are to be stored on Collector 1 until it can pull Collector 1 out of the rotation.     Considerations for Log Collector Group design   There are three primary reasons for configuring log collectors in a group:   Greater log retention is required for a specific firewall (or set of firewalls) than can be provided by a single log collector (to scale retention). Greater ingestion capacity is required for a specific firewall than can be provided by a single log collector (to scale ingestion). Requirement for log redundancy.   When considering the use of log collector groups there are a couple of considerations that need to be addressed at the design stage:   Spread ingestion accross the available collectors: Multiple device forwarding preference lists can be created. This allows ingestion to be handled by multiple collectors in the collector group. For example, preference list 1 will have half of the firewalls and list collector 1 as the primary and collector 2 as the secondary. Preference list 2 will have the remainder of the firewalls and list collector 2 as the primary and collector 1 as the secondary. Latency matters: Network latency between collectors in a log collector group is an important factor in performance. A general design guideline is to keep all collectors that are members of the same group close together. The following table provides an idea of what you can expect at different latancy measurements with redundancy enabled and disabled. In this case, 'Log Delay' is the undesired result of high latency - logs don't show up in the UI until well after they are sent to Panorama.     Inter LC Latency (ms) Log Rate Redundancy enabled Log Delay 50 10K No No 100 5K No No 100 10K No Yes 50 5K Yes No 50 10K Yes Yes 100 5K Yes No 150 3K Yes No 150 5K Yes Yes        Using The Sizing Worksheet      The information that you will need includes desired retention period and average log rate.     Retention Period: Number of days that logs need to be kept. Average Log Rate: The measured or estimated aggregate log rate. Redundancy Required: Check this box if the log redundancy is required. Storage for Detailed Logs: The amount of storage (in Gigabytes) required to meet the retention period for detailed logs. Total Storage Required: The storage (in Gigabytes) to be purchased. This accounts for all logs types at the defualt quota settings.     Example Use Cases                                                        
View full article
cstancill ‎07-12-2018 03:14 PM
93,119 Views
9 Replies
10 Likes
For Panorama 7.0, refer to the Panorama Administrator’s Guide for the procedures to Configure Log Forwarding, Add a Firewall as a Managed Device, and Analyze Log Data for the PA-7050 firewall and other firewall platforms.   Details A PA-7000 series is configured as a Panorama managed device. Panorama will display logs (traffic logs) for the PA-7000 series, even if there is not a "Log Forwarding Profile" defined or configured on any security policy.   The following examples are for traffic observed on Panorama, even though there is not a Log Forwarding Profile on PA-7000 series. Shown below is traffic observed for Rule "ANY" on Panorama for the PA-7000 series:   In the example below, changing context to the PA-7000 series, reveals the Forwarding Profile is not configured on the Security Policy "ANY":   As shown below, the Log Forwarding profile is not configured on the PA-7000 series:   What is observed in Panorama, is a real time running query from the management port on Panorama to the PA-7000 series, which results in displaying the logs.   Note: The logs are physically residing only on the PA-7000 series. This occurs because Panorama cannot handle the rate at which a PA-7000 series would send its logs out of the box, therefore offloading for this platform to Panorama is not supported.   However, the PA-7000 series does support offloading of its logs to syslog, email and SNMP servers. The PA-7000 series has a dedicated Log Processing Card (LPC). Any unused port on any of the NPCs can be defined to be the LPC (Interface Type: Log Card). A data port configured as the type Log Card performs log forwarding for all of the following: Syslog Email SNMP WildFire file forwarding Only one port on the Palo Alto Networks firewall can be configured as a Log Card interface and a commit error is displayed if log forwarding is enabled and there is no interface configured with the Interface Type: "Log Card".   Make sure that the IP assigned to the Log Card Interface can reach the Syslog, Email, SNMP and/or WildFire servers.   Special Note This limitation was overcome with the release of PAN-OS 8.0 For more information please refer to:   https://www.paloaltonetworks.com/documentation/80/pan-os/newfeaturesguide/management-features/pa-7000-series-firewall-log-forwarding-to-panorama   https://live.paloaltonetworks.com/t5/Featured-Articles/PAN-OS-8-0-Forwarding-PA-7000-Logs-to-Panorama/ta-p/132063
View full article
mivaldi ‎07-11-2018 09:58 AM
31,733 Views
6 Replies
2 Likes
How to Register and Activate Eval Panorama Software   The following procedure walks you through the steps to license, download, and install the Panorama management software.   STEP 1 | Register the Panorama Serial # Log in to the Customer Support Portal (https://support.paloaltonetworks.com) and select Assets > Devices > Register New Device.    In the Device Type window, select Register device using Serial Number or Authorization Code and click Submit To activate the Panorama software, enter the Serial Number you received in the “Request for Software Evaluation Approved” email and click Agree and Submit.   After successful registration, your Assets screen should display the newly registered and activated Eval Panorama.     STEP 2 | Download the Panorama software In the navigation menu, click Updates > Software Updates  Click the Filter By: drop down menu and select Panorama Base Images Locate the most recent base image that will be used for your environment and click the corresponding download link       STEP 3 | Install the Panorama software For detailed instructions on installing and configuring the Panorama software, go to  PANW Tech Docs: Panorama Admin Guide: Set up the Panorama Virtual Appliance   STEP 4 | Activate the support license on Panorama Open a web browser and navigate to the management IP address you set for Panorama Login using the factory default credentials of admin/admin for username and password On the Dashboard > General Information section, the Serial # field should say “Unknown”   Go to Panorama > Setup > Management > General Settings. Click the settings wheel and set the proper timezone and current system time. After clicking OK, the screen may freeze. If it does, close that browser tab and bring up a new tab to the Panorama GUI.   Go back to Panorama > Setup > Management > General Settings. Click the settings wheel again to enter the Evaluation Panorama Serial # that you registered on the support portal. Click OK   Click Commit at the top right corner and then Commit to Panorama to commit any pending changes.   Go to Panorama > Support If the Support license is not displayed here, you will need to reboot Panorama for the system to display the license info.   Go to Panorama > Licenses: this screen shouldn’t show any additional feature licenses   Go to Panorama > Dynamic Updates to download the latest Apps & Threats, WildFire, and Antivirus content updates   Go to Panorama > Software to download the latest software version if needed   STEP 5 | Complete the Panorama software configuration
View full article
bfrentz ‎07-03-2018 12:42 PM
9,316 Views
0 Replies
Details Here are some checks that should be made when Panorama is out of sync with one of many managed firewalls, or simply cannot connect to a firewall. Check IP connectivity between the devices. Make sure port 3978 is open and available from the device to Panorama. Make sure that a certificate has been generated or installed on Panorama. Confirm the serial number configured in Panorama (case sensitive). If a permitted IP list is configured for the management interface, make sure that Panorama IP is allowed in the list. By default, it will allow all IPs if a list is not specified. Make sure Panorama is on a version greater than or equal to that of the managed devices. Panorama can manage devices running supported PAN-OS versions of the same or a lower release. Check MTU settings on the managed device, as the value may need to be reduced. If a device on the path is fragmenting packets, communication from Managed Device to Panorama will not succeed. Verify that there is not a large time difference between the clock (Date/Time) on Panorama and the clock (Date/Time) on the managed device.   owner: swhyte
View full article
swhyte ‎05-09-2018 10:26 AM
34,265 Views
8 Replies
2 Likes
Question Why is it that when I use the command >scp export log traffic query start-time equal <time stamp> end-time equal <time stamp> to <location> on a firewall, I can get a CSV file that has more than 1 million lines, but when the command is ran on a Panorama I only get a maximum amount of 65535 lines? Answer The distributed nature of Panorama and PA-7000 platforms makes that a log query will cause several sources to be accessed and potentially terrabytes of data needed to be sifted through to accommodate for the export which could cause performance degradation, as the management plane will be taxed, and network congestion in distributed collector environments. This is why the log export capability is set to a 65535 lines limitation by default for these platforms. The total number of exported lines can be increased to 1 million by setting the max-log-count parameter.   This limitation is not imposed on firewall platforms as they store their logs on a single disk with limited storage capacity, making a large query less resource intensive. Log export on a firewall system is limited to 4 billion lines.   If log needs to be routinely exported off of Panorama, consider Configure Log Forwarding from Panorama to External Destinations
View full article
zsanem ‎12-14-2017 06:45 AM
2,306 Views
0 Replies
The following CLI command will allow you to export the logged data from Panorama: >scp export logdb to username@hostpath   >Note that you need to add a filename.   An example :< > scp export logdb to user@10.192.0.32:/Users/user/filename.tar.gz Password:******* >
View full article
nrice ‎12-13-2017 01:35 AM
5,626 Views
4 Replies
Overview   Device Groups (DG) in Panorama are used to build configurations that are shared among the managed firewalls. Policy and address objects configurations are pushed to the managed firewalls within Device Groups.   At times, the Panorama administrator may need to clone a device group for efficiency and make further edits to customize the device group for a new set of managed firewalls. This task can be performed from the CLI using the method described below.   Important: This process requires an administrator account with ‘superuser’ privileges to run the command and issue a commit.   The command, load configure partial <attributes> , can be used to merge the XML elements from a certain XPath in a Panorama configuration.   Notes: The devices from the original device group will be moved to the new device group. For example, 36-AP-500 is being moved to DG_clone. The new device group's Parent Device Group will be Shared. If it is necessary for it to have the same parent as the original, then go to Panorama > Device Groups > DG_clone and change the Parent Device Group to the correct DG   Details First, the configuration must be imported into Panorama. The configuration can be imported from the web-interface or the CLI. The example below will use the predefined ‘running-config.xml’ file which stores the current running configuration on the Panorama server. Whenever a successful commit is completed in Panorama, the configuration is saved to the ‘running-config.xml’ file.   Following is the snapshot of the Device Group, DG_1, as seen from the web-interface:   The Device Group, DG_1, already exists in the Panorama running-config.xml file. This is the Device Group that will be cloned/duplicated, and the new DG will be named, DG_clone. Run the following command to create DG_clone as a clone of DG_1:   # load config partial from running-config.xml from-xpath /config/devices/entry[@name='localhost.localdomain']/device-group/entry[@name='DG_1'] to-xpath /config/devices/entry[@name='localhost.localdomain']/device-group/entry[@name='DG_clone'] mode merge   Config loaded from running-config.xml   [edit] #   The above command uses 'running-config.xml' as the source configuration and DG_clone for the name of the newly created clone configuration. Enter the appropriate configuration file if different from 'running-config.xml'. The mode used in the command must be specified as ‘merge’ (as seen in the above example).   A new DG with the name, DG_clone, is created after the command above is performed. The following screenshot shows DG_clone in the list of Device Groups:   owner: kadak
View full article
kadak ‎11-15-2017 12:33 PM
9,651 Views
3 Replies
2 Likes
Issue When changing the group ID of a HA configuration from a Panorama template, the following commit error occurs: Mar 12 13:12:19 Error: pan_schema_verify_attribute(pan_schema_types.c:778):attr name failed to verify Mar 12 13:12:19 Error: pan_schema_verify_attr(pan_schema_obj.c:3488): attribute name breaks schema at line 341 Mar 12 13:12:19 Error: pan_cfg_verify_ex(pan_cfg_commit_handler.c:999): invalid confgiuration. Schema verification failed. Mar 12 13:12:19 <line><![CDATA[deviceconfig -> high-availability -> group -> 10 Constraints failed  : Only one HA Group ID allowed Mar 12 13:12:19 Error: pan_jobmgr_process_job(pan_job_mgr.c:2914): error verifying commit candidate Mar 12 13:12:22 Error: pan_cfg_md5sum_by_file(pan_cfg_utils.c:4998): file/opt/pancfg/mgmt/sp/vsys1/pretrans-sp-config.xml doesn't exist Mar 12 13:12:22 Error:pan_cfg_sp_get_shared_policy_info(pan_cfg_shared_policy.c:1606): failed to get md5sum for file /opt/pancfg/mgmt/sp/vsys1/pretrans-sp-config.xml   Resolution :   Steps to be followed on the Managed Firewall :   Log in to the device. Go to Device > Setup > Management. In the Panorama Settings widget, click on "Disable Network Template". In the popup, leave the checkbox blank (so as not to copy the template contents to the local space). Return to the same page and click on “Enable Network Template”. Note: The purpose of steps 1 and 2 are to temporarily free the template contents pushed from Panorama. Go to the High Availability (HA) setup page and set the group id to the desired new value (for example, 10). Note: Each HA group should have its own template so the HA group value is pushed to only that HA pair.   Steps to be followed on the Panorama :     Change the template to have the new group ID and push it again to this device. This causes other template configurations to be recreated on the device. Step 1 caused the template objects to be lost. Make sure that the “Merge with candidate config” is checked, and perform a push just to this device. Now this device has group id 10 and also all the template objects are restored.   owner: kadak
View full article
kadak ‎11-15-2017 12:32 PM
3,590 Views
0 Replies
1 Like
After upgrading PAN-OS to 6.0.x or later in the Panorama appliance and the Log Collector, we’re now unable to see the system log sent from the Log Collector in the Panorama appliance. This scenario seems to occur if the Local Log Collector configuration is deleted before upgrading PAN-OS. Any help?
View full article
TShimizu ‎08-16-2017 03:07 AM
11,008 Views
1 Reply
1 Like
Overview Panorama saves a backup of every committed configuration from each device it manages. In addition, Panorama saves copies of its own committed configurations. To facilitate off-box backup requirements, the system supports a method to regularly export these backups to an external data store. This document describes the steps to back up Panorama.   Steps Managing device backups from the Web UI: To manage device backups on Panorama: Go to Panorama > Managed Devices. Click Manage in the Backups column for a device. This brings up a window showing saved and committed configurations for the device. Click Load to restore the selected configuration to the device. To remove a saved configuration, click .   Managing Panorama Configuration Backups from the GUI Go to Panorama > Setup > Operations. Click “Export named Panorama configuration snapshot” or “Export Panorama configuration version” under the Configuration Management section. Select the configuration from the configuration drop down list in the pop-up window. Click OK.   Manual Export and Import of Panorama Configuration from the CLI On the CLI, the commands below will export the Panorama configuration: > tftp export configuration with the following parameters: remote-port tftp server port source-ip Set source address to specified interface address from from to tftp host   > scp export configuration with the following parameters: remote-por t SSH port number on remote host source-ip Set source address to specified interface address from from to destination (username@host:path)   To import Panorma’s configuration from the CLI, use the following command: > tftp import configuration from 1.2.3.4 file c:/a/b/c   To export Panorama’s entire log database, use the following command: > scp export logdb to   <value>  Destination (username@host:path)   To import a Panorama log database, use the following command: > scp import logdb from userabc@1.2.4.3:c/a/b/c Note:  For LogDBs larger than 2 TB the export will fail. The failure comes from the tarring lack of /tmp space for operation and archiving failure.    owner: swhyte
View full article
nrice ‎08-16-2017 02:53 AM
18,390 Views
5 Replies
1 Like
Issue When the user commits templates from Panorama to the firewall, the following error is encountered:   Template configuration administratively disabled Cause When managing a Palo Alto Networks firewall with Panorama, it is recommended to commit Panorama templates to the device first. This will ensure the existing Panorama policies will work on the newly upgraded firewall. If you receive the above message, this means that templates have not been enabled yet.     Resolution If the user receives this error, enter the Panorama WebGUI and enable Panorama templates: Go to Device > Setup > Management > Panorama Settings Click the "Enable Device and Network Template" button and click OK. Then, click OK on the confirmation window. No commit is needed. From Panorama, commit templates to the firewall Once this is complete, all of the templates will have been updated Proceed with the normal policy commit from Panorama   From CLI Note: The Device and Network Template can also be enabled on the CLI: > set system setting template enable   owner: jdelio
View full article
‎08-08-2017 12:45 PM
5,947 Views
0 Replies
1 Like
Overview Older managed device can be replaced with new device by using a CLI command. Important: Do not add the replacement unit under managed devices.   Steps Perform the following steps from the Panorama CLI. Enter the following command: > replace device old <old SN#> new <new SN#> Go into configuration mode and commit the changes. > configure # commit   On the managed firewall, configure the Panorama IP address (Device > Setup > Management > Panorama Settings) and commit the changes. Note: The device will be in a connected state on Panorama once the new firewall is configured with the Panorama IP address .   owner: tindla
View full article
tindia ‎08-08-2017 02:16 AM
19,991 Views
2 Replies
Procedure applies for PANOS versions  8.0 and below   Scenario Standalone M-500 Panorama in Hybrid mode ( Panorama device management and local Log Collector configured )  faced a hardware issue that requires chassis replacement. The M-500 uses 8 disk pairs for storing the logs received from managed devices. Naming convention Faulty M-500 device to be replaced will be called  "Old-M-500". Newly received replacement device will be called "New-M-500". You can use any name desired in your environment. These names are used for easier understanding of operations in the procedure.   Requirements In order to replace the faulty chassis Old-M-500 we need to have the configuration saved, so that we can import it in the New-M-500. Configuration can be exported by following the procedure in this Live article:. How to Back Up Panorama or by following the administrator manual: Export Panorama and Firewall Configurations The Old-M-500 has 8 disk pairs that will be moved to the New-M-500.   Procedure details 1) Power down the failed M-500 platform - Old-M-500.   Shutdown Panorama Link 2) Configure the New-M-500 in Panorama mode. Import the configuration exported from the faulty device. Import Old-M-500 exported configuration in the New-M-500. Load the named imported configuration into the New-M-500. Modify the Hostname from Old-M-500 to New-M-500.   Commit the configuration to Panorama. 3) Take the Primary disks from Old-M-500 ( A1, B1, C1, D1, E1, F1, G1, H1) and move them to the same Primary positions in New-M-500 ( A1, B1, C1, D1, E1, F1, G1, H1) .   Check M-500 Hardware documentation for correct identification of disks. M-500 Hardware Guide   The picture below shows the physical positioning of the drives inside the M-500 devices.     On New-M-500 we are going to add the Primary Log disks to RAID using CLI commands.  We must use "force" and "no-format" option. Force option associates the disk pair that is previously associated with another Log Collector. The option “no-format” keeps the logs by not formatting the disk storage. In this step we are going to add the Primary log disks only.   Secondary Log Disks will be added towards the end of the procedure. This is done as the Secondary Log Disks are used as data backup and we do not want to use them until the Migration of logs is confirmed.   In our example we have 8 Active RAID pairs ( A, B, C, D, E, F, G, H ). The full list of commands to attach the 8 primary 8 disks is: admin@New-M-500> request system raid add A1 force no-format admin@New-M-500> request system raid add B1 force no-format admin@New-M-500> request system raid add C1 force no-format admin@New-M-500> request system raid add D1 force no-format admin@New-M-500> request system raid add E1 force no-format admin@New-M-500> request system raid add F1 force no-format admin@New-M-500> request system raid add G1 force no-format admin@New-M-500> request system raid add H1 force no-format 4) Check the disk adding status by verifying the status and RAID status:   > show system raid detail Example: Output for 8 primary disks inserted after the adding operation ends: admin@New-M-500> show system raid detail Disk Pair A                           Available    Status                       clean, degraded    Disk id A1                           Present        model        : ST91000640NS            size         : 953869 MB        status       : active sync    Disk id A2                           Missing Disk Pair B                           Available    Status                       clean, degraded    Disk id B1                           Present        model        : ST91000640NS            size         : 953869 MB        status       : active sync    Disk id B2                           Missing .... Disk Pair G                           Available    Status                       clean, degraded    Disk id G1                           Present        model        : ST91000640NS            size         : 953869 MB        status       : active sync    Disk id G2                           Missing Disk Pair H                           Available    Status                       clean, degraded    Disk id H1                           Present        model        : ST91000640NS            size         : 953869 MB        status       : active sync    Disk id H2                           Missing To follow the state of the addition you can check the Management Plane raid.log debug logs through CLI:     >  tail lines 120 mp-log raid.log   This commands shows the last 120 lines that contain all the logs necessary to check the disk operations.   Mar 20 00:01:37 DEBUG: raid_util: argv: ['GetArrayId', 'A1'] Mar 20 00:01:37 DEBUG: raid_util: argv: ['Add', 'A1', 'force', 'no-format', 'verify'] Mar 20 00:01:37 DEBUG: Verifying drive A1 to be added. Mar 20 00:01:37 DEBUG: create_md 1, sdb Mar 20 00:01:38 DEBUG: raid_util: argv: ['Add', 'A1', 'force', 'no-format'] Mar 20 00:01:38 INFO: Adding drive A1 (sdb) Mar 20 00:01:38 DEBUG: create_md 1, sdb Mar 20 00:01:38 DEBUG: create_md_paired_drive 1, sdb, no_format=True Mar 20 00:01:38 DEBUG: Mounting Disk Pair A (/dev/md1) Mar 20 00:01:38 DEBUG: set_drive_pairing_one 1 Mar 20 00:01:38 INFO: New Disk Pair A detected. Mar 20 00:01:38 DEBUG: Created Disk Pair A (/dev/md1) from A1 (/dev/sdb1) Mar 20 00:01:38 INFO: Done Adding drive A1 ... Mar 20 00:02:41 DEBUG: raid_util: argv: ['GetArrayId', 'H1'] Mar 20 00:02:41 DEBUG: raid_util: argv: ['Add', 'H1', 'force', 'no-format', 'verify'] Mar 20 00:02:41 DEBUG: Verifying drive H1 to be added. Mar 20 00:02:41 DEBUG: create_md 8, sdp Mar 20 00:02:41 DEBUG: raid_util: argv: ['Add', 'H1', 'force', 'no-format'] Mar 20 00:02:41 INFO: Adding drive H1 (sdp) Mar 20 00:02:41 DEBUG: create_md 8, sdp Mar 20 00:02:41 DEBUG: create_md_paired_drive 8, sdp, no_format=True Mar 20 00:02:42 DEBUG: Mounting Disk Pair H (/dev/md8) Mar 20 00:02:42 DEBUG: set_drive_pairing_one 8 Mar 20 00:02:42 INFO: New Disk Pair H detected. Mar 20 00:02:42 DEBUG: Created Disk Pair H (/dev/md8) from H1 (/dev/sdp1) Mar 20 00:02:42 INFO: Done Adding drive H1 5)  Next step is to regenerate the Log Disks' Metadata for each RAID disk slot. Note:  This command can take a long time to finish depending on the data size stored on the disks, because the command rebuilds all the log indexes.   > request metadata-regenerate slot 1 > request metadata-regenerate slot 2 > request metadata-regenerate slot 3 > request metadata-regenerate slot 4 > request metadata-regenerate slot 5 > request metadata-regenerate slot 6 > request metadata-regenerate slot 7 > request metadata-regenerate slot 8 Sample Output:   Bringing down vld: vld-0-0 Process 'vld-0-0' executing STOP Removing old metadata from /opt/pancfg/mgmt/vld/vld-0 Process 'vld-0-0' executing START Done generating metadata for LD:1 .... admin@New-M-500> request metadata-regenerate slot 8 Bringing down vld: vld-7-0 Process 'vld-7-0' executing STOP Removing old metadata from /opt/pancfg/mgmt/vld/vld-7 Process 'vld-7-0' executing START Done generating metadata for LD:8 You can check the status of the metadata regeneration by opening a new CLI window and running the command to follow the debug log file vldmgr.log:   > tail lines 100 follow yes mp-log vldmgr.log This commands shows the last 100 lines and then follows the logfile vldmgr.log: Sample output: 2017-03-19 23:38:42.836 -0700 sysd send 'stop LD:1 became unavailable' to 'vld-0-0' vldmgr:vldmgr 2017-03-19 23:38:43.185 -0700 Error:  _process_fd_event(pan_vld_mgr.c:2113): connection failed on fd:13 for cs:vld-0-0 2017-03-19 23:38:43.185 -0700 Sending to MS new status for slot 0, vldid 1280: not online 2017-03-19 23:38:43.185 -0700 setting LD refcount in var:runtime.ld-refcount.LD1 to 0. create:false 2017-03-19 23:38:46.186 -0700 vldmgr vldmgr diskinfo cb from sysd .... 2017-03-20 00:20:56.792 -0700 setting LD refcount in var:runtime.ld-refcount.LD7 to 2. create:false 2017-03-20 00:20:56.792 -0700 Sending to MS new status for slot 6, vldid 1286: online 2017-03-20 00:20:56.905 -0700 connection failed for err 111 with vld-7-0. Will start retry 3 in 2000 2017-03-20 00:20:58.907 -0700 connection failed for err 111 with vld-7-0. Will start retry 4 in 2000 2017-03-20 00:21:00.908 -0700 Connection to vld-7-0 established 2017-03-20 00:21:00.908 -0700 connect(2) succeeded on fd:20 for cs:vld-7-0 2017-03-20 00:21:00.908 -0700 setting LD refcount in var:runtime.ld-refcount.LD8 to 2. create:false 2017-03-20 00:21:00.908 -0700 Sending to MS new status for slot 7, vldid 1287: online 6) On the New-M-500 add a new Local Collector. Click add under Panorama > Managed Collectors to add a new Collector. Under the General tab, enter the serial number of the New-M-500 device that we are moving the disks to. ( Visual example can be found below.  ) We will add the disks to the New-M-500 Log Collector in a later step.   7) Check the status of the new Log Collector. Check for following things in the output of the command: a. Connected status should display “yes” b. Disk capacity should display the correct size c. Disk pair will display as “Disabled” but this is expected behavior at this stage in the RMA process   >  show log-collector serial-number <serial-number-of-New-M-500> Sample output:   > show log-collector serial-number 007307000539 Serial           CID      Hostname           Connected    Config Status    SW Version         IPv4 - IPv6                                                      --------------------------------------------------------------------------------------------------------- 007307000539     0        M-500_LAB          yes          Out of Sync      7.1.7              10.193.81.241 - unknown Redistribution status:       none Last commit-all: commit succeeded, >>>>>>>>current ring version 0<<<<<<<< md5sum  updated at ? Raid disks DiskPair A: Disabled,  Status: Present/Available,  Capacity: 870 GB DiskPair B: Disabled,  Status: Present/Available,  Capacity: 870 GB DiskPair C: Disabled,  Status: Present/Available,  Capacity: 870 GB DiskPair D: Disabled,  Status: Present/Available,  Capacity: 870 GB DiskPair E: Disabled,  Status: Present/Available,  Capacity: 870 GB DiskPair F: Disabled,  Status: Present/Available,  Capacity: 870 GB DiskPair G: Disabled,  Status: Present/Available,  Capacity: 870 GB DiskPair H: Disabled,  Status: Present/Available,  Capacity: 870 GB 8) Add the disks to the New-M-500 Log collector configuration: Panorama > Managed Collectors Click on the name of the Log Collector (Eg. New-M-500) Click on the tab Disks Add all the disks that were moved to the New-M-500 device.  ( Eg. A,B,C,D,E,F,G,H)       9) On New-M-500 add the new Local Log Collector that we have created to the existing Log Collector Group that the Old-M-500 was a part of,  in this example the Old-M-500 log collector was part of the "default" Collector Group. Add the New-M-500 Log collector where the Old-M-500 Log collector was present:       10) Delete the failed Log Collector from the Collector Group. On WebGUI go to Panorama > Collector Group Select the Collector Group name where the New-M-500 is configured. In the Collector Group popup select the tab "Device Log Forwarding". Delete all references of the serial number of the failed Old-M-500.   11) Issue a Panorama Commit only.   12) Issue Commit to Collector Group. 13. Check that the old logs are visible.       14. Add spare disks to RAID, so that we rebuild full RAID redundancy will log migration already confirmed. Physically move disks from Old-M-500  A2, B2, C2, D2, E2, F2, G2, H2  to the New-M-500 A2, B2, C2, D2, E2, F2, G2, H2.   Check that the disks are available to be added to RAID:   > show system raid detail The newly added disks will be in the state "Present" and status "Not in use". admin@New-M-500> show system raid detail Sample Output: Disk Pair A                           Available    Status                       clean, degraded    Disk id A1                           Present        model        : ST91000640NS            size         : 953869 MB        status       : active sync    Disk id A2                           Present        model        : ST91000640NS            size         : 953869 MB        status       : not in use .... Disk Pair H                           Available    Status                       clean, degraded    Disk id H1                           Present        model        : ST91000640NS            size         : 953869 MB        status       : active sync    Disk id H2                           Present        model        : ST91000640NS            size         : 953869 MB        status       : not in use           15. Add the secondary disks (A2,B2,C2,D2,E2,F2,G2,H2) to RAID using the command:   > request system raid add A2 force > request system raid add B2 force > request system raid add C2 force > request system raid add D2 force > request system raid add E2 force > request system raid add F2 force > request system raid add G2 force > request system raid add H2 force   Note:  Executing this command may delete all data on the drive being added. Do you want to continue? (y or n) Press the key "y" to accept. After these commands the RAID goes to "Spare Rebuild" operation.  Please note that this may be a lengthy operation and it will run in the background until it ends. During this time logging to the Log Collector Group will be on hold. Once operation is over the log forwarding to the New-M-500 will resume. You can check the status of the operation running the command: > show system raid detail Sample Output: > show system raid detail Disk Pair A                           Available    Status     clean, degraded, recovering (2% complete)    Disk id A1                           Present        model        : ST91000640NS            size         : 953869 MB        status       : active sync    Disk id A2                           Present        model        : ST91000640NS            size         : 953869 MB        status       : spare rebuilding   .... Disk Pair H                           Available    Status     clean, degraded, recovering (0% complete)    Disk id H1                           Present        model        : ST91000640NS            size         : 953869 MB        status       : active sync    Disk id H2                           Present        model        : ST91000640NS            size         : 953869 MB        status       : spare rebuilding         16. Once the Spare rebuild operation is finished the New-M-500 is in fully operational state and the RMA process is done.
View full article
bbolovan ‎08-07-2017 01:02 AM
7,680 Views
2 Replies
2 Likes
Details If you're experiencing slowness with the Panorama GUI, the first area to look at is the underlying configuration of VMware. The VM host requires a high-speed disk and fast CPUs, preferably on dedicated hardware to ensure that other images aren’t consuming the CPU or I/O channel. Examining the VMware statistics will help determine if any particular resource is being maxed out (disk I/O, Processor, memory, and so on).   Note: A minimum of 4GB RAM and 4 processor cores is required for deployments with up to 10 managed firewalls. For more managed firewalls it is required to have 8 processor cores and 8GB to 16GB or RAM. Check here for more system requirements   Other factors that might cause GUI slowness: Too many log messages being sent to the system. Changes being made while a report is running. More than one administrator commiting changes at the same time. Slowness of the user's computer, or a slow link to Panorama.   See also Panorama Deployment Guide   owner: panagent
View full article
nrice ‎08-07-2017 01:01 AM
10,998 Views
2 Replies
Symptoms After upgrading firewalls from older software release to a new release, Panorama Template or Device Groups may fail to commit.   This is an example of the commit error:  Details: . In VSYS vsys1 from zone Zone-A of type unknown and to zone Zone-B of type unknown are incompatible in security rule Test Rule   Diagnosis The template virtual system does not have a display name to match the display name on the firewall for each vsys, so template push will create a new vsys instead of reusing the existing vsys.   This configuration error is only detected in newer PAN-OS releases. Solution Add display name in the Panorama template virtual system to match the vsys name configured in the firewall.
View full article
shyo ‎08-01-2017 07:56 AM
3,793 Views
0 Replies
If the firewall has local reference made in the interface for zones created in a template and Force Template Values is enabled, these zone configurations in the interfaces would be removed.   Zones are configured in template:       Template does not have any interface configured:     On the firewall, interfaces reference the template zones, and committed:     Do a template push from Panorama with Force Template Values enabled:     Once the commit is complete, the interface zone configurations are removed:     Recommendation    Do not enable Force Template Values if local references to template zone configurations are made. Otherwise, these interface zone references would be wiped out, since they are not in the template.
View full article
jlee1 ‎07-17-2017 01:43 PM
4,424 Views
4 Replies
This article is outdated, please refer to Best Practices for PAN-OS Upgrade   This document shows how to upgrade PAN-OS and Panorama. Major and minor releases introduce new features and fix issues from earlier releases. A maintenance release fixes issues. A major release is indicated by the first digit of the release (for example, 6.0.0), a minor release by the first and second digits (6.1.0) and a maintenance release is indicated by the third digit (6.1.1).   Release type What it offers How to identify Major Features & fixes 6.0.0 Minor Features & fixes 6.1.0 Maintenance Fixes 6.1.1   Note: Always read the release notes before performing an upgrade.   The following procedures are discussed:   Requirements Upgrading to a New PAN-OS Major Release Downgrading Upgrading Panorama Upgrading Devices from Panorama Upgrading HA Pair Downgrading HA Pair Installing an Intermediate Operating System   The Palo Alto Networks firewall or Panorama must be registered with a current support subscription to access the latest PAN-OS software. To register a device and activate subscriptions, go to the Customer Support Portal.   Requirements To upgrade to a new PAN-OS major release, the firewall or Panorama must be running PAN-OS in a feature release immediately preceding it, such as 6.0.x -> 6.1.x. Generally, any version in the earlier release set can be upgraded to the new feature release. As an example, PAN-OS 6.0.5 can be upgraded to PAN-OS 6.1 without downloading later PAN-OS 6.0.x versions. Attempts to upgrade to PAN-OS 6.1 from a PAN-OS 5.0.x version will be blocked. As long as the hardware has support and a working connection to the Internet, the currently supported versions will be listed when the 'Check Now' option is selected in the lower left of the Device > Software page.   Ensure the device or Panorama is connected to a reliable power source, as a loss of power during the upgrade could make the device unusable. Save a backup of the current configuration file by clicking Save named config on the Device tab of the GUI under Setup or the Panorama tab under Setup. Read the Upgrade/Downgrade Procedures in the release notes to determine if there is a minimum content version required in order to perform the upgrade. The PAN-OS base image for the feature release must be downloaded to the device or Panorama before downloading and installing a later version in that release. The base image is the earliest version available and is generally the x.x.0 version. It does not need to be installed on the device, just downloaded before downloading and installing the current PAN-OS version. For example, if upgrading a Palo Alto Networks device from PAN-OS 5.0.8 to 6.1.3: Download but do not install the 6.0.0 base release. Download and install the latest 6.0.x maintenance release, for example 6.0.13, then reboot. Download but do not install the 6.1.0 base release. Download and install the latest 6.1.x maintenance release, for example, 6.1.3, then reboot. Note: After the installation, the Palo Alto Networks device requires a reboot for any new OS to take effect. If upgrading devices from Panorama, perform the upgrade to Panorama first by following the steps under Panorama Upgrade. Following the PAN-OS upgrade, you may need to upgrade associated software. See the Associated Software Versions chart in the release notes to make a determination. Upgrade Steps Go to Device > Software. Click 'Check Now' (lower left) to view the latest software releases available from Palo Alto Networks. Click 'Release Notes' to view a description of the changes in that release. Download and install PAN-OS. Directly from the Web UI: Click Download next to the release to be installed. When the download is complete, a check mark displays in the Downloaded column. Click Install next to the release to initiate the installation. During installation, an option is available to have the device automatically reboot when installation is complete. If the option is enabled, the firewall restarts when the installation is complete. Note: A reboot is not required at this time. However, the new software upgrade will not take effect until the reboot is performed. Manually download the software and install: Navigate to the Palo Alto Networks Support Portal on a web browser. Go to the Software Updates page and download the appropriate PAN-OS release for the designated device. On the Web UI of the device, navigate to Device > Software and click Upload. Browse to locate the downloaded software package, then click OK to upload the file to the device. Click 'Install from File' and select the uploaded file. Click OK to initiate the upgrade. Note: To delete an outdated release, go to Device > Software and click 'X' next to the release. Do not delete the base PAN-OS releases.   Downgrade Steps In the event the device needs to be downgraded, please refer to the following document: How to Downgrade PAN-OS   Panorama Upgrade Inside the Panorama GUI, click the Panorama tab, then the Software tab. Note: Make sure you are not on Panorama > Device Deployment > Software. Click Check Now to retrieve the currently available releases that can be installed. Locate the latest release and download it to Panorama by clicking the Download link in the row corresponding to that release. (If using VMware ESX, choose that image.) After downloading, click the 'Install' link to perform the upgrade and reboot when prompted.  Upgrading Devices from Panorama Browse to the Panorama tab, click Device Deployment > Software and click 'Check Now' for the latest PAN-OS versions available. Click Download to download the appropriate software for the device type to be upgraded. The Platforms list displays. The same rules for the software versions apply, as stated above. After the correct image is downloaded, click Install, then select the device where you want to install the software. Notice the options at the bottom to 'Upload only to device (do not install)' and 'Reboot device after install.'  3. There is another way to install the software on a managed device by going to Panorama > Managed Devices. Select the 'Install' option at the bottom.       When you click the 'install' option, you will be directed to the same install page as in the above step.     Upgrading HA Pair For information on upgrading an HA pair of firewalls, refer to the following document: How to Upgrade a High Availability (HA) Pair   Downgrading HA Pair To fall back before upgrading the second device: Suspend the upgraded device. The passive device then becomes active and the suspended unit can be downgraded. Follow the procedures here: How to Downgrade PAN-OS After the downgrade completes, make sure the unit is active in the GUI to enable the admin to load up a shared configuration.   Installing an Intermediate Operating System Sometimes an upgrade path requires installing an intermediate operating system to reach the final intended operating system, for example, to upgrade from 6.0 to 7.0, first install 6.1.   We recommend installing the latest maintenance release version available in the intermediate release to prevent issues during the upgrade process, for example, 6.0.5 to 6.1.13 to 7.0.6.   See also How to Downgrade PAN-OS How to Upgrade a High Availability (HA) Pair How to Downgrade PAN-OS   owner: jdelio
View full article
nrice ‎07-12-2017 03:28 AM
94,223 Views
12 Replies
3 Likes
Overview This document describes how to create an admin role in Palo Alto Networks Panorama and push this role to managed devices. The example screenshots below represent a Panorama and devices running PAN-OS 8.0.x but also applies to previous and later versions   Steps Under Panorama > Templates, create a template group and add the desired devices. Under Device > Admin Roles, select the new template from the "Template" drop-down list and create a new admin role for the template group. Click commit and select Panorama to simply save the changes to Panorama, if you want to continue preparing other configuration parts Hit commit again and select the Commit and Push option to choose your group and device once you are ready to save your configuration to Panorama and commit the changes to the firewalls Once the commit is complete your admin role will exist on the device    
View full article
jteetsel ‎07-05-2017 06:16 AM
3,069 Views
0 Replies
The Article is in reference to another customer-facing article which talks about the Panorama Certificate Expiration. https://live.paloaltonetworks.com/t5/General-Topics/Panorama-Certificate-Expiration-on-June-16-2017/m-p/150948/highlight/true#M50050    The two options to mitigate this issue is following:   Option 1: Upgrade software on Panorama and all log collectors to the maintenance releases listed below:   Panorama / log collector version 7.1.9 Panorama / log collector version 7.0.15 Panorama / log collector version 6.1.17   Option 2: Update the content on Panorama and all log collectors to content version 700 or later:   However, once you have used any one of the option to upgrade the certificate, please follow the following steps to verify that the certificate validity is extended.     Chrome Browser:   1. Open Chrome Browser and type "https://<mgmt ip of Panorama>:3978" and Click Enter. 2. At this point the Panorama will ask for mutual authentication and the web browser will present all the certificates present in its Personal Store, so click Cancel. 3. The connection will show "Not Secure" so press F12 in order to inspect the certificate. (cmd+opt+i on a Mac) 4. Navigate from Elements to Security tab. 5. Click "View Certificate" 6. Once the certificate opens, please navigate to "Certification Path" 7. The Panorama server certificate is signed by the Root CA "localhost" - This is the certificate that was expiring on June 16th. We need top verify if the validity of this certificate is extended or not. 8. Click "localhost" certificate and then click "view Certificate" 9. Notice the validity of Root Certifiacte is extended.      
View full article
zimtiaz ‎06-22-2017 04:11 PM
2,875 Views
0 Replies
1 Like
  Panorama can only be configured for one of the URL DBs (BrightCloud or PAN-DB). However, Panorama includes support for auto-migration of URL categories between non-matching vendors when pushing policies to managed devices.   When a mismatch is detected between the URL DB configured on Panorama and URL DB configured on the managed device, the device can convert the URL profiles and categories to match its URL Filtering vendor. The conversion/migration will take into account that a single category can translate into multiple categories and vice versa. For the category mapping, see: BrightCloud to PAN-DB Category Mapping     owner: sjanita
View full article
panagent ‎05-10-2017 06:24 AM
9,002 Views
4 Replies
The following links are provided to show you the steps needed to recover the logs from a failed M-100 Log Collector.   PAN-OS 6.1 Recover-logs-after-failure-rma-of-m-100-appliance-in-panorama-mode   PAN-OS 7.0 Recover-logs-after-panorama-failure-rma-in-non-ha-deployments   PAN-OS 7.1 Migrate-log-collectors-after-failure-rma-of-non-ha-panorama   PAN-OS 8.0 Migrate-log-collectors-after-failure-rma-of-non-ha-panorama     See Also How to Determine and Replace Failed Raid Drives in M-100   owner:ksomu
View full article
sesco ‎05-08-2017 02:28 PM
7,716 Views
0 Replies
Question When are new configuration versions added to Committed Configurations list under Manage Backups for Managed Devices in Panorama?         Answer New configurations are added to the list only when local firewall configuration is changed. This should not happen if configuration was pushed from Panorama. However, if there were uncommitted changes on the Firewall, either made by user or changes made in the candidate-config.xml due to content update or similar operation, after commit or commit-all (pushed from Panorama), Firewall will send its configuration to Panorama and this configuration will be added as a new configuration version under under Committed Configurations.
View full article
nkajgana ‎04-24-2017 03:29 AM
2,335 Views
0 Replies
Details:   Consider following the device group configuration on Panorama:     Currently, the DG3 device-group has a parent-DG as "Shared" and we want to set DG2 as the parent-DG for DG3. We would have to run the following command from CLI, and then commit the changes on Panorama:   > request move-dg <device group to be moved> new-parent-dg <new parent device group> > configure # commit            
View full article
poagrawal ‎04-05-2017 07:31 AM
2,186 Views
2 Replies
2 Likes
Details By default, the Panorama Virtual Machine template provided by Palo Alto Networks firewall comes configured with a single disk, which hosts both the operating system and the logs collected from the associated firewalls. Shown below is an example of the VM configuration:   The following screenshot is an example of system disk-partition and disk-space:   The default disk provides 10 GB's of storage. If more storage is needed, a custom virtual disk can be attached to the VM and it will be used as dedicated log disk. Note: The maximum disk size is 2 TB's. With 8.0 the maximum size increases. For more info please see Panorama 8.0 admin guide    Disk type needs to be SCSI, and the recommended VMWare disk provisioning is Thick Provision Lazy Zeroed, as shown in the example below:   After rebooting Panorama, the new partition and log disk size is visible by using the following CLI commands: > show system disk-space > show system disk-partition   Important notes: The total space allocated for log storage is the size of the attached virtual disk. For example, if attaching a 100GB disk the total log size will be 100 GB. Attach only one log disk to Panorama VM. If other disks are attached, they will be ignored. With 8.0 the behavior is different. Please see Panorama 8.0 admin guide Up until 8.0 disk size cannot be extended by modifying the disk size. If the disk size is modified, the allocated log database size remains the same as before. The actual disk size will be increased, but the partition size will not be increased by Panorama VM.   owner: bbolovan
View full article
bbolovan ‎03-23-2017 10:10 AM
9,916 Views
5 Replies
3 Likes
Question Are there any special considerations when importing the firewall configurations from an HA pair into Panorama? Answer Yes, there are many considerations  that you need to be aware of.   By default, Panorama will create a new device group and a new template when the first firewall's configuration is imported. When importing the second firewall's configuration, it too will require its own template, but it can be associated with the same device group as the first firewall.   SPECIAL NOTE The High-Availability configuration is part of the template and if both firewalls are associated with the same template, then they will both have the same HA configuration and in turn both members will try to become active when turned on. Be sure to double check the templates to avoid this happening.   For guidance on how to import a firewall's configuration into Panorama, please reference:  How to Perform a Device Config Import into Panorama
View full article
jjosephs ‎03-07-2017 09:33 AM
6,476 Views
7 Replies