A Palo Alto firewall does not have a per-list EDL limit. PAN-OS enforces a platform-wide capacity for IP-type External Dynamic Lists that every IP EDL on the box shares, including Palo Alto’s own predefined lists. Entry-level appliances sit around 50,000 IP entries; larger hardware and VM-Series sizes allow 150,000 or more. Each IP address or CIDR block counts as one entry, entries beyond the limit are silently skipped, and you can see exactly what you are using with request system external-list stats type ip name <list>.
Most admins meet the EDL limit the hard way: they add a popular aggregated blocklist, the commit succeeds, and weeks later they discover a system log warning that the list exceeded capacity and half of it was never enforced. This guide explains how the limit actually works so you can size your lists deliberately instead of discovering the ceiling by accident.
What the Palo Alto EDL Limit Actually Is
PAN-OS supports four kinds of External Dynamic Lists: IP address, domain, URL, and (on newer versions) equipment identity and subscriber identity lists. Each type has its own capacity, and the capacity is defined per firewall model in Palo Alto’s Firewall Object Capacities documentation. The number that matters for blocklists is the IP-type capacity.
Three properties of that limit trip people up:
- It is shared. All IP EDLs configured on the firewall draw from one pool. Three 40,000-entry lists consume 120,000 entries, regardless of how many of them are referenced in policy.
- Predefined lists count too. Palo Alto’s built-in bulletproof ISP, high-risk, known-malicious, and Tor exit lists are IP EDLs. If you reference them in policy they occupy capacity alongside your own feeds.
- It counts entries, not addresses. An IPv4 address, an IPv6 address, a range, and a CIDR block each count as one entry. A single
203.0.113.0/24line covers 256 addresses for the price of one.
Capacity by Platform Tier
Palo Alto publishes the exact figure per model, and the numbers move between PAN-OS releases. The pattern is consistent enough to plan around:
| Platform tier | Typical IP-EDL capacity | Planning guidance |
|---|---|---|
| Entry-level hardware (PA-400 and PA-200/220 class) | ~50,000 entries | One curated feed plus predefined lists. Avoid multi-source aggregators. |
| Mid-range hardware (PA-800, PA-1400, PA-3000 class) | ~150,000 entries | Room for two or three curated feeds. Still too small for full FireHOL-style aggregates. |
| High-end hardware and large VM-Series (PA-5000/7000 class) | 150,000+ entries | Largest headroom, but the shared-pool rule still applies. |
| Small VM-Series and CN-Series | Varies with the licensed size | Check the capacity for your specific VM tier before adding lists. |
Notice that no tier comfortably fits a full aggregated reputation feed. FireHOL Level 3 and similar aggregates run to tens of thousands of entries on their own, and AbuseIPDB exports at low confidence thresholds can exceed 100,000. That is the core sizing problem: the most popular free lists are built for servers with unlimited iptables memory, not for firewall EDL pools.
What Happens When You Exceed the Limit
PAN-OS does not reject the commit. It loads entries in order until the platform capacity is reached, drops the remainder, and writes a system log entry (subtype general) warning that the EDL exceeded the maximum number of supported entries. The firewall continues to enforce the entries it did load.
Truncation is also non-deterministic from your point of view: the entries that get dropped are whatever the source happened to place last, which for most aggregated feeds is arbitrary. You cannot assume the “important” IPs survived.
How to Check Your EDL Usage
Three CLI commands answer every capacity question. Run them from operational mode:
1. Entry counts and refresh status for one list
request system external-list stats type ip name <list-name>Returns total valid entries, invalid entries (lines the parser rejected), and the last refresh timestamp. Run it for each IP EDL and add the valid totals; that sum is your consumption against the platform pool.
2. Inspect the loaded entries
request system external-list show type ip name <list-name>Prints the entries the firewall actually holds. Useful for confirming CIDR blocks parsed as ranges rather than being rejected as invalid.
3. Force a refresh after changing the source
request system external-list refresh type ip name <list-name>Pulls the list immediately instead of waiting for the configured interval, so you can re-run the stats command and confirm the new size.
In the web UI, Objects > External Dynamic Lists shows each list’s last refresh, and Monitor > Logs > System filtered on ( subtype eq general ) surfaces capacity warnings.
How to Stay Under the Limit
1. Prefer curated lists over aggregated ones
An aggregated feed merges many sources and inherits every entry each source ever flagged. A curated feed keeps only addresses confirmed to be attacking a specific target class right now. For a VPN gateway, a curated VPN brute force list of a few thousand entries blocks the infrastructure that is actually hitting GlobalProtect portals, while a 100,000-entry aggregate spends most of its capacity on spam relays and web scanners that will never touch your VPN.
2. Use CIDR-aggregated sources
Because a range counts as one entry, a source that publishes attacker netblocks instead of individual addresses can cover millions of addresses in a few thousand lines. ThreatListPro’s list is about 2,700 entries and expands to more than 5.4 million addresses, so it uses under 6 percent of a 50,000-entry pool. Our free CIDR calculator shows how many addresses a given block covers.
3. Budget for the predefined lists
If you reference Palo Alto’s bulletproof ISP or high-risk lists in policy, subtract their size from your pool before adding third-party feeds. On an entry-level box those predefined lists alone can be a meaningful share of capacity.
4. Split by purpose, not by source
One list per protected surface (VPN, RDP, SSH, web) is easier to size and easier to audit than one list per vendor. If a list is dedicated to the VPN portal, its policy scope is narrow and its acceptable size is obvious.
5. Watch the system log
Create a log forwarding profile or a simple saved filter for EDL capacity warnings. The silent-failure mode is the whole risk; a five-minute alert configuration removes it.
How Other Firewalls Compare
The same shape of limit exists elsewhere, with different numbers. FortiGate’s external IP threat feeds (External Connectors) accept up to 131,072 entries per feed on most models. pfSense with pfBlockerNG and OPNsense URL aliases are bounded by table memory rather than a fixed count and comfortably handle six-figure lists. SonicWall and Sophos dynamic lists have smaller ceilings that vary by appliance. The practical conclusion is identical: a compact curated list works everywhere; a large aggregate works only on the biggest hardware. Our Palo Alto GlobalProtect guide and FortiGate guide walk through the vendor-specific setup.
Blocklist Sizes vs Palo Alto EDL Capacity
| Blocklist | Approximate entries | Fits a 50k pool? | Fits a 150k pool? | Built for |
|---|---|---|---|---|
| ThreatListPro VPN Brute Force | ~2,700 (CIDR-aggregated, 5.4M+ addresses) | Yes, under 6% | Yes, under 2% | VPN gateways and firewalls |
| Spamhaus DROP / EDROP | ~1,000–1,500 netblocks | Yes | Yes | Network hygiene |
| FireHOL Level 1 | Low thousands of netblocks | Yes | Yes | Servers, general perimeter |
| FireHOL Level 3 | Tens of thousands | Marginal, crowds out other lists | Yes, but consumes a large share | Servers with iptables/ipset |
| AbuseIPDB export (low confidence) | 100,000+ | No | Marginal | SIEM enrichment, not EDLs |
| IPsum Level 3 | Tens of thousands | Marginal | Yes | Broad reputation on servers |
For the reasoning behind stacking a small curated list with a hygiene list, see the 2026 IP blocklist stack and ThreatListPro vs FireHOL.
Frequently Asked Questions
How many IP addresses can a Palo Alto EDL contain?
It depends on the firewall model, not the list. PAN-OS enforces a platform-wide capacity for IP-type External Dynamic Lists that is shared across every IP EDL configured on the firewall, including Palo Alto's own predefined lists. Entry-level appliances sit around 50,000 IP entries; larger hardware and VM-Series sizes allow 150,000 or more. Check the Firewall Object Capacities table for your exact model and PAN-OS version.
Is the Palo Alto EDL limit per list or per firewall?
Per firewall. All IP-type EDLs share one pool of entries. Three lists of 40,000 entries each consume 120,000 entries against the platform limit, so a single oversized aggregated feed can starve every other list you configure.
Does a CIDR block count as one entry or many?
One entry. A single /24 range counts once even though it covers 256 addresses. That is why a curated list built from CIDR blocks can cover millions of addresses while consuming only a few thousand entries of EDL capacity.
What happens when a Palo Alto EDL exceeds capacity?
PAN-OS loads entries up to the limit and skips the rest, then writes a system log warning that the list exceeded capacity. The skipped entries are silently unenforced, so a feed that is too large gives you partial protection without an obvious failure.
How do I check how many entries my EDL is using?
From the CLI run request system external-list stats type ip name <list-name>. It reports total valid entries, invalid entries, and the last refresh time. Run it for each IP EDL and add the totals to see how close you are to the platform limit.
Does ThreatListPro fit under Palo Alto EDL limits?
Yes. The ThreatListPro blocklist is about 2,700 entries that expand to more than 5.4 million addresses through CIDR aggregation, so it uses under 6 percent of even a 50,000-entry platform limit and leaves room for Palo Alto's predefined lists and any other feeds you run.