Next-Generation Firewall
Test the Configuration
Table of Contents
Expand All
|
Collapse All
Next-Generation Firewall Docs
-
-
-
-
-
-
-
- PAN-OS 12.1
- PAN-OS 11.2
- PAN-OS 11.1
- PAN-OS 11.0 (EoL)
- PAN-OS 10.2
- PAN-OS 10.1
- PAN-OS 10.0 (EoL)
- PAN-OS 9.1 (EoL)
- PAN-OS 9.0 (EoL)
- PAN-OS 8.1 (EoL)
-
- PAN-OS 12.1
- PAN-OS 11.2
- PAN-OS 11.1
- PAN-OS 10.2
- PAN-OS 10.1
Test the Configuration
Validate and test PAN-OS configurations using CLI testing commands before applying changes to production environments.
Where Can I Use This? | What Do I Need? |
---|---|
NGFW (Managed by PAN-OS or Panorama) |
|
Use the CLI-only test commands
to test that your configuration works as expected. For example,
you can test that your policy rulebases are working as expected,
that your authentication configuration will enable the Palo Alto
Networks device to successfully connect to authentication services,
that a custom URL category matches expected sites, that your IPSec/IKE
VPN settings are configured properly, that your User-ID syslog parsing
profiles are working properly, and many more things.
The following sections show examples of how to use some of the test commands:
Test the Authentication Configuration
Use the test authentication command to determine if your
firewall or Panorama management server can communicate with a back-end
authentication server and if the authentication request was successful. You can
additionally test authentication profiles used for GlobalProtect and Captive
Portal authentication. You can perform authentication tests on the candidate
configuration, so that you know the configuration is correct before
committing.
Connectivity testing is supported for local database authentication and for
external authentication servers that use multi-factor authentication (MFA),
RADIUS, TACACS+, LDAP, Kerberos, or SAML.
- (Vsys-specific authentication profiles only) Specify which virtual system contains the authentication profile you want to test. This is only necessary if you are testing an authentication profile that is specific to a single virtual system (that is, you do not need to do this if the authentication profile is shared).
admin@PA-3060> set system setting target-vsys <vsys-name>
For example, to test an authentication profile in vsys2 you would enter the following command:admin@PA-3060> set system setting target-vsys vsys2
The set system setting target-vsys command is not persistent across sessions.Test an authentication profile by entering the following command:admin@PA-3060> test authentication authentication-profile <authentication-profile-name> username <username> password
You will be prompted for the password associated with the user account.Profile names are case-sensitive. Also, if the authentication profile has a username modifier defined, you must enter it with the username. For example, if the username modifier is %USERINPUT%@%USERDOMAIN%, for a user named bzobrist in domain acme.com, you would need to enter bzobrist@acme.com as the username.For example, run the following command to test connectivity with a Kerberos server defined in an authentication profile named Corp, using the login for the LDAP user credentials for user bzobrist:admin@PA-3060> test authentication authentication-profile Corp username bzobrist password Enter password : Target vsys is not specified, user "bzobrist" is assumed to be configured with a shared auth profile. Do allow list check before sending out authentication request... name "bzobrist" is in group "all" Authentication to KERBEROS server at '10.1.2.10' for user 'bzobrist' Realm: 'ACME.LOCAL' Egress: 10.55.0.21 KERBEROS configuration file is created KERBEROS authcontext is created. Now authenticating ... Kerberos principal is created Sending authentication request to KDC... Authentication succeeded! Authentication succeeded for user "bzobrist"
Test Policy Matches
You can use test commands to verify that your policies are working as expected.- Test a security policy rule.Use the test security-policy-match command to determine whether a security policy rule is configured correctly. For example, suppose you have a user mcanha in your marketing department who is responsible for posting company updates to Twitter. Instead of adding a new rule just for that user, you want to test whether twitter will be allowed via an existing rule. By running the following test command, you can see that the user mcanha is indeed allowed to post to twitter based on your existing Allowed Personal Apps security policy rule:
admin@PA-3060> test security-policy-match application twitter-posting source-user acme\mcanha destination 199.59.150.7 destination-port 80 source 10.40.14.197 protocol 6 "Allowed Personal Apps" { from trust; source any; source-region none; to untrust; destination any; destination-region none; user any; category any; application/service [ twitter-posting/tcp/any/80 twitter-posting/tcp/any/443 finger/tcp/any/79 finger/udp/any/79 irc-base/tcp/any/6665-6669 vidsoft/tcp/any/51222 vidsoft/tcp/any/80 vidsoft/tcp/any/443 vidsoft/tcp/any/1853 vidsoft/udp/any/51222 vidsoft/udp/any/1853 rtsp/tcp/any/554 rtsp/udp/any/554 kkbox/tcp/any/80 yahoo-mail/tcp/any/80 yahoo-mail/tcp/any/143 0 msn-base/tcp/any/443 msn-base/tcp/any/1863 msn-base/tcp/any/7001 msn-base/udp/any/7001 ebuddy/tcp/any/80 gmail-base/tcp/any/80 gmail-base/tcp/any/443 hovrs/tcp/any/443 hov application/service(implicit) [ http/tcp/any/80 http/tcp/any/443 http/tcp/any/6788 http/tcp/any/6789 http/tcp/any/7456 http/tcp/any/8687 http/tcp/any/9100 http/tcp/any/9200 http/udp/any/1513 http/udp/any/1514 jabber/tcp/any/any jabber/tcp/any/80 jabber/tcp/any/443 jabber/tcp/any/5228 jabber/tcp/any/25553 jabber/udp/any/any stun/tcp/any/any stun/tcp/any/3158 stun/udp/any/any web-browsing/any/any/any web-browsing/tcp/any/any web-browsing/tcp/any/80 action allow; icmp-unreachable: no terminal yes; }
Test an Authentication policy rule.Use the test authentication-policy-match command to test your Authentication policy. For example, you want to make sure that all users accessing Salesforce are authenticated. You would use the following test command to make sure that if users are not identified using any other mechanism, the Authentication policy will force them to authenticate:admin@PA-3060> test authentication-policy-match from trust to untrust source 192.168.201.10 destination 96.43.144.26 Matched rule: 'salesforce' action: web-form
Test a Decryption policy rule.Use the test decryption-policy-match category command to test whether traffic to a specific destination and URL category will be decrypted according to your policy rules. For example, to verify that your no-decrypt policy for traffic to financial services sites is not being decrypted, you would enter a command similar to the following:admin@PA-3060> test decryption-policy-match category financial-services from trust source 10.40.14.197 destination 159.45.2.143 Matched rule: 'test' action: no-decrypt