Use the blocklists: nftables, iptables, pfSense, OPNsense, MikroTik and more

This is how you add the IPv64.net IP blocklists to your firewall, server or reverse proxy: Linux with nftables or iptables/ipset, pfSense, OPNsense, MikroTik, Palo Alto, FortiGate, Sophos, nginx, CrowdSec and Node64. This page is the IPv64.net integration guide; the former address https://ipv64.net/v64_blocklist_integration_guide redirects here. The Linux scripts and the nginx and CrowdSec examples were tested with the live lists.

Before you start

A blocklist drops all traffic from the listed networks. Try it on a test system first, keep a second way to reach the device (console, VPN) and start with a list with few false positives – Spamhaus DROP (spamhaus_drop) or FireHOL Level 1 (firehole_l1). Which list suits which purpose is described under Which list for whom?.

1. Choose a list
   You find the list ID in the overview, e.g. firehole_l1, all_notor or v64.
2. Build the address
   IPv4 and IPv6: https://ipv64.net/blocklists/ipv64_blocklist_<id>.txt, IPv4 only: …/ipv64_blocklist_v4_<id>.txt, IPv6 only: …/ipv64_blocklist_v6_<id>.txt, MikroTik: …/v64_mikrotik_v4_<id>.rsc and …_v6_<id>.rsc. Each line holds one address or network (CIDR), without comments.
3. Set the interval
   Fetch at most every 30 minutes; every 1 to 6 hours is enough. For the live state of the v64 Blocklist see Live state with list token.
4. Choose the direction
   Most lists are blocked inbound by source. Spamhaus DROP and Feodo Tracker are also worth blocking outbound (destination), the DoH server list outbound only.

Choose a list

Every list is available in three variants (IPv4 and IPv6, IPv4 only, IPv6 only) and as a MikroTik import file; the addresses are listed above under Build the address. The lists are regenerated several times a day. Country and continent lists are on the list page and under Country and continent lists. For scripts, the index.json lists every list with count, last update, source, licence and file names (see index.json). All lists in detail: All lists at a glance.

Sources, false positives and terms

IPv64.net combines and cleans public lists: it converts everything to networks and removes duplicates, contained networks and reserved ranges. The entries themselves come from these projects:

• Spamhaus DROP
• FireHOL Level 1
• blocklist.de
• DShield (SANS ISC) (CC BY-NC-SA 2.5, not for commercial purposes)
• Tor Project
• abuse.ch Feodo Tracker (CC0)
• Emerging Threats
• CINS Army
• IPsum (Unlicense)
• DoH-IP-blocklists (GPL-3.0)
• Honeypot64 (IPv64.net, CC BY 4.0): v64 Blocklist
• Cloud networks as published by Cloudflare, AWS and Google Cloud
• AI crawlers: the address lists of the operators and ai.robots.txt (MIT), see AI crawlers
• Origin (country_ranges.txt.gz): DB-IP.com (CC BY 4.0, attribution “IP country data by DB-IP.com”), country lists from the data of the regional Internet registries, see Country and continent lists

Licence, false positives and size of every list are in the overview. If one of your addresses is listed by mistake, ask the source project to remove it; the change reaches the IPv64 lists with the next update. For the v64 Blocklist, request the release in the IP lookup (see release). The lists are free to use; please respect the terms of the source projects and do not use them as the only protection.

Linux: nftables or iptables/ipset

For Linux servers and Linux routers, IPv64.net provides two ready-made scripts. Both load the chosen list for IPv4 and IPv6, swap it in one step and keep the old list active if a download fails. They take the list ID as parameter (default: firehole_l1).

nftables (recommended)

For current Debian, Ubuntu, Fedora and Proxmox systems and most Linux routers. The script creates its own table inet ipv64 and replaces it completely on every run. Your other rules stay untouched. It filters traffic to the host itself (input) and forwarded traffic (forward), including Docker containers and hosts behind NAT. IPv64.net tested the nftables, ipset, nginx and CrowdSec examples with the live lists.

Install (as root):

apt install -y nftables curl
curl -fsSo /usr/local/sbin/ipv64-blocklist-nft.sh https://ipv64.net/blocklists/tools/ipv64-blocklist-nft.sh
chmod +x /usr/local/sbin/ipv64-blocklist-nft.sh
/usr/local/sbin/ipv64-blocklist-nft.sh firehole_l1

Update every 4 hours and after a reboot (cron):

cat > /etc/cron.d/ipv64-blocklist <<'EOF'
17 */4 * * * root /usr/local/sbin/ipv64-blocklist-nft.sh firehole_l1 >/dev/null
@reboot      root sleep 30 && /usr/local/sbin/ipv64-blocklist-nft.sh firehole_l1 >/dev/null
EOF

Check and remove:

nft list chain inet ipv64 input     # counters show dropped packets
nft delete table inet ipv64          # remove the blocklist completely

The script (https://ipv64.net/blocklists/tools/ipv64-blocklist-nft.sh), so you know what it does before you run it. It downloads ipv64_blocklist_v4_<id>.txt and ipv64_blocklist_v6_<id>.txt, keeps only lines that look like an address or network and writes the sets bl4/bl6 with the chains input and forward (priority −10):

#!/bin/sh
# IPv64.net blocklist for nftables (IPv4 + IPv6) - https://ipv64.net/v64_blocklist_integration_guide
# Usage: ipv64-blocklist-nft.sh [list]   (default: firehole_l1, see https://ipv64.net/v64_blocklists)
# Run as root. Replaces table "inet ipv64" atomically; on a failed download the old sets stay active.
set -eu
LIST="${1:-firehole_l1}"
BASE="https://ipv64.net/blocklists"
TMP="$(mktemp -d)"
trap 'rm -rf "$TMP"' EXIT

for v in 4 6; do
	curl -fsS --max-time 120 -o "$TMP/raw$v" "$BASE/ipv64_blocklist_v${v}_${LIST}.txt"
	# only keep lines that look like an address or network
	grep -E '^[0-9A-Fa-f:.]+(/[0-9]{1,3})?$' "$TMP/raw$v" > "$TMP/v$v" || true
done
if [ ! -s "$TMP/v4" ] && [ ! -s "$TMP/v6" ]; then
	echo "ipv64-blocklist: download empty, keeping the active sets" >&2
	exit 1
fi

elements() { # file -> "elements = { a, b, ... }" (nothing for an empty file)
	[ -s "$1" ] || return 0
	printf '\t\telements = { '
	paste -sd, "$1" | sed 's/,/, /g'
	printf ' }\n'
}

{
	echo "table inet ipv64"
	echo "delete table inet ipv64"
	echo "table inet ipv64 {"
	printf '\tset bl4 {\n\t\ttype ipv4_addr\n\t\tflags interval\n\t\tauto-merge\n'
	elements "$TMP/v4"
	printf '\t}\n\tset bl6 {\n\t\ttype ipv6_addr\n\t\tflags interval\n\t\tauto-merge\n'
	elements "$TMP/v6"
	printf '\t}\n'
	# drop traffic FROM listed networks to this host and to forwarded/NATed hosts (routers, Docker)
	printf '\tchain input {\n\t\ttype filter hook input priority -10; policy accept;\n\t\tip saddr @bl4 counter drop\n\t\tip6 saddr @bl6 counter drop\n\t}\n'
	printf '\tchain forward {\n\t\ttype filter hook forward priority -10; policy accept;\n\t\tip saddr @bl4 counter drop\n\t\tip6 saddr @bl6 counter drop\n\t}\n'
	echo "}"
} > "$TMP/ipv64.nft"

nft -f "$TMP/ipv64.nft"
echo "ipv64-blocklist: $LIST loaded ($(wc -l < "$TMP/v4") IPv4, $(wc -l < "$TMP/v6") IPv6 entries)"

iptables and ipset

For systems that still use iptables. The script fills one set each for IPv4 and IPv6 (ipv64-v4, ipv64-v6) via ipset restore, swaps it in and adds the DROP rules only once: in INPUT, FORWARD and, if present, Docker's DOCKER-USER chain.

apt install -y ipset iptables curl
curl -fsSo /usr/local/sbin/ipv64-blocklist-ipset.sh https://ipv64.net/blocklists/tools/ipv64-blocklist-ipset.sh
chmod +x /usr/local/sbin/ipv64-blocklist-ipset.sh
/usr/local/sbin/ipv64-blocklist-ipset.sh firehole_l1
echo '17 */4 * * * root /usr/local/sbin/ipv64-blocklist-ipset.sh firehole_l1 >/dev/null' > /etc/cron.d/ipv64-blocklist
echo '@reboot root sleep 30 && /usr/local/sbin/ipv64-blocklist-ipset.sh firehole_l1 >/dev/null' >> /etc/cron.d/ipv64-blocklist

The @reboot line restores sets and rules after a restart; ipset-persistent is not needed. Docker recreates its chains when the daemon restarts – run the script once more afterwards.

The script (https://ipv64.net/blocklists/tools/ipv64-blocklist-ipset.sh). It creates the sets as hash:net with up to 1,048,576 entries, fills a new set and swaps it with the active one using ipset swap; if the IPv4 download is empty, it stops and keeps the active set:

#!/bin/sh
# IPv64.net blocklist for iptables + ipset (IPv4 + IPv6) - https://ipv64.net/v64_blocklist_integration_guide
# Usage: ipv64-blocklist-ipset.sh [list]   (default: firehole_l1, see https://ipv64.net/v64_blocklists)
# Run as root. Loads the list into a new set and swaps it in; on a failed download the old set stays active.
set -eu
LIST="${1:-firehole_l1}"
BASE="https://ipv64.net/blocklists"
TMP="$(mktemp -d)"
trap 'rm -rf "$TMP"' EXIT

for v in 4 6; do
	fam=inet; ipt=iptables
	[ "$v" = 6 ] && { fam=inet6; ipt=ip6tables; }
	set="ipv64-v$v"; new="ipv64-v$v-new"
	curl -fsS --max-time 120 -o "$TMP/raw" "$BASE/ipv64_blocklist_v${v}_${LIST}.txt"
	grep -E '^[0-9A-Fa-f:.]+(/[0-9]{1,3})?$' "$TMP/raw" > "$TMP/list" || true
	n=$(wc -l < "$TMP/list")
	if [ "$n" -eq 0 ] && [ "$v" = 4 ]; then
		echo "ipv64-blocklist: IPv4 download empty, keeping the active set" >&2
		exit 1
	fi
	ipset create -exist "$set" hash:net family "$fam" maxelem 1048576
	ipset destroy "$new" 2>/dev/null || true
	{ echo "create $new hash:net family $fam maxelem 1048576"; sed "s/^/add $new /" "$TMP/list"; } | ipset restore -exist
	ipset swap "$new" "$set"
	ipset destroy "$new"
	# rules only once: -C checks whether the rule exists already
	for chain in INPUT FORWARD; do
		$ipt -C "$chain" -m set --match-set "$set" src -j DROP 2>/dev/null || $ipt -I "$chain" -m set --match-set "$set" src -j DROP
	done
	# Docker publishes ports through DOCKER-USER, not INPUT
	if $ipt -nL DOCKER-USER >/dev/null 2>&1; then
		$ipt -C DOCKER-USER -m set --match-set "$set" src -j DROP 2>/dev/null || $ipt -I DOCKER-USER -m set --match-set "$set" src -j DROP
	fi
	echo "ipv64-blocklist: $set ($LIST) loaded with $n entries"
done

pfSense: URL table as alias

1. Create the alias
   Firewall › Aliases › URLs › Add: Type URL Table (IPs), name e.g. IPv64_firehol, URL https://ipv64.net/blocklists/ipv64_blocklist_firehole_l1.txt, update frequency 1 day. Save and Apply Changes.
2. Rule on the WAN
   Firewall › Rules › WAN › Add (arrow up = top): Action Block, Address Family IPv4+IPv6, Protocol Any, Source: Single host or alias = IPv64_firehol, Destination any. Save and apply.
3. Optionally outbound
   Recommended for Spamhaus DROP: Firewall › Rules › LAN, Block rule at the top with Destination = the alias. This stops infected devices from contacting the listed networks.

Large lists (countries) may exceed Firewall Maximum Table Entries under System › Advanced › Firewall & NAT; raise the value if the alias stays empty. Diagnostics › Tables shows the loaded entries. pfSense checks URL tables once per day, so the live state of the v64 Blocklist brings no advantage here.

The guide does not cover the pfBlockerNG package; the text lists can be used anywhere a URL with one address or network per line is expected.

OPNsense: alias of type URL Table

1. Create the alias
   Firewall › Aliases › +: Type URL Table (IPs), name e.g. IPv64_firehol, refresh frequency 0 days 4 hours, content https://ipv64.net/blocklists/ipv64_blocklist_firehole_l1.txt. Save and Apply.
2. Rule on the WAN
   Firewall › Rules › WAN › +: Action Block, Direction in, TCP/IP Version IPv4+IPv6, Protocol any, Source = IPv64_firehol, Destination any. Save, drag the rule to the top and apply.
3. Optionally outbound
   On the LAN, a Block rule with Destination = the alias.

Firewall › Diagnostics › Aliases shows the loaded entries and the last update.

MikroTik RouterOS 7

IPv64.net provides ready-made import files for every list. Each file first removes its own old entries and then adds the current ones to the address list IPv64-<id>. The following script downloads the files for IPv4 and IPv6, imports them and is run by the scheduler every 6 hours. Paste it into the terminal (Winbox › New Terminal):

/system script add name=ipv64-blocklist policy=read,write,test source={
  :foreach v in={"v4";"v6"} do={
    :local f ("ipv64-" . $v . ".rsc")
    /tool fetch url=("https://ipv64.net/blocklists/v64_mikrotik_" . $v . "_firehole_l1.rsc") dst-path=$f
    :delay 2s
    /import file-name=$f
    /file remove $f
  }
}
/system scheduler add name=ipv64-blocklist interval=6h start-time=startup on-event="/system script run ipv64-blocklist"
/system script run ipv64-blocklist
/ip firewall raw add chain=prerouting src-address-list=IPv64-firehole_l1 action=drop comment="IPv64 blocklist"
/ipv6 firewall raw add chain=prerouting src-address-list=IPv64-firehole_l1 action=drop comment="IPv64 blocklist"

• The raw rules drop the traffic before connection tracking, for the router and the LAN. If you have other raw rules, move these to the top.
• Importing large lists takes a few seconds. /ip firewall address-list print count-only where list=IPv64-firehole_l1 shows the number of entries.
• For another list, replace firehole_l1 everywhere with its ID.
• For the live state of the v64 Blocklist, use the URL ("https://ipv64.net/blocklists/live/<token>/v64_mikrotik_" . $v . "_v64.rsc"), the list name IPv64-v64 and interval=30m.

Older import files wrote all lists into the shared address list IPv64-Blocklist. If you still have such entries, clean them up like this:

/ip firewall address-list remove [find list=IPv64-Blocklist]
/ipv6 firewall address-list remove [find list=IPv64-Blocklist]

You can run Honeypot64 itself as a container on MikroTik – see Node64 docs: MikroTik RouterOS.

Business firewalls: Palo Alto, FortiGate, Sophos

These firewalls load a plain text list from a URL themselves. The steps follow the vendor documentation (PAN-OS 11.1, FortiOS 7.6, Sophos Firewall 21.5) and have not been tested live by IPv64.net. The examples use the v64 Blocklist; every other list works the same way. For the live state, enter the address with your list token. Set the update interval to 30 minutes or more – FortiGate refreshes every 5 minutes by default.

Palo Alto Networks (PAN-OS): External Dynamic List

1. Create the list
   Objects › External Dynamic Lists › Add: name e.g. IPv64_v64, Type IP List, Source https://ipv64.net/blocklists/ipv64_blocklist_v64.txt, optionally a Certificate Profile with the CA of the ipv64.net certificate (server authentication), Check for updates Hourly. OK.
2. Create the rule
   Policies › Security › Add: on the Source tab the list as Source Address (inbound from the Internet zone), Action Deny. Move the rule above your allow rules. For outbound traffic, use the list as Destination Address in a second rule.
3. Apply
   Commit. Import Now on the list fetches it immediately.

PAN-OS accepts IPv4 and IPv6 addresses, ranges and networks. All IP lists together may hold 50,000 addresses on most models (150,000 on PA-3200, PA-5200 and PA-7000); see List Capacities under Objects › External Dynamic Lists. If the server cannot be reached, the firewall keeps the last list.

Fortinet FortiGate (FortiOS): IP address feed

1. Create the feed
   Security Fabric › External Connectors › Create New, under External Feeds (older versions: Threat Feeds) choose IP Address: name e.g. IPv64_v64, URL of external resource https://ipv64.net/blocklists/ipv64_blocklist_v64.txt, Refresh Rate 60 minutes. OK.
2. Create the rule
   Policy & Objects › Firewall Policy: rule from the WAN interface with Source = the feed (section IP ADDRESS FEED), Action DENY, above the allow rules. For outbound traffic, a rule with the feed as Destination.

The same on the CLI, plus a local-in policy that also protects the FortiGate itself (VPN, admin access); use a free policy number:

config system external-resource
    edit "IPv64_v64"
        set type address
        set resource "https://ipv64.net/blocklists/ipv64_blocklist_v64.txt"
        set refresh-rate 60
        set server-identity-check full
    next
end
config firewall local-in-policy
    edit 100
        set intf "any"
        set srcaddr "IPv64_v64"
        set dstaddr "all"
        set service "ALL"
        set schedule "always"
    next
end

FortiOS accepts IPv4 and IPv6 addresses, ranges and networks, one per line. server-identity-check checks the server certificate (default none).

Sophos Firewall: Third-party threat feeds

1. Create the feed
   Active threat response › Third-party threat feeds › Add: name e.g. IPv64_v64, Action Block, Indicator type IPv4 address, External URL https://ipv64.net/blocklists/ipv64_blocklist_v4_v64.txt, Authorization No authentication, Validate server certificate on, Polling interval 1 hour (or 30 minutes). Save.
2. Load
   Synchronize now loads the feed immediately; check the log for matches.

Requires the licence for third-party threat feeds (Xstream Protection). According to Sophos, these feeds take single IPv4 addresses only, no IPv6, ranges or networks. The IPv64.net lists contain networks and write single addresses as /32; whether Sophos accepts these entries has not been tested. XGS 87, 88 and 107 offer only 24 hours, 7 days or 30 days as polling interval.

Web server and reverse proxy: nginx and CrowdSec

nginx

For a web server or reverse proxy without firewall access. The geo module checks networks efficiently, even with tens of thousands of entries. Blocked clients get HTTP 403.

1. Fetch the list as a geo file (via cron, e.g. every 4 hours):

curl -fsS https://ipv64.net/blocklists/ipv64_blocklist_blocklistde_all.txt \
  | awk '/^[0-9A-Fa-f:.]+(\/[0-9]+)?$/ {print $1" 1;"}' > /etc/nginx/ipv64-geo.conf.new \
  && [ -s /etc/nginx/ipv64-geo.conf.new ] && mv /etc/nginx/ipv64-geo.conf.new /etc/nginx/ipv64-geo.conf \
  && nginx -t -q && systemctl reload nginx

2. Use it in nginx.conf:

http {
    geo $ipv64_blocked { default 0; include /etc/nginx/ipv64-geo.conf; }
    server {
        # ...
        if ($ipv64_blocked) { return 403; }
    }
}

Behind Cloudflare or another proxy, configure real_ip_header first, otherwise nginx sees the proxy address. Ready-made nginx snippets for attack paths and user agents of attack tools are available as text lists from the honeypot.

CrowdSec

Import the list as decisions; all your bouncers (firewall, nginx, Traefik …) apply it. The decisions expire after 6 hours, so import again every 4 hours via cron. Tested with CrowdSec 1.6:

curl -fsSo /tmp/ipv64.txt https://ipv64.net/blocklists/ipv64_blocklist_firehole_l1.txt \
  && cscli decisions import -i /tmp/ipv64.txt --format values --duration 6h --reason ipv64-blocklist

Live state of the v64 Blocklist with list token

The normal addresses deliver the v64 Blocklist as a daily state (up to 24 hours old), free for everyone. IPv64.net updates the live state every 30 minutes. It is available to contributors (one of your Honeypot64 sensors reported in the last 7 days) and to all account classes except the free one (Free, sometimes called “Standard” on ipv64.net).

1. Create a token
   While logged in under Honeypot64 › List token (ipv64.net/honeypot/token.php). The list token has 32 characters (letters and digits), is separate from the API key and only allows fetching the lists. The page also shows whether you get the live state.
2. Enter the address
   The same file names as usual, with the token in the path – only for the v64 Blocklist: ipv64_blocklist_v64.txt, ipv64_blocklist_v4_v64.txt, ipv64_blocklist_v6_v64.txt, v64_mikrotik_v4_v64.rsc and v64_mikrotik_v6_v64.rsc (MikroTik address list IPv64-v64).

https://ipv64.net/blocklists/live/YOUR_LIST_TOKEN/ipv64_blocklist_v4_v64.txt

• The token is part of the path because many firewalls cannot send headers. No login is needed; every firewall that accepts a URL can use it.
• Keep the token secret like a password: not in screenshots, tickets or shared configurations. If it leaks, create a new one; the old one stops working immediately.
• Fetch every 30 minutes or less often; the live state does not change more often. Per token (it applies to the whole account, all nodes together) at most 60 requests per 5 minutes are allowed, otherwise 429 with Retry-After.

Where the firewall only loads the URL once a day anyway (e.g. pfSense), the live state brings no advantage.

List token via API

Programs fetch the token with the API key via API v2: GET https://ipv64.net/api/v2/honeypot/list-token. If there is no token yet, IPv64.net creates one; an existing token stays unchanged (the request does not create a new one). The response contains token, live (whether your account currently gets the live state) and base, the base address for the file names:

curl -s -H "Authorization: Bearer YOUR_API_KEY" https://ipv64.net/api/v2/honeypot/list-token

{"data": {"token": "YOUR_LIST_TOKEN", "live": true, "base": "https://ipv64.net/blocklists/live/YOUR_LIST_TOKEN/"}}

PROXY64 in Node64 does the same. Errors: 401 without a valid API key, 429 for too many requests.

Node64: PROXY64, Honeypot64 and firewall helper

Node64 is the IPv64.net home network container. It uses the blocklists directly, without entering addresses by hand:

• PROXY64 (reverse proxy): under PROXY64 → Access lists you switch on the IPv64 blocklists with one click for the whole reverse proxy. The selection comes from the index.json; new lists appear without an update. PROXY64 refreshes the lists every 30 minutes; you define exceptions yourself. PROXY64 loads the v64 Blocklist live as soon as your account is entitled: without a token entered by hand, it fetches the list token itself with the central API key (list token via API); a token entered by hand takes precedence. Details: Node64 docs: ipv64 blocklists and live lists with list token.
• Honeypot64: with your own sensor you contribute to the v64 Blocklist – and as a contributor you get the live state. The sensor reports to IPv64.net every 10 minutes with the API key of your account. It also works anonymously without an account (no API key) – your sensor then counts together with all other anonymous ones as a single account, and the live state is only available with an account. A sensor changes its account (another API key, or anonymous ↔ with key) only from the network of its last report or after 24 hours without a report – knowing the sensor ID alone is not enough to take it over. Setup: Node64 docs: Honeypot64, reporting: Reporting to ipv64.
• Firewall helper (nftables): in the mode without a web interface, Node64 adds the v64 Blocklist or other lists from the index.json to the host's nftables firewall itself, with exceptions for your own addresses. See Node64 docs: firewall helper.

Older “v64 Blocker Nodes”

IPv64.net still has the page v64 Blocker Nodes with the status “still under development”. Reporting single IPs via the API, as described there, is switched off in the current code. Contributions to the v64 Blocklist now come from Honeypot64 sensors; the overview IPv64 Secure no longer mentions the blocker nodes.

Testing and troubleshooting

Is the list loaded?

How many entries a list currently has and when it was last renewed is shown in the index.json (count, updated) and on ipv64.net/v64_blocklists.

Is my own IP blocked?

• v64 Blocklist: the IP lookup shows whether and why an address is listed and offers to check your own address directly. Via API: curl https://ipv64.net/api/v2/threat/ip/192.0.2.10 (without API key with a strict limit per client IP). If the address is listed by mistake, submit a release request there.
• Other lists: the IP lookup only checks the v64 Blocklist. Whether an address is in a loaded set can be checked locally, e.g. with ipset test ipv64-v4 192.0.2.10 or nft get element inet ipv64 bl4 '{ 192.0.2.10 }'. Report addresses listed by mistake to the respective source project; with the next update they disappear from the IPv64 lists as well.
• Early warning: at ipv64.net/honeypot/watch.php you add your public networks and get an e-mail when an address from them shows up at the Honeypot64 sensors – with service, port and type of the attacks. IPv64.net watches your DynDNS addresses there automatically; for them you only get hits when the address is on the v64 blocklist (without port and rule, last sighting only to the day).

I locked myself out

• Remove the block via the console or another way in: nft delete table inet ipv64, or delete the rule added by the ipset script (iptables -D INPUT -m set --match-set ipv64-v4 src -j DROP, for IPv6 the same with ip6tables and ipv64-v6). Then delete the cron file /etc/cron.d/ipv64-blocklist, otherwise the block comes back with the next run.
• On pfSense, OPNsense and the business firewalls, add an allow rule for your fixed addresses (office, VPN, monitoring) above the block rule.
• In Node64, add your own addresses as exceptions (PROXY64) or to NODE64_FIREWALL_ALLOW (firewall helper).

Common errors

• “download empty, keeping the active sets”: the nftables script got no entries for IPv4 and IPv6 (the ipset script: for IPv4) and keeps the previous list active. The cause is a network error, a wrong ID – or a list that really is empty at the moment, which can happen with the v64 Blocklist. Check the address with curl -fsS https://ipv64.net/blocklists/ipv64_blocklist_v4_<id>.txt | head.
• Alias stays empty (pfSense): the list is larger than Firewall Maximum Table Entries – raise the value.
• Block has no effect with Docker: Docker publishes ports via DOCKER-USER/FORWARD, not INPUT. Both scripts filter there too; after a Docker restart, run the ipset script again.
• nginx blocks nothing or everyone: behind a proxy, without real_ip_header nginx only sees the proxy address.
• Live fetch returns X-IPv64-List: daily: your account currently has no live entitlement (no sensor report in the last 7 days and an account class without live). You still get the daily state.
• 404 on a live fetch: the token is wrong, was recreated or deleted – enter the address with the current token.
• 404 for v64_ssh, v64_web and the like: the sub-lists of the v64 Blocklist no longer exist, neither as daily state nor live. Switch to v64 (see One list: v64).
• 429: fetched too often; set the interval to 30 minutes or more. The limit applies to all devices of your account together. PROXY64 (from 1.33.1) keeps the existing state on 429 without an error.
• Released address still blocked: it drops out of the live state with the next evaluation (every 30 minutes), out of the daily state only with the next daily update – and out of your firewall only with its next fetch.

More help is available in the v64.tech forum and in the FAQ.

Found a mistake or missing something? Tell us in the v64.tech forum. · Updated: 2026-11-02