// Why URL Tables

pfSense supports an alias type called URL Table (IPs) that fetches a remote list of CIDR prefixes on a schedule and treats it as a first-class firewall alias. Combined with the plain-text list endpoints on asn.ipinfo.app, you get firewall and policy-routing rules that stay current with an ASN's announced prefixes — no scripts, no cron jobs on the firewall itself, no manual copy-paste.

The same approach works for blocking abusive ASNs, allow-listing trusted cloud providers, and policy-routing specific destinations around a VPN tunnel. Anywhere you'd normally reach for a hand-curated list of CIDRs, a URL Table alias backed by an ASN replaces it with something self-maintaining.

Block

Drop traffic from datacenter, VPN, or abuse-heavy ASNs at the edge.

Allow

Restrict an admin interface to a known cloud or office ASN.

Route

Send game or streaming traffic out the WAN instead of a VPN tunnel.

NAT

Apply outbound NAT or port forwarding only for traffic to/from a specific ASN.

// Endpoint

pfSense's URL Table alias expects one CIDR per line in plain text. That's exactly what the /api/text/list/ endpoint returns. Replace {asn} with the AS number (with or without the AS prefix — both work):

https://asn.ipinfo.app/api/text/list/AS{asn}

Example — Steam (AS32590)

curl -s https://asn.ipinfo.app/api/text/list/AS32590

# Sample output (truncated):
# 103.10.124.0/23
# 103.28.54.0/24
# 146.66.152.0/22
# 146.66.155.0/24
# 155.133.224.0/19
# 162.254.192.0/21
# 2a04:a440::/29
# 2a04:a441::/32
# ...

Output mixes IPv4 and IPv6 prefixes. pfSense handles that natively — see IPv4 + IPv6 below.

Find the right ASN: use the main lookup to search by organization name (e.g. "Valve", "Cloudflare", "DigitalOcean") and grab the AS number from the result.

Caveat — verify before relying on it: not every service maps cleanly to a single ASN. Some publishers route game, login, or asset traffic through third-party CDNs or shared hosting providers, and the publisher's own ASN won't capture those flows. Confirm with a packet capture during actual usage before pinning a policy-routing rule to a single ASN alias.

// Create the Alias

In the pfSense web UI, navigate to Firewall → Aliases → URLs and click Add. Configure the new alias as follows:

Name	A short identifier with no spaces. Used by reference in firewall rules. Example: `Steam_Servers`.
Description	Free text. Useful for documenting what's inside.
Type	`URL Table (IPs)` — the variant that fetches and parses on a schedule.
URL	`https://asn.ipinfo.app/api/text/list/AS{asn}`
Update Frequency	`1` (day). Note: the dropdown to the right of the URL is labeled Subnet mask in the pfSense UI, but for `URL Table (IPs)` aliases that field is repurposed as the refresh interval in days. Same widget, different meaning. ASN announcements change slowly; daily is plenty.

Click Save, then Apply Changes. pfSense fetches the list immediately, parses every CIDR, and stores it as a pf table backing the alias.

The alias becomes available in the source/destination dropdowns of any firewall, NAT, or policy-routing rule. Type the alias name and pfSense autocompletes it.

// Field Reference

Type — URL Table (IPs) vs URL (IPs)

pfSense offers two URL-backed variants. URL Table (IPs) fetches the list on a configurable schedule and is the right choice for anything backed by a live source. URL (IPs) fetches once at save time and never refreshes — that's a one-shot import, not what you want here.

Update Frequency (a.k.a. the "Subnet mask" dropdown)

The dropdown to the right of the URL is labeled Subnet mask in the pfSense UI, but for URL Table (IPs) aliases that field is repurposed as the refresh interval in days. Same widget, different meaning — for Network aliases it's a CIDR prefix length; for the URL Table variant it's a day count. Easy to miss on first setup.

Daily is a sensible default. ASN prefix announcements typically change on the order of days to weeks; a tighter interval costs you nothing on the upstream side (the endpoint is CDN-cached) but adds churn to your firewall state without much benefit.

Max Entries

pfSense caps URL Table aliases at 200,000 entries by default. The vast majority of ASNs are well under this — even Cloudflare (AS13335) and Amazon (AS16509) are in the low thousands. If you're aliasing a multi-AS aggregate that approaches the limit, raise it under System → Advanced → Firewall & NAT → Firewall Maximum Table Entries.

// IPv4 + IPv6

The /api/text/list/ endpoint returns mixed IPv4 and IPv6 prefixes in a single response. pfSense handles that natively — entries are sorted into the correct address family at parse time and resolved automatically when you reference the alias from a v4 rule, a v6 rule, or a dual-stack rule.

You don't need separate aliases for IPv4 and IPv6 unless you specifically want to filter the lists differently. One alias, one URL, both stacks.

One exception: some older pfSense plug-ins or third-party packages assume single-family aliases. If you're using one of those and hit a parse error, fall back to filtering the list at fetch time — host a small upstream that strips one family — but the built-in firewall and NAT rules don't have this limitation.

// Use Case — Blocking an ASN

The most common reason to reach for an ASN alias: drop inbound traffic from a network you don't want talking to your edge. Pick the ASN, create the URL Table alias, and add a single firewall rule.

Alias

Name: Block_DigitalOcean
Type: URL Table (IPs)
URL:  https://asn.ipinfo.app/api/text/list/AS14061
Freq: 1 day

Firewall rule (WAN tab)

Action:      Block
Interface:   WAN
Address Family: IPv4+IPv6
Protocol:    Any
Source:      Single host or alias → Block_DigitalOcean
Destination: any
Description: Drop inbound traffic from AS14061 (DigitalOcean)

Place the rule above any allow rules on the WAN tab so it short-circuits first. The same alias can be referenced from multiple rules — drop on WAN in, no-reply on a port forward, exclude from a NAT — without re-fetching the data.

Block on WAN, not LAN. Source-ASN blocks belong on the interface where the traffic enters. Putting them on LAN catches outbound connections, which is rarely what you want.

// Use Case — Allow-listing

Inverse pattern: lock down an admin interface so only a specific ASN can reach it. Useful for restricting a management VPN endpoint to your corporate network's ASN, or limiting a webhook receiver to a known SaaS provider's address space.

Alias

Name: Allow_GitHub_Webhooks
Type: URL Table (IPs)
URL:  https://asn.ipinfo.app/api/text/list/AS36459
Freq: 1 day

Firewall rules (WAN tab — order matters)

# 1. Pass — allow GitHub's ASN to the webhook port
Action:      Pass
Source:      Allow_GitHub_Webhooks
Destination: WAN address, port 443

# 2. Block — deny everything else to that port
Action:      Block
Source:      any
Destination: WAN address, port 443

Allow rules have to come above the catch-all block — pfSense evaluates top-to-bottom and stops at the first match.

// Use Case — Policy Routing

The third common pattern: force traffic destined for a specific ASN out a specific gateway, regardless of the routing table's default. A typical setup is a home network whose default route is a WireGuard or OpenVPN tunnel — most of the time that's fine, but game traffic, streaming, or certain bank login flows misbehave when the apparent client IP is a datacenter exit. Policy routing carves an exception per ASN.

Alias

Name: Steam_Servers          → AS32590  (Valve)

Firewall rule (LAN tab — above the default rule)

Action:      Pass
Interface:   LAN
Source:      LAN net
Destination: Single host or alias → Steam_Servers
Advanced → Gateway: WAN_DHCP   # bypass the tunnel
Description: Steam traffic — exit direct WAN, skip VPN

Adding more services is a matter of creating one URL Table alias per ASN and either adding it to the existing rule's destination list or creating a parent Network alias (Firewall → Aliases → IP) that nests multiple URL Tables together — pfSense lets a Network alias reference other aliases, so a single firewall rule can target the parent and you maintain membership in one place.

Verify the ASN actually carries the traffic. Not every service maps cleanly to a single autonomous system. Some game and streaming publishers run game traffic on their own ASN but route logins, telemetry, or asset downloads through third-party CDNs and hosting providers — those won't be captured by the publisher's ASN. Run a packet capture during real gameplay (or whatever the workload is) and confirm the destination IPs actually fall inside the ASN you're aliasing before relying on the rule.

Why this is good when it fits: for services that do cleanly correspond to a single ASN, the destination list re-fetches every day — a publisher adding new server CIDRs propagates into your routing policy with no intervention. The hand-maintained CIDR lists that circulate on forums all eventually go stale; an ASN-backed alias does not.

// Manual Refresh

URL Table aliases refresh on the schedule you set, but you can force an immediate update from the CLI when you've just changed a URL or want to verify the fetch is working:

SSH into pfSense, then:

# Refresh all URL Table aliases now
/etc/rc.update_urltables now

# Inspect the parsed table for a specific alias
pfctl -t Steam_Servers -T show | head

# Count entries
pfctl -t Steam_Servers -T show | wc -l

The web UI also surfaces the entry count under Diagnostics → Tables — pick the alias from the dropdown and the contents render in the page.

// OPNsense Notes

OPNsense — the FreeBSD-based pfSense fork — uses the same underlying pf tables and supports the equivalent feature under a slightly different name: Firewall → Aliases → Add, type URL Table (IPs). The URL field, refresh frequency, and rule-binding behaviour are functionally identical to pfSense.

One difference: OPNsense exposes a "Refresh frequency" in days (decimals allowed), while pfSense uses an integer-day field. For practical use both map to roughly the same daily cadence. The endpoint URL doesn't change.

// Troubleshooting

The alias is empty after Save

Check that pfSense can reach the upstream. From SSH: fetch -o - https://asn.ipinfo.app/api/text/list/AS13335 | head. If the request hangs or fails, the firewall's outbound rules or DNS resolver are blocking it — typical for setups where the firewall itself is policy-routed through a VPN tunnel that's down.

Table size keeps changing

Expected. ASN prefix announcements ebb and flow as networks grow, acquire ranges, or reorganize. Day-to-day variation of a few prefixes is normal; large swings (10%+ entries) are worth investigating with a quick check on the main lookup.

"Maximum table entries reached"

Raise the global limit under System → Advanced → Firewall & NAT → Firewall Maximum Table Entries. The default of 200,000 is comfortably above any single ASN's prefix count, but stacking dozens of aliases can add up.

Rule matches the wrong direction

pfSense rules are evaluated on the interface where traffic enters the firewall. A "block source = ASN_X" rule on the LAN tab won't catch inbound WAN traffic from that ASN — it has to be on the WAN tab. This trips people up regularly.

// What Else

The same pattern works on anything that consumes a URL-fetched IP set — ipset's restore-from-URL, nftables sets, MikroTik /ip firewall address-list with a remote list, EdgeOS firewall groups, and most enterprise platforms with a "URL feed" feature. If the platform can read CIDRs from a URL on a schedule, it can consume /api/text/list/AS{asn}.

For Linux-native usage (ipset, iptables, nginx, Apache, Cisco, Juniper), see the main guides page. Building something interesting? Drop us a note.