Testing 26.07_2. It is now much , much better for me. I'll keep testing for a few days. Thanks, Netgate team!

@marcosm Thanks now it works

I reinstalled nexus and it now works. Ted Quade

said in CoreDNS Groups Prefix: forcefully redirect all DNS queries I mean I would but the problem described here is still not tackled: https://forum.netgate.com/topic/201131/26.07-release-port-forward-is-missing-pass/11?_=1789294343778

@phil_socket95 Thanks for the advice. IPv6 doesn't change the behavior, but I get your point; I'll simply take IPv6 out of the equation for now, as testing it is a hassle—it causes outages at times when CPU usage is high. Good point regarding RSS; I'll keep a closer eye on that. Another thing: after running further tests, I noticed the problem occurs under two different circumstances when ZTE is enabled: Restarting the pfnet-controller service and letting ThreatGate refresh the feeds for the first time (this takes at least 3 hours, as that is the minimum allowed interval); CPU usage spikes immediately after the refresh. Restarting the pfnet-controller service and changing the ThreatGate refresh interval to more than 24 hours to prevent a refresh; in this case, CPU usage increases gradually over time. I'll need to write up a new summary of all this when I have the time.

@tkerr Proton Pass is working on my phone. I'll try again on the desktop. Might be some setting or blocker failure. ‍️

@pfGeorge Thanks for the heads-up, much appreciated!

Also it lacks personality.

Solved with Nexus Version 26.07_1.

This should be fixed in the latest available Nexus version in 26.07.

@marcosm Thank you very much, I can confirm that this has resolved the issue. Mike

Cool, my VM seems supported now. Even the other one.

@SlackerDude if you see nothing helpful in the logs (Status->System Logs->Netgate Nexus), there could be a port conflict. If that isn't it, please share your logs and we'll look into it.

@jimp Thanks for the reply and looking into this. Messed around with this some more and it seems the key is that on the CoreDNS group for restricted clients you have to not define a DNS server. That way only the domains under FW get resolved. Otherwise if the group has a specified DNS server than everything gets resolved that isn't explicitly blocked. With this setup I also do not need to rely on the fallback to default. However, I have only been able to prove this from a DNS resolution standpoint because for some reason it seems like the traffic is not getting tagged with coredns_allow because my corresponding firewall rule for allowing the traffic does not match and I have checked it 5 times to ensure the rule is correct. It is basically allow TCP/UDP ANY ANY ANY ANY tagged:coredns_allow on the interface of the client in question. ZERO TRUST EGRESS is enabled and the client can only resolve the domains I put in group forward section and the IPs I get from a dig are exactly the same that curl then tries in my test. @264 pass in log quick on igc2.60 inet proto tcp from 192.168.77.41 to any flags S/SA keep state (if-bound) label "id=1788994054" label "tags=user_rule" label "descr=[COREDNS] allow coredns allowed internet hosts" ridentifier 1788994054 tagged coredns_allow Ultimately the firewall logs for the test traffic show it match for default deny on the interface. Seems to be quite similar to issue reported here https://forum.netgate.com/topic/201102/zero-trust-egress-with-coredns-can-t-get-it-working/ On another note, I had not fully considered one downside of using coreDNS allow listing like this which is that inheirently the firewall rules have to allow anything tagged coredns_allow so all clients subject to this, at least within the same group, end up being allowed to access all of the same domains. Not the end of the world, but I guess what Im really looking for as a feature request is CoreDNS backed aliases that could be used in firewall rules which hopefully this lays the ground work for someday. In the meantime I am still curious to get the tagged allow rules working like they are supposed to now. Running 26.07-RELEASE (amd64) on Netgate 4200.

@Gertjan OK so then it's likely a "feature" that they block it if it's not the configured static subnet. Annoying in my very specific case but not a big issue.

I posted to the wrong forum initially.

@beerguzzle The services widget is coming soon (like a few days soon)! In the meantime you can go to Status -> Services to check. It looks like CoreDNS doesn't get a status so I will make a ticket to track that