There are two types of address groups in the Palo Alto Networks firewalls; dynamic and static. By default, the firewall creates a static address group if you do not explicitly select dynamic. Therefore, you need to add the static element at the time of address group creation. The Controller monitors the health of Palo Alto Network software by using the VM-series API and performs switch over based on the API return status. The Controller dynamically programs Palo Alto Network route tables for any new propagated new routes discovered both from new Spoke VPCs and new on-premise routes.
In the week's Discussion of the Week (DotW), we'll take a look at a question from user 'aguley' about FQDN.
Even though it's not possible to use a wildcard inside an FQDN object, I'll highlight two possible workarounds.
When an FQDN object is committed to the system, the management plane sends out periodic DNS queries to populate this object with IP addresses mapped from the DNS reply. These mapped IP addresses are then be pushed down to the dataplane, where they're used inside the object in the security policy. On the dataplane, this object includes only the IP addresses it receives from the management plane, but no domain information. Each FQDN object on the dataplane is limited to a maximum of 10 IP addresses. No actual URL lookups are performed, which is why a wildcard cannot be used.
If the requirement is to allow web browsing to all possible subdomains of a certain domain, a Security Policy based on a custom URL category in the destination could be useful to fill the gap between an FQDN Object and a URL Filtering Security Profile.
The first step is to create a custom URL category that includes the desired wildcard domains:
Next, a Security Policy where the custom URL category is used in the service/URL category tab.
Note: A URL filtering license or URL Filtering Security Profile is not required for this to work.
This allows outbound web browsing to all subdomains of the domain while all other connections can be blocked.
A slightly more complex workaround that allows for more versatility is to use Dynamic Address Groups and Tags that can be updated by an API call. In this scenario, the DNS resolution must be performed by an external script, but the number of addresses allowed in a Dynamic Address Group is far greater than in an FQDN Object.
First, you'll need to generate an API key:
Where hostname is the firewall IP or hostname, username and password are your username and password.
The output will look somewhat like this:
111MyKey111
</result>
Next, create a Tag to represent the IP address pool:
Then create a new Dynamic Address Group and add the Tag as Match Criteria:
Finally, create a security policy using the DAG.
This DAG can now be populated with IP addresses from an external script. IPs can be added with a register operation or removed with an unregister operation.
This example was prepared to register 2 new IP addresses to the wildcard1 Tag:
The file can be pushed out with either wget or curl--the example uses wget:
To verify the IP addresses were added, click the more... link in the GUI Address Groups:
Or use the CLI command:
Palo Alto Generate Api Key
You can also verify the IP addresses are now in use in the Security Policy:
To view the original discussion, please follow this link: FQDN policy
All comments or suggestions are encouraged.
Thanks for reading!
Tom Piens
For additional information:
More information about Dynamic Address Groups:
Perhaps all serious admins of Palo Alto firewalls have heard about the REST API that PAN provides with their firewalls. Not all of them have tried to automate their work though :).
You may not need to work with API on a daily basis to perform routine firewall changes but if you happen to get involved with firewall migrations, bulk network changes and the like then the API is a must have!
I absolutely love it. You may actually be not very good at scripting but rest assured that the bicycle of PAN API scripting has already been invited for you. The bicycle is called PAN-Configurator and you can get it from GitHub. If the link ever changes the new one is likely to be referenced on PAN web site here.
PAN-configurator is a PHP library aimed to free you from XML as such (the native format of PAN firewalls’ configuration) and focus on the actual configuration tasks. Apart from various classes and functions the library contains a number of ready to use scripts which you can call from your own scripts and batch files.
PAN-configurator is a PHP library aimed to free you from XML as such (the native format of PAN firewalls’ configuration) and focus on the actual configuration tasks. Apart from various classes and functions the library contains a number of ready to use scripts which you can call from your own scripts and batch files.
High level sequence of steps to get started with PAN-configurator is as follows:
- Create a new Admin role for XML API (I would not recommend to allow Commit for this role)
- Create a new user and assign it the role above
- Generate API key
http(s)://hostname/api/?type=keygen&user=username&password=password
- Now you can use the key to make API calls from your scripts or to run the scripts from PAN-Configurator.
One of the most useful scripts withing PAN-configurator is the
rules-edit.php
Palo Alto Firewall Generate Api Key Download
To use it you basically need to:
- define input mode – you can make changes to the candidate config directly on the firewall or you can export running-config from your firewall, work with that file offline and then import it back on to the firewall and commit the changes;
- define filter – this is how you define what firewall rules your change will be applied to; definition of filters is very similar to filters in firewall GUI
- define action – this is actually what to do with the rules which were selected by the filter
![Generate Generate](/uploads/1/2/6/0/126071029/349190696.png)
Here are some examples (taken from the PAN web page referenced above):
rules-edit.php in=api://fw1.mycompany.com actions=enableLogStart 'filter=(to has dmz) and (dst has.only Webfarms)'
rules-edit.php in=config.xml actions=service-Set-AppDefault 'filter=!(app is.any) and (service is.any)'
It’s worth noting that you may fail to make changes directly on the entry-level firewalls which run latest codebases (i.e. PA2020 on 6.x firmware is likely to struggle and the option with config export/import may be the only one that works for you).
Play with these scripts and you will be amazed at how much you can do in no time at all. Luckily there is also a “Display” action that allows you to try any filter before you make actual change.
And, by the way, despite the fact that PAN-Configurator is still a Beta, I would say it’s already quite mature and its author is not a random Palo Alto enthusiast but a technical lead from PAN EMEA Professional Services – Christophe Painchaud who does firewall migrations and similar jobs pretty much on a daily basis.
Thank you Chris!