Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    Zero trust Egress with CoreDNS - can't get it working

    Scheduled Pinned Locked Moved Plus 26.07 Snapshots (Retired)
    10 Posts 6 Posters 705 Views 10 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • keyserK Offline
      keyser Rebel Alliance
      last edited by

      I have tried several times now to configure ZTE in CoreDNS, and I can't get it to work.
      Version: 26.07-RC - 20260801-1756

      I 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?

      Love the no fuss of using the official appliances :-)

      1 Reply Last reply Reply Quote 0
      • jimpJ Offline
        jimp Rebel Alliance Developer Netgate
        last edited by

        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.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        keyserK 1 Reply Last reply Reply Quote 0
        • keyserK Offline
          keyser Rebel Alliance @jimp
          last edited by keyser

          @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.

          Love the no fuss of using the official appliances :-)

          1 Reply Last reply Reply Quote 0
          • M Offline
            mr_nets
            last edited by

            Netgate 6100
            Version 26.07

            It'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.

            1 Reply Last reply Reply Quote 0
            • M Offline
              mr_nets
              last edited by mr_nets

              My setup:

              WAN:
              1xPPPoE

              LAN:
              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 remote

              CoreDNS: , (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.1

              Firewall 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

              1 Reply Last reply Reply Quote 1
              • J Jim Coogan referenced this topic on
              • F Offline
                felixm223pfsense
                last edited by

                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.

                M F 2 Replies Last reply Reply Quote 0
                • M Offline
                  marcosm Netgate @felixm223pfsense
                  last edited by

                  @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;
                  
                  M 1 Reply Last reply Reply Quote 1
                  • M Offline
                    mr_nets @marcosm
                    last edited by

                    @marcosm I can confirm that this patch works on my configuration.

                    Nexus : 26.07_1
                    Appliance: Netgate 6100

                    1 Reply Last reply Reply Quote 2
                    • F Offline
                      felixm223pfsense @felixm223pfsense
                      last edited by

                      @marcosm,

                      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

                      1 Reply Last reply Reply Quote 0
                      • Bob.DigB Offline
                        Bob.Dig LAYER 8
                        last edited by Bob.Dig

                        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.

                        1 Reply Last reply Reply Quote 1
                        • First post
                          Last post
                        Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.
                        Privacy Policy · Cookie Policy