@marcosm said in 26.07 RC memory leak?: How soon does it reach that amount after restarting the service? After about 17 to 19 hours, a memory issue occurs. Despite seeming pretty stable, it gradually starts to leak RAM. Does it still happen with ThreatGate disabled? I haven't tested it with ThreatGate disabled yet, so I can't say for sure. A little more about my setup:In CoreDNS, I'm using 3 groups with fallback.In these groups, I have a few forwards and resolvers.CoreDNS is forwarding to DNS resolver 127.0.0.1:5353 because I'm using DNS-over-TLS to Cloudflare.ThreatGate is enabled, but it is only using the GeoIP MaxMind feed, nothing else yet.

@marcosm Since enabling Nexus, I've noticed that other config changes, not related to Nexus, also change config.xml permissions. Could be a coincidence, but thought I'd flag it.

@stephenw10 New interface via Netgate Nexus, Management View / Status / Monitoring / any of System or Quality or Packets or Traffic. Ted

Quick addition: I actually ran into an API (from Qfeeds) Limit so at one time where I tried saving to re-download, it actually tried but got an error but showed NO feedback in the popups, errors or anything else. Only after browsing Nexus Logs did I see a API restriction answer from a curl call. The Nexus GUI itself showed all happy greens and no errors. That's also not that nice for debugging. Also not seeing anywhere in the TG UI how many "items" in a list were actually downloaded or loaded (in terms of DNS lists) at all makes it also hard to check if something went right or wrong. Ah and a final thing: TG doesn't "remove" lists when you disable TG or the list in TG. When the Alias is in use, you'll get no info whatsoever and wonder, why you're disabling everything and it doesn't vanish. Even when you rename stuff, it doesn't get renamed (in my test at least).

@fwit I can replicate this bug. We'll get it fixed

Does no one have the same problem? Is the bug known?

@marcosm said in A lot of "reserved IP" traffic going out on WAN while Nexus is enabled: We'll work on fixing that. Great. There are a few connections to 169.254.169.254 over the day, even if Nexus is disabled.

@keyser said in ThreatGate DB - pfnet-controller WARN No rules found: Does MaxMind downloads work for you? It is working. Try to disable, then enable the feed, it worked for me.

@tkerr Observed bugs in 26.07-RC - 20260801-1756: Using the new UI has several issues when attempting to create new rules: 1: Attempting to add a rule from the top does not work if you have the anti-lockout setting enabled (default). Then you will be given the error "Failed to insert rule: insert rule error - unable to find insertion point. 2: You cannot set a "tagged" value under advanced on rules in the new UI - sort of defeats the purpose of zero trust egress mode. You have to use the old UI to set the tagged value. It saves the rule and says success. There is just no tagged value and advanced tagged setting saved. [image: 1786347202094-bebdf07d-fac0-4f78-8038-d145059d4d3d-image-resized.png]

Some of this is being discussed here: Nexus Discussion I am going to be testing baking in a serial today on a couple protectli boxes to see if I can restore functionality, and will respond to that thread with my results. FYI.

@SteveITS said in CoreDNS and Caching best practices?: Google DNS truncates TTL to a maximum of 6 hours. Of course they do. Why ? Short answer : you would do the same thing (if you worked for them). Google (8.8.8.8) prefers that you have to come back as much a possible for fresh DNS info. This gives them a very important info : they start to know in quasi real time where and when go visit something. That info will be thrown in the 'profiler' just for 'you' so adds can be sold with an even higher price. If there wasn't a local cache in the forwarder like pfSense, neither in the end users device, then for every DNS request the DNS server has to be consulted. I won't be surprised that the DNS will start to 'throttle' your requests. There is probably a sweet spot, but 0 TTL would for sure create problems. Ok, my answer has some in it, but I'm pretty sure I'm not wrong.

@tinfoilmatt I agree and I have read them. I would just like to know how it has been implemented in the back so I can make an educated guess on performance. I’m mostly worried about the thousands of lists of resolved IPs CoreDNS needs to maintain (one for each client), and the risk of the client attempting to pass correctly resolved traffic before CoreDNS and pfFilter is updated with the correct list of resolved IP’s for that client.

@patient0 yeah looks like a parsing isssue - write out the full address vs shorthand

Yup more orchestration options are coming. Upgrading multiple boxes at the same time has become an invaluable feature for me. But I do upgrade a lot!

Thanks so much!