Palo Alto Networks – PCNSE Certification Part 5: Basic Configuration (Security Policies, source NAT)

Create Tags

One thing that I really appreciate from PANOS is the introduction of TAGs, they are very handy when you are looking for policies, objects and many different things in your firewall. I know many of you out there appreciate the feature.

Tags are color-coded labels and enable you to group, sort, and filter objects using keywords or phrases. Tags can be applied to Address objects, Address Groups (static and dynamic), services, Service Groups, and policy rules. Tags can be assigned a color that makes the results of a search easier to find in the web interface.

Locate tags under Objects –> Tags (right panel) ** we are going to be creating a few tags to help identify traffic as follows:


Here is how the configuration looks in the CLI

admin@firewall-a# set tag andres color color42 comments Andres-Testing-Tags


A little trick to see things in a more understandable format!

admin@firewall-a# run set cli config-output-format set


admin@firewall-a# run set cli config-output-format set
admin@firewall-a# show | match tag
set tag danger color color7
set tag danger comments "Danger Tag"
set tag egress color color3
set tag egress comments "Egress Tag"
set tag dmz color color6
set tag dmz comments "DMZ Tag"
set tag internal color color4
set tag internal comments "Internal Tag"
set tag andres color color42
set tag andres comments Andres-Testing-Tags


The RAW Running Configuration

admin@firewall-a#show config running

tag {
  danger {
    color color7;
    comments "Danger Tag";
  egress {
    color color3;
    comments "Egress Tag";
  dmz {
    color color6;
    comments "DMZ Tag";
  internal {
    color color4;
    comments "Internal Tag";


Creating a source NAT

One of the main reasons why I have started again creating these posts is basically because there are some of the operations like NAT that I don’t fully understand, so here we are! – This type of NAT is what I know like PAT, or the NAT to provide internet to Inside resources.

The workflow is as follows
We will configure as follows:

The General TAB:

* The name ** It is always good practice to specify the type of NAT and direction of your NAT policy
* A Description
* The Tag (Help keeping your config clean!)
* Group Rules By Tag –> YESS!!
* Audit Comment, well if you add one you are Hard Core in my book, congrats!


But let’s be honest all the General Tab does is keep your work clean, there is still no effect on configuration other than just descriptions and organization

The Original Packet Tab

This is where things start to get interesting, Lets make sure we understand this one correctly
* Source Zone
* Destination Zone
* Destination Interface
* Service
* Source Address
* Destination Address


At this point you should be thinking, why this guy allowed Source: ANY? ** Well I could easily hard code the source address to my inside IP addressing, but what I’m looking to do in this case is make sure my Zone is the one that is taken as the source, and this will help me in the future when configuring new “Inside Interfaces” I could just allocate them to the “Inside Zone”

The Translated Packet

This TAB is downhill now – At this point you know the direction of your traffic, so the only thing you need to configure is
* Translation type (PAT or Dynamic IP and Port)
* Address Type – Interface Address ** We only have 1 IP we are going to be using for Internet
* Interface –> This is your outside Interface
* IP address –> Your Public IP address


We are not touching the Destination piece, remember we are working with a Source NAT ** Now, here is how it looks when you are done.


As part of the flow in the configuration, we still need to configure a Security Policy to allow traffic between Zones

Create a Security Policy Rule

This piece should self explanatory, but we are going to cover it for my sanity

The General TAB

* Name
* Rule Type
* Tag
* Group Rules by Tags


The Source TAB

Select your source Zone, and make sure the source address is checked with ANY

The Destination TAB

Here we do the same, make sure your destination Zone is specified and that destination address is checked for ANY

** Again all these can be hard coded, but as for the lab we are playing with the configs, and we are forcing access based on Zones, which so far will work for what we are doing. As part of the Security Policy, note that you have the option to configure based on UserID, Application and URL. We will have the chance to play individually with them at some point, but in the mean time we should make sure all of them are marked with ANY at their destination.


Testing all this worked!

After a very nice Commit action ** which I completely forgot, here are the results

Here is some of the traffic we are sending out to the internet

What is Next?

Destination NAT – This post was getting too long!

About the Author:

Andres Sarmiento, CCIE # 53520 (Collaboration)
With more than 15 years of experience, Andres is specialized in Unified Communications and Collaboration technologies. Consulted for several companies in South Florida, also Financial Institutions on behalf of Cisco Systems. Andres has been involved in high-profile implementations including Cisco technologies; such as Data Center, UC & Collaboration, Contact Center Express, Routing & Switching, Security and Hosted IPT Service provider infrastructures.

You can follow Andres using Twitter, LinkedIn or Facebook

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top