on 10-12-201811:47 AM - last edited on 12-13-201802:10 PM by ploera
Read about best practices for support escalation, threat IDs for PAN-OS, and a new App-ID placeholder. Palo Alto Networks Live Community also dives into how to search Live Community from Google, a URL bulk categorization script, PAN-OS 8.1 metrics with 8.0 firewalls, and firewalls enacting TCP reuse.
Best Practices for Support Escalation
There are times when you may need to escalate a Support ticket and there may be a variety of reasons for doing so. As a reminder, you have several options before requesting a formal ticket escalation. Here are the options you have at your disposal:
Change the priority of the ticket. Many times, the priority is left at the default of “medium” when opening a Support case. Each priority level has its own SLA in terms of when contact is made by Support.
Severity 4/Low: 8 business hours for initial response – does not impact customer business
Severity 3/Medium: 4 business hours for initial response – production not effected
Severity 2/High: 2 business hours for initial response – production is up but impacted
Severity 1/Critical: 1 business hour for initial response – productivity is down
Re-assign the ticket. This is helpful when you may be working with a Support Engineer (SE) in a vastly different time zone making it difficult to proceed at a quick pace. Simply call into Support with your case number and ask to be re-assigned to a Support Engineer closer to your time zone or to an engineer more versed with your particular issue/product.
Contact the Duty Manager. At the bottom of every email from your Support Engineer, you should see the Duty Manager's contact information. If for some reason this info is not present, you can call into Support and ask for the Duty Manager. The manager on duty can assist with a variety of issues from case re-assignment to getting tier-3 involved as necessary.
Formal escalation. This is where you get your local SE involved. Your SE will review the case history and have a conversation with you to fully understand the situation. If agreeable, the SE will proceed with a formal escalation request. Note, this may require resources on your end to be available to work with Support “around the clock” until the issue is resolved.
New App-ID Placeholder on October 16th
The Application and Threat Content release of October 16th will have a placeholder App-ID for Cisco SXP (Security Group Tag/SGT Exchange Protocol). This is one of several protocols that supports Cisco TrustSec. The placeholder App-ID will be labeled "cisco-sxp" and will not be activated until November 13th. Currently, Cisco SXP traffic is identified as unknown-tcp. The placeholder will allow you to implement the App-ID ahead of time within your security policies in preparation for the November activation. If you have Cisco SXP traffic traversing your Palo Alto Networks firewall and do not make the policy preparations, this traffic will likely end up match interzone-deny and get dropped. See this article for more information.
Storage of Threat IDs for PAN-OS 6.1 and 7.0 Releases
If you have any firewalls on PAN-OS versions 6.1 or 7.0, note that you will need to upgrade from these releases before October 25th. PAN-OS 6.1 will reach the end of life on October 25th, and PAN-OS 7.0 was at end of life last December, so you should already have either upgraded or have plans to upgrade very soon. It is recommended for both of these releases to be upgraded to PAN-OS 7.1.x. See this article for the latest information on the Threat ID ranges related to these PAN-OS releases.
URL Bulk Categorization Script
Ever have the need to see how PAN-DB would categorize hundreds or thousands of URL’s? Besides entering the URLs one-by-one at urlfiltering.paloaltonetworks.com, there is a faster way. One reason you might need to do this is when you are migrating from a URL-whitelist based security to URL categorization. All you need is a bash-capable machine that sits behind a Palo Alto Networks firewall on the perimeter with URL Filtering configured to at least alert on every category. In addition, you will need a text file with the URLs to be tested. Then, follow these steps:
Open a terminal window (MAC) or bash shell (Linux).
Change to the directory where the text file resides.
Copy and paste the following into the terminal/bash window command line:
For URL in ‘cat URL.txt’; do echo $URL; curl -m .5 -s -I $1 “$URL”; done
This will read and display the contents of URL.txt line-by-line and use the curl command to retrieve the HTTP header from each site.
Review the URL Filtering logs on the Palo Alto Networks firewall to see how each site is categorized.
TIP: Searching LIVE from Google
There are many helpful articles on live.paloaltonetworks.com but searching for a precise subject is easier done through a Google search. If you’d rather use Google to search LIVE, simply follow this syntax when at the Google search bar:
For example, if I was interested in creating a MineMeld miner, but I needed an article to get started, I would enter the following at the Google search bar:
site:live.paloaltonetworks.com minemeld miner
You will see the 3rd entry or so from the results list is what I was looking for.
Need 8.1 Metrics with 8.0 Firewalls?
PAN-OS 8.1 for Panorama brings useful firewall health statistics and graphs. Panorama keeps a baseline of individual firewall performance and provides a baseline for every firewall. These metrics include dataplane CPU, management CPU, connections, memory utilization, interface statistics, etc. Since a baseline is kept, Panorama knows when a firewall is outside of its baseline and will flag the specific metric that is high or low.
This feature requires Panorama to be on PAN-OS 8.1 as well as the firewalls. However, if your Panorama is on 8.1 but your firewalls are still on 8.0, there is a script that may be used to gather these metrics from the firewalls and store them within Panorama via the API. The script is called GoldenGate, and it may be found on Palo Alto Networks GitHub repository.
When Does the Firewall Enact TCP Reuse?
TCP Reuse is the act of reusing a TCP connection. If the 6-tuple connection is the exact same as a previous connection, the firewall will use the same connection for the new traffic. This, of course, assumes the former connection has not timed out.
This will only happen if the firewall sees a FIN or new SYN packet for a connection and the new connection matches the previous 6-tuple exactly. As long as a new SYN packet is received, the connection may be reused. A FIN packet is not necessary to start this process.
You will see the following in debugs and captures:
157.572489000 [TCP Port numbers reused] 33044→3306…