Wire a NxtFireGuard blocklist into PAN-OS as an external dynamic list

PAN-OS has consumed external dynamic lists for years, which is convenient for us: there is nothing to install on the firewall and nothing exotic in the policy. You create a list, the firewall fetches it on a timer, and a security rule does the rest. Budget twenty minutes for the first one.

This walkthrough assumes PAN-OS 10.1 or newer and a firewall that can reach the internet over HTTPS, directly or through a proxy.

Before you start

Three things save you a rollback later.

Know your own address space first. Every public range you own, your branch offices, your VPN concentrator, your monitoring and backup providers, the source addresses of any partner integration. Put those into a whitelist before you enforce anything. The arbiter checks whitelists before an address is published to a list, so this is your seatbelt and it costs five minutes.

Decide where in the rulebase the deny rule goes. Above your permit rules, below whatever emergency allow rules you rely on for out of band access. If you lock yourself out of your own management plane, it will be because of rule order and not because of the list.

Finally, check what your platform can hold. EDL capacity in PAN-OS depends on the model, and lists are committed in order until capacity runs out. If you already run several large EDLs, look at the counts before adding another.

Step 1: create the blocklist

In the NxtFireGuard portal, go to Blocklists and create one. Four fields matter.

The name is what you will see in reports and audit trails, so make it descriptive rather than clever. pan-perimeter-deny tells the next person what it feeds.

Private and public IP types are separate decisions with separate thresholds. Public addresses are the normal case for a perimeter list. Private addresses are for lateral movement scenarios and belong on a different list with different rules, so leave them off unless you know you want them.

The public IP score threshold is the dial that controls everything downstream. An address has to clear this score before a contributing traffic sensor sends a block recommendation. Set it high for the first list. You can always lower it once you have watched the hits for a week, and lowering a threshold is a much calmer operation than explaining a blocked partner.

The check interval, in hours, decides how often blocked addresses are re scored and dropped when they no longer qualify. Shorter intervals mean a leaner list and more churn in the fetches. Twelve hours is a sensible starting point for a perimeter list.

The full field reference is in the blocklist documentation.

Step 2: get the URL

Every list is served from an endpoint that looks like this:

https://limes.nxtfireguard.de/blocklist/your-blocklist-id

You can cap what the endpoint returns with the entries parameter:

https://limes.nxtfireguard.de/blocklist/your-blocklist-id?entries=500

The cap only affects the response. Addresses stay on the internal list and keep getting re scored, you are just deciding how many of the highest scoring ones this particular firewall receives. That is useful when the firewall is small, when the list feeds a lab, or when you want a tight high confidence subset for an inline deny rule while a second, larger view feeds a log only rule.

Test it from a machine first, not from the firewall:

curl -s "https://limes.nxtfireguard.de/blocklist/your-blocklist-id?entries=20"

One address per line, no protocol prefixes, nothing else. That is exactly what PAN-OS wants.

Step 3: add the EDL object in PAN-OS

Go to Objects and then External Dynamic Lists, and click Add.

• Name: mirror the list name from the portal so the two are obviously the same thing.
• Type: IP List.
• Source: the full URL from step 2.
• Certificate Profile: because the source is HTTPS, enable server authentication and select a certificate profile whose root and intermediate CA certificates match the ones presented by the endpoint. If you skip this, retrieval fails and the failure is quiet.
• Check for updates: the default is hourly and hourly is fine to begin with. Intervals run relative to the last commit, which explains the occasional surprise where a list refreshes on a schedule you did not expect after a busy change window.

Use Test Source URL before you commit. It tells you whether the firewall itself can reach the endpoint, which is a different question from whether your laptop can. Note that the button is unavailable when the source requires authentication.

Click OK, then commit.

Step 4: reference it in a security rule

The EDL object is just an address object as far as policy is concerned.

Create a rule above your permit rules with the EDL as the source address, destination any, service any, action Drop. Drop rather than Deny if you would rather not send anything back to a scanner. Enable logging, because a deny rule you cannot see is a deny rule you cannot tune.

For a first rollout, do it the boring way instead: create the same rule with action Allow and logging on, placed above your normal rules, and read the traffic log for a week. You get the exact list of sessions that would have been dropped, with real source addresses, real destinations and real applications, before anything is enforced. When the log looks sane, flip the action. This single habit prevents nearly every bad outcome in this kind of deployment.

Step 5: verify what the firewall actually holds

The UI shows the object. What you want is the content the firewall pulled. From the CLI:

request system external-list show type ip name pan-perimeter-deny

If the count is zero, work backwards: certificate profile, name resolution from the firewall's service route, proxy configuration, then the URL itself. If retrieval fails after a period of success, PAN-OS keeps enforcing on the last list it successfully retrieved, so a silent failure looks like a working policy that is slowly going stale.

Week one

Look at the deny rule hit count daily. A perimeter list should be busy, so a rule with almost no hits usually means the threshold is too high or the list is not reaching the firewall.

If you get a false positive, resist the urge to lower the list size. Whitelist the specific address or range, then ask why it scored at all. Sometimes the answer is interesting: a partner running a vulnerability scanner from a shared cloud address, a CDN node that also hosts something unpleasant, your own external pentest.

Once the first list behaves, a second one with a lower threshold in log only mode is the cheapest way to find out what a more aggressive policy would cost you, without paying for it.

Questions about a specific PAN-OS version or a Panorama managed setup are welcome. Get in touch and we will walk through it with you.