Thursday, October 16, 2025

Lab 6

Module 6: Creating and Managing Security Policy Rules


 Palo Alto  Firewall 

 

 

 

 

Security Policy


You have the firewall deployed and connected to all the appropriate networks. The next step is to
begin creating Security Policy rules. You will start by creating rules that allow hosts in the
Users_Net zone to communicate with hosts in the Extranet zone. You will then create Security
Policy rules to allow hosts in the Users_Net zone to connect to hosts in the Internet zone.
You also need to allow hosts in the Extranet zone to communicate with hosts in the Internet
zone.

Lab Objectives

• Configure a Security Policy rule to allow access from Users_Net to Extranet
• Test access from client to Extranet servers
• View the Traffic log
• Examine Policy Rule Hit Count
• Reset rule hit counts
• Customize Policy tables
• Enable intrazone and interzone logging
• Create Security Policy rules to Internet Zone
 

High-Level Lab Steps
Use the information in the sections below to complete the objectives for this lab. We suggest that
you use this section only if you have extensive experience working with Palo Alto Networks
firewalls.
If you need more detailed guidance for the objectives, use the Detailed-Lab Steps section.
Apply a Baseline configuration to the Firewall
• Load and commit the configuration file - edu-210-11.1a-06.xml to the Firewall
 

Create Security Policy Rule

• Use the information below to create a Security Policy rule that will allow traffic from the
Users_Net zone to the Extranet zone.
 

Rule Name Users_to_Extranet
Description Allows hosts in Users_Net zone to access servers in Extranet zone
Source Zone Users_Net
Destination Zone Extranet
Application Any
Service application-default
URL Category Any
Action Allow
Commit the configuration
• Commit the changes before proceeding.



Modify Security Policy Table Columns

• Hide the following columns in the Security Policy table to create more area to view
helpful information
• Type
• Source Device
• Destination Device
• Options
• Drag and drop the Action column from its current location so that it appears between the
Name column and the Tag column
Test New Security Policy Rule
• From the Client-A host, ping 192.168.50.80, which is the IP address of a web server in
the Extranet zone.
• Use the web browser on the Client-A client to connect to the Extranet web page at
192.168.50.80.
 

Examine Rule Hit Count
• In the Security Policy rule table, locate the column for Hit Count, and note the number
of Hits on this Users_to_Extranet rule.
• From the Client-A host, ping the Extranet web server - 192.168.50.80.
• Refresh the Hit Count and note any increase in the value for the Users_to_Extranet
Security Policy rule.
Reset the Rule Hit Counter
• Reset the Hit Count for the Users_to_Extranet rule
 

Examine the Traffic Log
• Hide the following columns in the Traffic Log.
• Type
• Source Dynamic Address Group
• Destination Dynamic Address Group
• Dynamic User Group
• From the terminal window on the Client-A host, ping 8.8.8.8
You will not get a reply
• Examine the traffic log again and use a simple filter to see if there are any entries for the
ping session that failed 

Answer the following question:

Why there are no entries in the Traffic log for your ping session to 8.8.8.8?
• Write down your answer in the field shown or on notepaper in class. 

Enable Logging for Default Interzone Rule
• Edit the Interzone Security Policy rule and enable Log at Session End
 

Commit the configuration
• Commit the changes before proceeding

Ping a Host on the Internet
• From the terminal window on the Client-A host, ping 8.8.8.8
 

You will not get a reply
• Examine the Traffic Log again and use a simple filter to see if there are any entries for
this session that failed
• The entries in the Traffic Log should show you that the ping sessions are hitting the
interzone-default rule
 

Create Block Rules for Known-Bad IP Addresses

• Use the information below to create a rule at top of the Security Policy to block traffic to
known bad IP addresses provided by Palo Alto Networks. 

Rule Name Block-to-Known-Bad-Addresses
Description Blocks traffic from Users and Extranet to known bad IP addresses
Source Zone Users_Net
Extranet
 Destination Zone Internet 
 Destination Address 
Palo Alto Networks – Bulletproof IP addresses
● Palo Alto Networks – High risk IP addresses
● Palo Alto Networks – Known malicious IP addresses

Application Any
Service any
URL Category Any
Action Deny

 

 

 • Use the information below to create another Security Policy rule to block traffic from
known bad IP addresses provided by Palo Alto Networks. Place this rule at the top of the
Security Policy, just below the Block-to-Known-Bad-Addresses rule.
 

Rule Name Block-from-Known-Bad-Addresses
Description Blocks traffic from known bad IP addresses to Users and Extranet
Source Zone Internet
Source Address ● Palo Alto Networks – Bulletproof IP addresses
● Palo Alto Networks – High risk IP addresses
● Palo Alto Networks – Known malicious IP addresses
Destination Zone Users_Net
Extranet
Application Any
Service application-default
URL Category Any
Action Deny

 


Create Security Rules for Internet Access

• Use the information in the tables below to create Security Policy rules.
Create Users to Internet Security Policy Rule
• Use the information below to create a Security Policy rule that will allow traffic from the
Users_Net zone to the Internet zone.
 

Rule Name Users_to_Internet
Description Allows hosts in Users_Net zone to access Internet zone
Source Zone Users_Net
Destination Zone Internet
Application Any
 

 

 

Create Extranet to Internet Security Policy Rule

Use the information below to create a Security Policy rule that will allow traffic from the
Extranet zone to the Internet zone.
 

Rule Name Extranet_to_Internet
Description Allows hosts in Extranet zone to access Internet
zone
Source Zone Extranet
Destination Zone Internet
Application Any
Service application-default
URL Category Any
Action Allow 

 

Commit the configuration
• Commit the changes before proceeding
 

Ping Internet Host from Client A
• From the terminal window on the Client-A host, ping 8.8.8.8
You will not get a reply
 

• Examine the Traffic Log again and use a simple filter to see if there are any entries for
this session that failed  aged-out
 

• The entries in the Traffic Log should show you that the ping sessions are hitting the
Users_to_Internet rule.
• Answer the following question:
 

Can you explain why your ping session from the client to the Internet host did not get a reply
even though the firewall is allowing the traffic?
• Write down your answer in the field shown or on notepaper in class.  No NAT for RFC 1918

addresses to internet  

RFC 1918 is an Internet Engineering Task Force (IETF) document that reserves three blocks of IPv4 addresses for private networks: 

(10.0.0.0-10.255.255.255)  (10.0.0.0/8)
(172.16.0.0-172.31.255.255)  (172.16.0.0/12)
(192.168.0.0-192.168.255.255)  (192.168.0.0/16) 

These addresses are not routable on the public internet, allowing organizations to use them internally without coordinating with the Internet Assigned Numbers Authority (IANA). This is crucial for conserving the limited IPv4 address space 

 

 

GENERAL 

 

 SOURCE

 DESTINATION

 

 APPLICATION

 SERVICE /URL Category

 ACTION

 

 

Examples of some Destinations

 

Examples of Some Sources 

 

Security Policy 

 

 

 

 Ping aged out because NO NAT was created for inside to hit the internet

  

No comments:

Post a Comment

Global Protect Troubleshooting

Global Protect Components Certificate Management Connections Authentication Debugging https://www.youtube.com/watch?v=0Z48WHvyW0Q authentica...