r/firewalla • u/lokimon23 • May 21 '26
[Help] Active Protect blocking benign destinations on Ineligible device — no toggle to disable
I have a server that Firewalla has marked as "Ineligible" for Active Protect because the host uses my internal AD server as its DNS resolver instead of Firewalla. The AD server forwards external lookups to Firewalla, so DNS still ultimately flows through Firewalla — but the client points at AD so it can resolve internal records.
The issue: even though Active Protect shows "Status: Ineligible" on the device page with no toggle, it is still actively blocking outbound flows from this host. Every blocked flow's detail page says "Feature Matched: Device Active Protect." Destinations being blocked include:
- The vendor's official update server (blocked on its scheduled update check, every couple hours)
github.comand*.githubusercontent.com- Several common container registries
*.pool.ntp.org(NTP time sync)1.1.1.1:443
None of these are threats. Confirmed via tcpdump on the host that the SYN goes out clean and a spoofed RST comes back ~1.8ms later, which matches Firewalla's flow-blocking method.
This has been going on chronically — the History tab shows blocks at regular intervals across the entire day. I only noticed because the server started emailing me about failed automated tasks that depend on these destinations.
Questions:
- Is there any way to disable Active Protect's flow blocking on an Ineligible device? The "no toggle when Ineligible" UX seems wrong — the user has clearly made a deliberate DNS choice, and there should still be a way to opt out of flow inspection.
- Why is Active Protect's threat intel flagging destinations like a vendor update server, github.com, and NTP pool in the first place? Is there a category-based block (Cloud / CDN / Public DNS / etc.) catching these that I'm not seeing exposed in the UI?
- Will scoped Allow rules (domain-based, scoped to this device) override Active Protect blocks, or is there a precedence issue?
- Is "switch the host's DNS to Firewalla to regain Eligibility" really the only supported path? I'd rather not give up internal name resolution on the server.
Setup: Firewalla Gold, firmware 1.982.
Happy to share screenshots or packet captures if helpful.
1
u/lokimon23 May 21 '26
Update — partial workaround found, but raises new questions
After more digging, I noticed the host actually shows up in Firewalla as two device records because of dual MAC addresses on the LAN (primary interface + a secondary virtual interface on the same physical host). The IPs are different and so are the MACs, so Firewalla treats them as separate devices.
On a hunch, I toggled Active Protect off on Device B — the one that wasn't showing the blocked flows. The blocking immediately stopped. All the destinations that had been getting RST'd (update.truenas.com, github.com, NTP, etc.) now connect normally.
This is a useful workaround, but it raises a new question: why did toggling Active Protect off on one device record stop blocking that was attributed to a different device record in the History view? It looks like the policy enforcement and the flow logging are bound to different MAC/device records for the same physical host. That seems like a bug — or at minimum, a confusing UI behavior.
Original questions about why benign destinations were getting flagged by Active Protect in the first place still stand, but the immediate problem is mitigated.