What is still missing or needs to be improved in PA Next Generation Firewalls ?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

What is still missing or needs to be improved in PA Next Generation Firewalls ?

L1 Bithead

Hi, will like to understand the oppinion from the PAN community about the features that are still missing or needs to be improved.

Will appreciate if you can specify by functionality like :

FIREWALL

Must Have : A,B,C

Nice to Have : D,E,F

Thks

Mario

78 REPLIES 78

Not applicable

Nice to Have : cisco integration with Filtering Service on Palo Alto, like websense or SurfControl

L4 Transporter

Nice to have: Applipedia should include the information if a specific application requires an exclusion for SSL decryption in order to work. E.g. dropbox

L4 Transporter

Ability to define and fold up groups of security rules.  The tags are very cool but a way to fold up groups of rules to a single line would be nice.

Longer captive portal, ability to put in length of captive portal based on user/group and/or timeout and/or native client etc.  Bottom line is BYOD is here.

Free copy of Panorama for small rollouts.  Why?  Word of mouth for larger installations, ability to gain experience with Panorama.

Real world examples of implementation, rules etc.  It is a different way of thinking and honestly is difficult to get a grip on it for complex situations.

Graphical interface for schedules.

Bob

L2 Linker

What i really would like to see in PA device is usable DLP. A few days ago i powered up old fortigate device and damn their DLP is quite nice to work with. They even had a chance to search for keywords in mail subject or body.

The ability to import user and group information periodically, and the ability to use those imported objects to create groups on the box. Our management does not like the fact that I need to rely on our IT group for firewall ACL's. Nor do they want to create another process in which we have to monitor more group memberships/changes to AD.

L3 Networker

I want a response page that comes up whenever someone attempts to do anything that is blocked that hooks to Active Directory.

There will be an Active Directory group that will allow overrides.

I want the user to be able to enter an Active Directory password in that response page that will allow overrides to application blocks, url filtering blocks and file blocks.

This is how it currently works in our Barracuda.

Not applicable

Must have :

So important, I'm listing it before my numbered items below : TCPDUMP support. I miss this basic feature nearly every day since our switch to Palo Alto. The web-based set up of background packet filters across fw, rx, tx and drop profiles is so tedious, I die inside each time I'm forced to use it. I now tcpdump from our F5's far more often because it's easier to troubleshoot using this industry standard and well-understood tool.

Other must-haves :

1. Security policy rules should be numbered. Ridiculous that when you search by tag, you have no context for where in your policy the results lie. We have to use Tufin for this basic functionality.

2. Security policy rules should be groupable, like Checkpoint's SmartCentre. Wading through over 200 lines of near-identical looking rules is tedious and can lead to mistakes. Tagging is only a partial fix and rendered near-useless by the lack of rule numbers.

3. Better support for opening multiple windows on the admin interface. For some reason, you can't middle-click on admin tags (policy, monitor, network, etc) to open new windows to those views. So you have to copy the current URL, open a new tab, paste in your URL, wait for it to load, then click on the tab you want.

4. Monitor filters should be easier to use (to create, and to apply after creation), more visible in the GUI and shareable between admins. The monitor tab should remember its last view automatically so you don't have to keep creating the filter, or copy/pasting the filter line.

5. Customisable user activity reports that don't cut off after 3 days of activity. Group support for user activity reports too - tedious having to re-run the same report for a whole team.

6. Better DLP support. We've been recently stung by the fact that you can't specify REGEX for data filters unless your REGEX has at least 7 characters of immutable text. I guess it's performance related, but undermines the DLP engine's usefulness.

There are almost too many Nice To Have's to list, it's overwhelming. Right click support on the policy editor would be good, so that I can choose to drill into an object from the policy page instead of having to copy the name, jump to the Object tab and search. A breadcrumb list in the ACC so that, having drilled in, I can step back out without losing the entire search. A threat log that I can actually search by "Name" (the entry is missing for some reason). Event types for the System Log so that I can filter by, say, "VPN related events".

L1 Bithead

Monitor Threats: The ability to query by Name same as Type and Severity, etc. but also keep a way to view the Threat description.

( subtype eq spyware ) and ( severity eq critical )

Just thought of one more - full name support in reports. Our HR department often have no idea who a user is based on their username, and so have to look it up, then write on the printed report who each username represents. To be fair, Bluecoat also fails this basic usability issue, but Websense nailed this out of the box last time I used it (about 7 years ago now right enough).

broadleyn wrote:

Must have :

So important, I'm listing it before my numbered items below : TCPDUMP support. I miss this basic feature nearly every day since our switch to Palo Alto. The web-based set up of background packet filters across fw, rx, tx and drop profiles is so tedious, I die inside each time I'm forced to use it. I now tcpdump from our F5's far more often because it's easier to troubleshoot using this industry standard and well-understood tool.

I miss tcpdump as well.  My eyes lit up when I saw a reference to tcpdump in the PANOS 5.0 documentation and after loading up 5.0 on a test box sure enough the tcpdump command was now present.  Unfortunately it can only capture traffic on the management interface NIC and doesn't work with the data plane interfaces.   Smiley Sad

So tcpdump in v5 only supports the mgmt interface? Basically useless then. I can only hope its inclusion is a stepping stone on the road to full support. But then, when tech "dial-in" to your PAN, they can use a key exchange built into the PAN to unlock tcpdump to run on any interface, so its exclusion here is not technical. Which doesn't bode well for having it generally available...

L3 Networker

How about a warning if the current commit is going to disrupt the data plane?  I re-named a virtual router and guess what?  It dumps the routes and rebuilds the routing table :smileyangry:  A warning would have been nice.  BTW, you can add routes and change interfaces in your VRs w/out disruption, go figure :smileyconfused:

Nice to have: I'd like to be able to change attributes of the admin gui css, so I visually distinguish test sessions from live.

L2 Linker

Why do I need to list out all possible proxy-ID combinations for an IPsec tunnel? PAN OS 5.0 greatly increased the proxy ID count per tunnel (from the absurdly low 10 in previous PAN OS), thanks for that. But I still have got to ask, why do I need to do this at all? When configuring an IPsec tunnel, what do I end up doing? I write a quick Perl script or use a text editor to generate all of the proxy ID combinations to cut 'n' paste config at the CLI. This is what computers are good at, doing simple repetitive tasks. The PAN is a computer... so why am I doing this for it? Why can't I enter the two lists of networks and it builds all of the pairs itself. If I can do it in a three line Perl script, it seems it would be trivial for PAN OS to do this behind the scenes at commit time. It's not something that would even need to really touch the run-time or dataplane code.

If the answer is that perhaps the user would only want to have certain pairs in a tunnel and not others, e.g. these pairs are desired,

Local_Net-A <--> Remote_Net-A

Local_Net-A <--> Remote_Net-B

Local_Net-B <--> Remote_Net-B

But for some reason,

Local_Net-B <--> Remote_Net-A

Is not. The right place to enforce policy is... wait for it... your security policy. You can block that traffic there, not in the IPsec configuration. Doing in the IPsec configuration is kind of like using routing policy to null route traffic on a firewall rather than using security policy. It works, but is not a good practice.

Oh, and speaking of IPsec, it'd be nice to have IKEv2 support. I know protocols from 2005 might be a little bleeding edge, but if we wait all the way to PAN OS 6, it will probably have been about ten years. Along with that, certificate-base authentication rather than solely pre-shared, secret keys would conform to real-world policy requirements (and all of the code lives in PAN OS somewhere for GlobalProtect VPNs).

TCPDUMP is one of the hugh reasons for buying one of Palo Alto's competitors.   The ability to gain instant visibility into the traffic flow is priceless.

Depending on the way an organization writes its change control policy, the way ASA, Palo Alto, Fortigate and a few others do packet capture could be prevented due a configuration change being involved.

But since the other big competittor includes tcpdump, and it's not a piece of configuration, it can be executed anytime, without special permission.

I'd like to see a tcpdump command in Palo Alto that is a single line command, and dumps to the screen/tty/console etc. without having to execute a second, third, fourth, or fifth command.   Leaving behind no residual configuration.

It would be best if it based on 'tcpdump'.  Having worked with dozens of firewalls, I'm fatigued at having to remember each vendor's unique view on packet capturing command syntax.

Even if this feature is not tcpdump under the hood, having it fake being tcpdump would be extremely beneficial. Same command, 'tcpdump', same attributes, '-nn -i eth1/1 -s0 -vv -e -p -A -X -w filename.pcap' etc., and same filter syntax, 'host 1.1.1.1 and port 22 and ! udp' etc.

  • 29087 Views
  • 78 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!