New To PA- Differences between WebUI & Panorama

[MarioMarquez]

My company is about to deploy PA's in a few of our data centers as well as a single Panorama VM.  I have a traditional ASA background & want to know some basic theory on how PA's are configured.  I am enjoying the free training on the support site but I notice that so far most of it is taught based around configuring from the WebUI.  If I understand correctly Panorama is supposed to be used instead of the WebUI & I want to know if thats true & if so how different is configuration between Panorama & WebUI?  Here are some questions I have as a newbie to PA.

1) Is the WebUI still relevant when the PA's your managing are set up on Panorama?

2) Can 100% of the configuration be done from Panorama?  Even for a single PA?

3) Are there ANY settings that can ONLY be configured on CLI or the XML configuration terminal

    If so which settings?

4) Are Palo Alto & Juniper command line/sintacs mostly the same, somewhat the same or completely different?

[BPry · Accepted solution]

@MarioMarquez,

Answers:

1) yes the GUI is still relevant but depending on how you setup Panorama you may never need to log into the individual firewalls once they've been configured. Panorama can be your sole management point for the firewalls. 

2) No. The devices need to be configured a little bit so that they can communicate with your Panorama server when you are doing the inital configuration. Once they can communicate with Panorama then the answer would be yes, you could do the rest of the management 100% from Panorama. 

3) There's a few but nothing that I would suspect you to get into initially. 

4) It's fairly similar, same sort of layout. There are a number of differences that you'll find but they are easy to wrap your head around.

So one of the things that I'll point out to someone transitioning from an ASA background is that your whole mentality about how you build out policies really needs to change to effectively use all of the features of the firewall. Make sure that you don't simply transition your configuration to PAN and ignore app-id or WildFire and Security profiles, I've ran across way to many configurations that essentially purchase a PAN and don't use a third of its features because they are stuck in 'ASA' mode. 

Next, you'll find that a lot of people prefer the GUI when working with PAN, but that doesn't mean the CLI isn't valuable. The CLI and the API essentially go hand in hand, so if you get good at working in the CLI then you can easily script changes with the API.

Unlike other firewalls where you'll find features that are only accessable in the CLI, you'll actually find PAN to be the opposite. You'll find some features that only exist in the GUI and are totally inaccessible from the CLI; likewise you'll find more in-depth commands that are CLI only, but those are mostly debug and output commands. 

Biggest thing is don't get frustrated in the change, and don't be afraid to ask for help if you need it. Coming from an ASA background there are going to be some things with PAN that don't really line up with what you are used to, don't get frustrated by that. 

[MarioMarquez]

Thanks for the feedback. I’ve been studying alot & love the things I am reading. Are you familiar with the Packet-tracer command in cisco ASA? If not it basically lets you make a test of specific traffic going through the firewall e.g. “can host 192.168.1.25 access FTP from 20.20.20.20 over port 21” it will then give you the results showing you at what points in the process the packet passed or failed. It will tell you if you need a firewall rule or a nat statement etc... What is the Palo Alto equivalent of that? Does PA have a utility that lets you test specific traffic on the running config from source to destination telling you where the traffic passes or fails in configuration?

[BPry]

@MarioMarquez,

PA has a similar feature that is only available in the CLI to the best of my knowledge. What you are looking for is the 'test' function. 

Essentially you just run 'test' then specify what you want to test, so 'security-policy-match', 'pbf-policy-match', 'nat-policy-match', 'decryption-policy-match' or the like and input all the information that you would have present to see which policy matches what you've inputed. If it doesn't return anything then you don't have a policy to match what you've setup. 

An example of this would be 'test security-policy-match protocol 17 from L3-Trust to L3-Untrust source 10.191.16.1 source-user WISLEG\bpry destination 8.8.8.8 destination-port 53 application dns'.

As it sits currently there isn't an all-inclusive option similar to packet-tracer in the ASA world and you would need to test each part of the full communication path. This also won't account for packets that need to traverse a VPN tunnel similar to how the ASA would. That's like the one feature on the ASA that Cisco really got right 😉

[MarioMarquez]

Its good to know that tests can be run along different components of the full path. It sucks that it isnt as convenient as ASA packet tracer but I can pick & choose my battles.

[MarioMarquez]

@BPry

I meant to ask you, how different in comparrison is the WebUI & Panorama?

For instance if in the WebUI I needed to create tacacs authentication for PA admins I would need to go to Device > Server Profiles > Tacacs+  and create a Server Profile & then go to Device > Authentication Profile and add the Server Profile to an Authentication Profile, Etc...Etc...

How different would the location of these settings be when doing the same thing in Panorama?  Would learning to configure in the WebUI be pretty much the same thing as learning Panorama configurations?

[BPry]

@MarioMarquez,

So most things like that which you configure on the Firewall would be in the same location on Panorama for the actual Panorama appliance. If you were trying to configure the Server Profile to get pushed out to the firewalls then this would actually be done with a template to be able to push this information from panorama to the firewalls. 

[MarioMarquez]

Thanks alot.