Zero trust Egress with CoreDNS - can't get it working
-
I have tried several times now to configure ZTE in CoreDNS, and I can't get it to work.
Version: 26.07-RC - 20260801-1756I know my CoreDNS basic settings are good, and it's the only DNS service on my pfSense and the default group is configured to forward to 9.9.9.9.
Clients are using it, and their requests are filtered as per my default group settings in CoreDNS (blocks, lists and so on).But when enabling ZTE and creating the required Firewall rules, I cannot get ANY hits on rules configured with the
"coredns_allow" or "coredns_deny" tags. Is there perhaps a typo in the documentation, and the tag has some capital letters or something?Is there any way to verify and see the lists CoreDNS creates for each client as they resolve names that are then added to their approved IP list?
-
I just double checked my reference setup I used when writing the docs and it's all still working as expected, traffic is hitting the expected rules when tagged as allowed or denied.
Make sure the rules match the screenshot and text in the recipe (especially that you used the Tagged field, not Tag and that no rules above those are matching/passing the traffic before they can reach the rules.
-
@jimp I’ll give it another go, but I’m 99.99% sure I did everything as supposed. The traffic simply passes the two rules that:
1: Allow all (if tagged “coredns_allow”)
2: reject all (if tagges “coredns_deny”)
And then either hits the Internet If I make a general allow rule at the bottom, or gets denied If I leave it to hit the default deny rule.So it seems no traffic is tagged even though ZTE clearly is enabled, and clients are hitting my CoreDNS instance.
The documentation says once ZTE is enabled all traffic is by default tagged with “coredns_deny” unless it is marked with allow because the client looked up the DNS name.
But no traffic is tagged with “coredns_deny” according to how traffic is evaluated on my rules.EDIT: It just does not work on my setup. It’s a scratch installed 1537 with no config except enabling CoreDNS and ZTE on LAN. But I cannot get any rule hits on any rules with either of those two tags.
-
Netgate 6100
Version 26.07It's not working for me either. I followed the procedure, and the traffic isn't hitting the rule at all; the counter always stays at 0. In addition, there's a port forwarding rule that forces traffic on port 53 to 127.0.0.1 to ensure all DNS queries go through CoreDNS. At first, I thought the problem was traffic shaping, so I removed everything, but it's unrelated.
Another point: the CPU usage is very high when I enable the Zero Trust option. I imagine it's because all the traffic is tagged (coredns_allow, coredns_deny). And if I disable Zero Trust, the router becomes completely unstable, and I have no choice but to reboot it.
-
My setup:
WAN:
1xPPPoELAN:
1xLAGG link using 2 interfaces (No address set)
8xVLAN set on the LAGG (All network have the DNS set to hit the router )General setting:
2xIPv4 public DNS server
DNS Resolution Behavior : local, fallback to remoteCoreDNS: , (Unbound Resolver, is disabled)
Port: 53- Default Group
2xIPv4 Public DNS - Example GUEST Group
2xIPv4 more restrictive public DNS server - No Fallback
Port Forwarding:
1xRule to redirect all query on port 53 target IP 127.0.0.1Firewall Rules (Tested on the Guest network) :
1xPass all traffic on port 53 only
1xPass all traffic with the tag cordns_allow in the Tagged box
1xBlock All trafic with the tag cordns_deny - Default Group
-
J Jim Coogan referenced this topic on
-
I took another crack ar ZTE after they patched the CoreDNS failing on firewall boot/reboot Issue I had and I'm still having no luck either.
-
@felixm223pfsense Try with the following patch:
diff --git a/src/etc/inc/filter.inc b/src/etc/inc/filter.inc index 4dc9a603fb..89f6f60c96 100644 --- a/src/etc/inc/filter.inc +++ b/src/etc/inc/filter.inc @@ -5918,7 +5918,7 @@ function filter_rules_generate() { array_from_filter_lines(filter_captiveportal_pass()) ); - $add_coredns_rules = config_path_enabled('coredns'); + $add_coredns_rules = config_path_enabled('system/coredns'); if ($add_coredns_rules) { $saved_tracker += 10; $tracker = $saved_tracker; -
@marcosm I can confirm that this patch works on my configuration.
Nexus : 26.07_1
Appliance: Netgate 6100 -
The patch also appears to be working for me.
One thing to note for anyone who tries the patch, it took reloading the filter rules after applying the patch before it would pass traffic.
I can now continue testing ZTE.
Thank you,
Mike -
I tried it today and it is working for me (26.07_2). I only used it on my phone VLAN and VPN (IPv4 only) though. And I am missing the query log I have when I am using AdGuard directly. Still a nice feature though, good work Netgate.
Technically, if AdGuard reports its pfSense interface as the client, I still know that it is my phone because it is the only client.
Privacy Policy · Cookie Policy