Firewall IP ranges

Locking down your backend so it only accepts connections from Infinity-Filter is the final step that makes the origin IP actually secret. As long as your firewall is open, anyone with the IP can bypass Infinity-Filter and hit you directly.

What you’ll do

1. Pull the canonical list of IPv4 subnets Infinity-Filter routes from.
2. Allowlist those subnets at the backend firewall (host + cloud provider).
3. Default-deny the Minecraft port for everyone else.
4. Allow ICMP for the Latency Test.

The canonical list

Infinity-Filter publishes the up-to-date list of IPv4 ranges as a plain-text endpoint, one CIDR per line:

https://www.infinity-filter.com/v4/

Fetching it with curl returns something like:

The format is deliberately minimal — one CIDR per line, no headers, no JSON — so you can pipe it straight into a shell loop. Wire it into your firewall provisioning and you stop having to track new subnets by hand.

iptables — host firewall

A defense-in-depth setup uses both PREROUTING -t mangle and INPUT rules. The script below pulls the list dynamically — re-run it on a cron and your firewall stays up to date.

#!/usr/bin/env bash
set -euo pipefail

# Accept established connections.
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow loopback.
iptables -A INPUT -i lo -j ACCEPT

# Allow ICMP — the panel's Latency Test needs it.
iptables -I INPUT -p icmp -j ACCEPT

# Allowlist every Infinity-Filter subnet (mangle + filter).
for RANGE in $(curl -fsSL https://www.infinity-filter.com/v4/); do
  iptables -t mangle -I PREROUTING -s "$RANGE" -j ACCEPT
  iptables -I INPUT -s "$RANGE" -j ACCEPT
done

# Default-deny everything else on the Minecraft port.
iptables -A INPUT -p tcp --dport 25565 -j DROP
iptables -A INPUT -p udp --dport 19132 -j DROP    # Bedrock, if used

# (Optional) drop everything else.
iptables -P INPUT DROP
iptables -P FORWARD DROP

Persist with iptables-save > /etc/iptables/rules.v4.

UFW — simpler host firewall

#!/usr/bin/env bash
set -euo pipefail

for RANGE in $(curl -fsSL https://www.infinity-filter.com/v4/); do
  ufw allow from "$RANGE" to any port 25565 proto tcp
done

# Allow ICMP (edit /etc/ufw/before.rules to keep icmp echo-request ACCEPT).

# Default-deny.
ufw default deny incoming
ufw default allow outgoing

ufw enable

Keeping it in sync with a cron

The cleanest setup re-syncs once a day so you never miss a new subnet:

# Re-apply the Infinity-Filter allowlist every day at 04:00.
0 4 * * * /usr/local/sbin/iptables-allowlist.sh > /dev/null 2>&1

Add a --retry and a small backoff to the curl line in production if you want extra robustness.

Cloud-provider firewall (Hetzner, OVH, AWS, …)

Apply the same allowlist at the cloud provider’s firewall layer. This is critical: if the host firewall is permissive but the cloud one isn’t, or vice versa, you have a hole.

Most provider UIs let you create an allow rule per source CIDR. Add one rule per IF subnet on the relevant ports (25565/tcp, 19132/udp if Bedrock, voice UDP port, Votifier port).

Most cloud providers also expose a Terraform/API for firewall rules — point that at https://www.infinity-filter.com/v4/ the same way and you get the cloud layer in sync too.

Verify the lockdown

From a machine not on Infinity-Filter (your home connection), try to connect to your backend by IP:

The IP times out (correct — your backend doesn’t accept connections from your IP). The IF hostname succeeds.

”My server is being attacked despite Infinity-Filter being active”

Almost always means the backend is being hit directly. Confirm:

• The backend firewall only accepts connections from IF’s IP ranges.
• The cloud-provider firewall also enforces the allowlist.
• A previous, unsecured IP isn’t still being announced via DNS somewhere.

If your origin IP was previously exposed, attackers may keep targeting it for months even after you stop announcing it. Consider rotating to a new IP if abuse persists.

ICMP corner case

The Latency Test needs ICMP. If you don’t want ICMP permanently open, allow it temporarily only when running the test, then re-block. See Latency Test.

What’s next