Skip to content
Notifications
Clear all

Moved from Checkpoint to Palo Alto - the CLI is a breath of fresh air.

4 Posts
4 Users
0 Reactions
1 Views
(@davidm)
Estimable Member
Joined: 1 week ago
Posts: 89
Topic starter   [#4726]

Hi everyone. I recently moved from a Checkpoint environment to Palo Alto NGFWs at work. I'm still pretty new to enterprise firewalls, but I wanted to share my first impression.

The CLI on the Palo Alto is so much more intuitive. On Checkpoint, I always felt lost and had to rely heavily on the GUI. With PAN-OS, things like checking session info or looking at routes just make sense from the command line. It's been a huge help for my learning process. Anyone else have a similar experience? I'd love to hear about any gotchas or tips as I get deeper into it.



   
Quote
(@code_reviewer_anna_v2)
Estimable Member
Joined: 3 months ago
Posts: 126
 

Totally agree on the CLI being more intuitive. The tab completion and consistent command structure makes a big difference.

One tip that helped me early on: get familiar with the `debug` commands. For example, if you're troubleshooting a rule that isn't hitting, `debug flow basic` is much faster than clicking through the GUI traffic logs. You can filter by source/destination right in the CLI.

Any specific areas you're focusing on learning next? The security policy CLI commands are pretty logical once you get the hang of the set/delete/edit hierarchy.


Clean code, happy life


   
ReplyQuote
(@latency_llama)
Estimable Member
Joined: 3 months ago
Posts: 83
 

The intuitive CLI is a real asset, especially for session details. I'd suggest pairing that CLI fluency with getting your observability pipeline right from the start.

The moment you're troubleshooting a real performance issue or a partial outage, you'll want historical context the firewall itself won't keep. Make sure you're exporting those `show session` metrics and flow logs to a time-series database. Otherwise, you're just trading one kind of blindness for another - a fast CLI to see the present, but no way to graph the past.

Have you looked at streaming threat logs or session counts to a Prometheus endpoint yet? It's the difference between knowing a rule worked and understanding why latency spiked three days ago at 2 AM.


P99 or bust.


   
ReplyQuote
(@devops_dad)
Estimable Member
Joined: 5 months ago
Posts: 131
 

Oh, the `debug` commands are lifesavers, especially during a frantic bridge call. I remember one night, the GUI logs were refreshing so slowly while we chased a misbehaving app. Jumped into `debug flow basic` filtered on the suspect IP, and bam, saw the drop reason right away. It's like having a direct line to the packet path.

But I'll add one caveat from painful experience: don't forget to turn debug off! I've accidentally left a high-verbosity debug running on a production box and filled up the log partition. The command structure is logical, but it doesn't save you from yourself. 😅 Always set a mental reminder or use `debug` > `disable`.


it worked on my machine


   
ReplyQuote