IPFire Core Update 201 has been released for testing, allowing users to verify its new DNS-firewall feature works correctly without disrupting their network. To ensure this works as expected, you should update your system and reboot it afterwards so all services restart with the latest settings. When testing the DNS firewall, use tools like nslookup in a terminal on a client machine to confirm that malicious domains are being blocked; any other result indicates a problem that needs to be addressed. If issues persist after troubleshooting, it's likely due to a stale cache or rogue proxy setting on the client that needs to be flushed and corrected.

IPFire Core Update 201: How to Test the New DNS Firewall Without Messing Up Your Network

The new Core Update 201 has been released for testing. The article explains how to verify that the feature works correctly and what to do if it doesn’t.

Getting Started with the Update

Before installing anything, ensure the system is up to date. This guarantees that the new DNS‑firewall binary can communicate with the rest of IPFire’s stack without hitting a missing library error. After updating, reboot the appliance so all services restart in their latest form.

Confirming the Blocklist Is Being Pulled

The DNS‑firewall pulls its list through incremental zone transfers (IXFR). To make sure it is actually receiving updates, look at /var/log/ipfire/dnsfw.log and check for an entry like “IXFR transfer completed: 15,000 new domains.” A missing line here usually means the firewall did not start or the network path to the DNS server was blocked. If the log shows no IXFR activity, double‑check the firewall’s configuration file under /etc/ipfire/dnsfw.conf for correct host and port settings.

Testing DNS Resolution With a Known Malicious Domain

Open a terminal on a client machine that uses IPFire as its default gateway. Execute:

nslookup badexample.com

If the firewall is working, the response will be an NXDOMAIN status, essentially “I can’t find that domain.” If you still receive an IP address or a cached result, it means the DNS query bypassed the proxy, often because the client is configured to use another resolver or because IPv6 traffic slipped through.

Checking That No Traffic Leaves Your Network

After confirming NXDOMAIN behavior, capture packets on the LAN interface with tcpdump -i eth0 port 53. The output should show only queries and replies from IPFire itself. Any outgoing packets to external DNS servers indicate that the firewall is not intercepting traffic. A common pitfall: some routers still forward DNS over UDP/IPv6; disabling those in the router’s settings fixes the issue.

Why Pi‑hole or a Separate URL Filter Is Pointless Now

Many users keep Pi‑hole alongside IPFire to block URLs that the firewall misses. In reality, the new DNS‑firewall handles all of these requests out of the box; adding another layer just wastes resources and complicates troubleshooting when something goes wrong. Removing Pi‑hole frees up memory on low‑end appliances and eliminates duplicated rule sets.

Optional – Adjusting IDS Report Recipients

If the Intrusion Prevention System’s daily, weekly or monthly reports are going to the wrong mailbox, edit /etc/ipfire/ids.conf to point each line to the correct email address. A misconfigured recipient means you miss alerts about blocked threats—something no one wants.

Final Thought: What If It Still Fails?

If after all of that the DNS‑firewall still returns real IP addresses for known bad domains, the most likely culprit is a stale cache on the client or a rogue proxy setting. Flush the Windows resolver cache with ipconfig /flushdns and double‑check the client's network profile for any “Use a different DNS server” entry that points to an external service.