I created a test version of a RPZ add-on and I am looking for feedback

steven · 6 August 2025 10:55

Don’t get me wrong, but after following this for over a year and this brilliant innovation still not being generally available, I’m not surprised that Ipfire 3 is taking so long.

I get the impression that some members of the dev team take themselves too seriously and love to harp on trivialities or are extreme worriers. Just because something will change sometime, somehow, and somewhere in the future, this add-on would have been working perfectly for a year now.

Of course, this impression could be misleading, because I might not be able to understand everything, but I can’t find any comprehensible reason, other than bureaucracy, why the add-on isn’t available yet. And for the people who ultimately use it productively, we can expect a little personal responsibility.

I think Jon deserves a lot of respect for putting himself through this process for so long.

bbitsch · 6 August 2025 12:26

Not to forget Erik. He made a ‘nice’ infrastructure for RPZ lists.

ummeegge · 6 August 2025 20:26

And also Leo, Bernhard, Adolf and for sure also Michael and the whole development team but also the community, all made a great job in this specific project and are simply engaged to bring on the best they can for a new and useful project.

A short one: In general, there is no reason to feel ashamed of something but a reason to go further if someone like the way or did a lot of work in it and support it to make it even better.

haven´t found this part but i remembered it which was the initial intension to start a beneath development and support this here, thanks for digging it out .

All lists on the repo includes SOA entries even if the original source does not have one so it respects the Unbound update mechanisms.

But there are news .

The infrastructure can be made even better and bigger, let´s say the concept was ready to publish but the content can find more development so again, if someone have sources of good, categorized lists, critics, bugs, intensions for new ideas or/and even flowers, feel free to express them.

Am now in holidays and wish you all a good time, see you all.

Best,

Erik

peppetech · 7 August 2025 06:02

We should also credit the OG - jpgpi250 Peter Russel a DNS sinkhole guru whose inspiration started this addon. .

Time flew by so fast. Almost three years ago, my appliance got swallowed up by jpgpi250’s DoH sinkhole and after I mentioned it over here, Jon just took it on full speed.

Erik ,this is an amazing resource. Good sources of bloclists are slowly dying off or disappearing.

Maybe it’s time to start choosing a name for the addon:
Let me start with some suggestions :

-DNS Sinkhole
-P|hole™ Killa
-Filter Everything but the Kitchen Sink®

roberto · 8 August 2025 15:05

Hi guys!!!.

My small contribution to improving this add-on. I’ve generated the corresponding RPZ report in the “Reports” add-on.

I hope you like it.

Bye.

roberto · 23 September 2025 05:51

Hello.

I have a big question. What’s the latest version of this add-on?.

Thanks.

rjschilt · 23 September 2025 06:06

This page www.ipfire.org - Response Policy Zones (RPZ) :

…suggests 0.1.18

hjkl · 13 November 2025 14:32

Hello,
I have repeated the test for blocking DoH with RPZ (initially done in August 2024 and it was a success!): today the RPZ fails to block Google and Cloudflare DoH servers

Any solutions?

Important:

HagheziDOH	https://raw.githubusercontent.com/hagezi/dns-blocklists/main/rpz/doh.txt

and

Name	URL	Remark	Action
BlockDOH_jpgpi250	https://raw.githubusercontent.com/jpgpi250/piholemanual/master/DOH/DOH.rpz

are up to date in my system:

Haghezi

; Last modified: 11 Nov 2025 10:34 UTC
; Version: 2025.1111.1034.04
; Syntax: RPZ
; Number of entries: 6772

BlockDOH_jpgpi250:

; (o)DoH Response Policy Zones (RPZ)
; Last updated: 2025-11-13 04:11:21 (UTC)
;
; See https://jpgpi250.github.io/piholemanual/doc/Unbound%20response%20policy%20zones.pdf

RPZ logs:

Nov 13 16:27:22 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] dns.google.com. rpz-nxdomain a.b.c.d@41181 dns.google.com. A IN
Nov 13 16:27:22 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] cloudflare-dns.com. rpz-nxdomain a.b.c.d@55941 cloudflare-dns.com. A IN
Nov 13 16:27:22 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] doh.powerdns.org. rpz-nxdomain a.b.c.d@35943 doh.powerdns.org. A IN
Nov 13 16:27:22 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] doh.securedns.eu. rpz-nxdomain a.b.c.d@51735 doh.securedns.eu. A IN
Nov 13 16:27:22 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] doh.blahdns.com. rpz-nxdomain a.b.c.d@34675 doh.blahdns.com. A IN
Nov 13 16:27:22 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] dns.rubyfish.cn. rpz-nxdomain a.b.c.d@36743 dns.rubyfish.cn. A IN
Nov 13 16:27:22 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] commons.host. rpz-nxdomain a.b.c.d@46115 commons.host. A IN
Nov 13 16:27:42 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] doh.securedns.eu. rpz-nxdomain a.b.c.d@45707 doh.securedns.eu. A IN
Nov 13 16:27:42 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] doh.powerdns.org. rpz-nxdomain a.b.c.d@56817 doh.powerdns.org. A IN
Nov 13 16:27:42 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] dns.rubyfish.cn. rpz-nxdomain a.b.c.d@50657 dns.rubyfish.cn. A IN
Nov 13 16:27:42 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] doh.blahdns.com. rpz-nxdomain a.b.c.d@45674 doh.blahdns.com. A IN

jon · 13 November 2025 16:57

I hate to say this but it works A-OK for me…

Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] cloudflare-dns.com. rpz-nxdomain 192.168.60.211@53196 cloudflare-dns.com. HTTPS IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] cloudflare-dns.com. rpz-nxdomain 192.168.60.211@53517 cloudflare-dns.com. A IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] dns.google.com. rpz-nxdomain 192.168.60.211@50888 dns.google.com. HTTPS IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] dns.google.com. rpz-nxdomain 192.168.60.211@62853 dns.google.com. A IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] dns9.quad9.net. rpz-nxdomain 192.168.60.211@59048 dns9.quad9.net. HTTPS IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] dns9.quad9.net. rpz-nxdomain 192.168.60.211@54442 dns9.quad9.net. A IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] doh.powerdns.org. rpz-nxdomain 192.168.60.211@58033 doh.powerdns.org. HTTPS IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] doh.powerdns.org. rpz-nxdomain 192.168.60.211@56780 doh.powerdns.org. A IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] doh.blahdns.com. rpz-nxdomain 192.168.60.211@59152 doh.blahdns.com. HTTPS IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] doh.blahdns.com. rpz-nxdomain 192.168.60.211@64205 doh.blahdns.com. A IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] dns.rubyfish.cn. rpz-nxdomain 192.168.60.211@54922 dns.rubyfish.cn. HTTPS IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] dns.rubyfish.cn. rpz-nxdomain 192.168.60.211@55964 dns.rubyfish.cn. A IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] commons.host. rpz-nxdomain 192.168.60.211@57427 commons.host. HTTPS IN
Nov 13 10:46:17 ipfire unbound: [2165:0] info: rpz: applied [DOHblockHZ] commons.host. rpz-nxdomain 192.168.60.211@62073 commons.host. A IN

RPZ is blocking in your logs (see the rpz-nxdomain) . . .

Nov 13 16:27:22 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] dns.google.com. rpz-nxdomain a.b.c.d@41181 dns.google.com. A IN
Nov 13 16:27:22 ipfire unbound: [7681:0] info: rpz: applied [BlockDOH_jpgpi250] cloudflare-dns.com. rpz-nxdomain a.b.c.d@55941 cloudflare-dns.com. A IN

. . . and so I am guessing something else is allowing the connection.

I don’t have a good guess for a fix. As a wild guess, maybe firewall rules?

jon · 13 November 2025 18:12

I think it is related to Force DNS. Force DNS should be enabled.

I see what you see when Force DNS is disabled. Are you using this?

raffe · 14 November 2025 08:00

Any news on when RPZ add-on will be released? What more is needed to make it so? With 350+ replies (more than any other thread) and 5.1k views for this thread, it seems quite popular

jon · 14 November 2025 20:28

No news is bad news.

Michael & the Core Devs do not believe RPZ is a good fit. I personally disagree. So those that are interested in RPZ would need to convince Michael & the Core Devs.

Once the weather turns cold and I cannot longer play/work outside, I’ll add a few changes (bug fixes from way above in the thread). And then I will publish them.

If there is still interest in RPZ (even if it is not “official”) then there are a few updates/enhancements we will publish.

Let us know your thoughts…

rjschilt · 14 November 2025 23:06

Hi @jon

Personally I would like to see this addon included in the official collection of IPF addons. You have done an amazing job. If only to give IPF users a choice in method how they wish to block rogue sites.

If I remember correctly one of the team has given reasons why it was being overlooked…. are you able to share a link to that post where they give their reasons… I have searched but unable to find.

bloater99 · 14 November 2025 23:38

Anything that can add to network security by proactively blocking malicious sites is a good thing. Especially in corporations where one bad click can lead to a ransomware attack that can take an entire company down. I am all for an official RPZ add-on!

tratru · 15 November 2025 15:28

Hi, I don’t understand the developers’ opposition. Since it’s a package, it will only be installed by those who find it useful.

jon · 15 November 2025 17:56

This is a poor way for me to state the issue. I was trying to be gentle with my words…

This is a very long thread:

Any reply that is not me (or Bernhard) is a “given reasons”.

Side note:
To me the conversation is a bit hard to read with all of the replies and re-replies that are in gray.

Skip over the grey replies by scrolling WAY down and click next.

hjkl · 15 November 2025 19:03

Hi Jon,
No, I use the FW rules inside Meraki AP - all my clients are connected to Meraki AP and FW rules for controlling DNS traffic are in Meraki. More, Meraki AP are using NAT - all wifi clients are in a /8 IP range and are unaware of the ipfire - all is managed by Meraki - DHCP, DNS, all being provided by Meraki to the wifi clients.

I think I found a potential issue: the IPFIRE DHCP (!) gives to Meraki AP two DNS servers:

as Primary is provides the IPFIRE IP (i.e. unbound)
as Secondary an old DNS IP used by unbound as Upstream DNS (defined in the page https://a.b.c.d:444/cgi-bin/dns.cgi

So Meraki AP receives 2 DNS servers and (I assume!) it might use both of them to solve the DNS requests from Wifi clients.

Digram looks like this

Wifi Client in Isolation mode → Meraki AP in NAT mode and with DNS Proxy receiving its LAn setting from IPfire DHCP → IPFIRE with DHCP sending to Meraki 2 DNS servers: first being IPFIRE GREEN IP and secondary being an old (no longer used!) upstream DNS server used by unbound. IPFIRE unbound service uses a different upstream DNS server from the one DHCP sends to Meraki.

How Unbound is configured

And Meraki FW allowed traffic to several DNS servers including the ones you see above, but, again, the wifi client do not receive any of these from Meraki - Meraki gives them an internal IP where its DNS proxy listen

As soon as I removed the Meraki Allow FW rule to the Secondary DNS server provided by IPFIRE DHCP to Meraki AP the DoH test was successful (w/o any IPFIRE FW rule to block DNS or DoT)

DNS over HTTPS

This is weird because Meraki AP still has knowledge about second DNS server (provided by IPFIRE DHCP!) but the wifi clients no longer can access it directly although those clients are unaware of that server - those clients receive a Meraki IP address where Meraki DNS proxy listen.

And, now the RPZ logs show much more RPZ block lines:

Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] doh.securedns.eu. rpz-nxdomain Meraki.LAN.IP@58604 doh.securedns.eu. HTTPS IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``doh.powerdns.org``. rpz-nxdomain Meraki.LAN.IP@58817 ``doh.powerdns.org``. HTTPS IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``doh.powerdns.org``. rpz-nxdomain Meraki.LAN.IP@34775 ``doh.powerdns.org``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``doh.blahdns.com``. rpz-nxdomain Meraki.LAN.IP@35244 ``doh.blahdns.com``. HTTPS IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``doh.blahdns.com``. rpz-nxdomain Meraki.LAN.IP@33639 ``doh.blahdns.com``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``cloudflare-dns.com``. rpz-nxdomain Meraki.LAN.IP@60338 ``cloudflare-dns.com``. HTTPS IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``cloudflare-dns.com``. rpz-nxdomain Meraki.LAN.IP@36869 ``cloudflare-dns.com``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``dns.google.com``. rpz-nxdomain Meraki.LAN.IP@50883 ``dns.google.com``. HTTPS IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``dns.google.com``. rpz-nxdomain Meraki.LAN.IP@57876 ``dns.google.com``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``doh.powerdns.org``. rpz-nxdomain Meraki.LAN.IP@47097 ``doh.powerdns.org``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``doh.blahdns.com``. rpz-nxdomain Meraki.LAN.IP@38068 ``doh.blahdns.com``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``cloudflare-dns.com``. rpz-nxdomain Meraki.LAN.IP@48399 ``cloudflare-dns.com``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``dns.google.com``. rpz-nxdomain Meraki.LAN.IP@55758 ``dns.google.com``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] doh.securedns.eu. rpz-nxdomain Meraki.LAN.IP@51173 doh.securedns.eu. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``dns9.quad9.net``. rpz-nxdomain Meraki.LAN.IP@36165 ``dns9.quad9.net``. HTTPS IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``dns9.quad9.net``. rpz-nxdomain Meraki.LAN.IP@41770 ``dns9.quad9.net``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``dns9.quad9.net``. rpz-nxdomain Meraki.LAN.IP@60532 ``dns9.quad9.net``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``doh.blahdns.com``. rpz-nxdomain Meraki.LAN.IP@59449 ``doh.blahdns.com``. HTTPS IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``doh.blahdns.com``. rpz-nxdomain Meraki.LAN.IP@39767 ``doh.blahdns.com``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``doh.powerdns.org``. rpz-nxdomain Meraki.LAN.IP@34307 ``doh.powerdns.org``. HTTPS IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``doh.powerdns.org``. rpz-nxdomain Meraki.LAN.IP@34259 ``doh.powerdns.org``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``cloudflare-dns.com``. rpz-nxdomain Meraki.LAN.IP@36576 ``cloudflare-dns.com``. HTTPS IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``cloudflare-dns.com``. rpz-nxdomain Meraki.LAN.IP@53682 ``cloudflare-dns.com``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``dns.google.com``. rpz-nxdomain Meraki.LAN.IP@51941 ``dns.google.com``. HTTPS IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] ``dns.google.com``. rpz-nxdomain Meraki.LAN.IP@39313 ``dns.google.com``. A IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] doh.securedns.eu. rpz-nxdomain Meraki.LAN.IP@35359 doh.securedns.eu. HTTPS IN
Nov 15 20:53:51 black-x86-64 unbound: [20217:0] info: rpz: applied [BlockDOH_jpgpi250] doh.securedns.eu. rpz-nxdomain Meraki.LAN.IP@57480 doh.securedns.eu. A IN

Late edit - original Meraki FW rules - the ones marked with a red X were removed and that solved the DoH test!

jon · 15 November 2025 20:57

The Secondary DNS item will cause the bypass:

Plus not having the Primary DNS and Secondary DNS pointing at the IPFire Device Green zone.

My IPFire Device is 192.168.60.1 and that is what I use for the Primary DNS server IP Address:

hjkl · 15 November 2025 21:42

I am almost certain that Meraki Ap has a way to bypass RPZ.

I added the FW rule from guide www.ipfire.org - Force clients to use IPFire DNS Server

I have removed secondary DNS from DHCP and rebooted both Ipfire and then Meraki AP and then wifi client.

Wifi Client still manages to get a response for community.ipfire.org in the page DNS over HTTPS

Despite the fact that Meraki AP gets only IPFIRE Green IP for DNS and the Ipfire rule that redirects DNS queries to unbount this does not stops the Meraki AP: somehow the AP gets from unbound the upstream DNS server and directly interrogates it:

Here is a conntrack proof for that: Meraki AP learned somehow about the IP address of the upstream DNS server Ipfire uses: 86.54.11.13. This IP is listed in https://ipfire:444/cgi-bin/dns.cgi

[UPDATE] tcp      6 60 SYN_RECV src=Meraki.LAN.IP dst=86.54.11.13 sport=40609 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40609
[UPDATE] tcp      6 300 ESTABLISHED src=Meraki.LAN.IP dst=86.54.11.13 sport=40609 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40609 [ASSURED]
[NEW] tcp      6 120 SYN_SENT src=Meraki.LAN.IP dst=86.54.11.13 sport=40611 dport=53 [UNREPLIED] src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40611
[UPDATE] tcp      6 60 SYN_RECV src=Meraki.LAN.IP dst=86.54.11.13 sport=40611 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40611
[UPDATE] tcp      6 120 FIN_WAIT src=Meraki.LAN.IP dst=86.54.11.13 sport=40609 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40609 [ASSURED]
[UPDATE] tcp      6 30 LAST_ACK src=Meraki.LAN.IP dst=86.54.11.13 sport=40609 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40609 [ASSURED]
[UPDATE] tcp      6 300 ESTABLISHED src=Meraki.LAN.IP dst=86.54.11.13 sport=40611 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40611 [ASSURED]
[UPDATE] tcp      6 120 TIME_WAIT src=Meraki.LAN.IP dst=86.54.11.13 sport=40609 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40609 [ASSURED]
[NEW] tcp      6 120 SYN_SENT src=Meraki.LAN.IP dst=86.54.11.13 sport=40613 dport=53 [UNREPLIED] src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40613
[UPDATE] tcp      6 60 SYN_RECV src=Meraki.LAN.IP dst=86.54.11.13 sport=40613 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40613
[UPDATE] tcp      6 300 ESTABLISHED src=Meraki.LAN.IP dst=86.54.11.13 sport=40613 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40613 [ASSURED]
[UPDATE] tcp      6 120 FIN_WAIT src=Meraki.LAN.IP dst=86.54.11.13 sport=40611 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40611 [ASSURED]
[UPDATE] tcp      6 30 LAST_ACK src=Meraki.LAN.IP dst=86.54.11.13 sport=40611 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40611 [ASSURED]
[UPDATE] tcp      6 119 TIME_WAIT src=Meraki.LAN.IP dst=86.54.11.13 sport=40611 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40611 [ASSURED]
[NEW] tcp      6 120 SYN_SENT src=Meraki.LAN.IP dst=86.54.11.13 sport=40615 dport=53 [UNREPLIED] src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40615
[UPDATE] tcp      6 60 SYN_RECV src=Meraki.LAN.IP dst=86.54.11.13 sport=40615 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40615
[UPDATE] tcp      6 300 ESTABLISHED src=Meraki.LAN.IP dst=86.54.11.13 sport=40615 dport=53 src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40615 [ASSURED]
[NEW] tcp      6 119 SYN_SENT src=Meraki.LAN.IP dst=86.54.11.13 sport=40617 dport=53 [UNREPLIED] src=IPFIRE.GREEN.IP dst=Meraki.LAN.IP sport=53 dport=40617

Also, I see these in logs - Meraki Ap does reach directly Google and Cloudflare servers?

Nov 12 17:43:08 black-x86-64 kernel: IPv4: martian source 8.8.8.8 from Meraki.LAN.IP, on dev green0

And these are really weird:

Nov 15 23:17:00 black-x86-64 kernel: IPv4: martian source 8.8.8.8 from 1.1.1.1, on dev green0
Nov 15 23:17:11 black-x86-64 kernel: IPv4: martian source 8.8.8.8 from 1.1.1.1, on dev green0
Nov 15 23:17:16 black-x86-64 kernel: IPv4: martian source 8.8.8.8 from 1.1.1.1, on dev green0
Nov 15 23:17:21 black-x86-64 kernel: IPv4: martian source 8.8.8.8 from 1.1.1.1, on dev green0
Nov 15 23:17:26 black-x86-64 kernel: IPv4: martian source 8.8.8.8 from 1.1.1.1, on dev green0

Result I see on DNS over HTTPS despite my efforts to force Meraki AP to use only IPFIRE Green IP for DNS (including the FW Redirect rule for DNS traffic):

jon · 16 November 2025 03:56

It is very difficult to guess without knowing more about your network and how the AP is connected to the IPFire box and Internet. A network diagram would be great.

And without knowing more about the DHCP Config it is also hard to guess. Is it possible to just blank part of the IP address? Like this: