I'm using a Protectli currently while I wait for Netgate's next mid-range appliance. Nexus seems to be running fine for me. I'm not using ThreatGate yet.

@keyser said in "Bug": Threatgate list management?: EDIT: But this “bundling” og UI, Threatgate, CoreDNS and Snort in one package will soon also become a massive liability… It will likely cause quick updates to any one of those products to become massively delayed, due to all the other components in the package that needs release coordination with Nexus I think this “bundling” is bad design. Threatgate, CoreDNS and Snort should all come as independent packages/services.

@beerguzzle said in pfBlockerng->Threatgate migration, how to?: I would further argue that Nexus itself isn't ready yet, just because of the lack of a complete Dashboard widget set. If I wanted to use Nexus for just for remote management, I would want it to display the same or equivalent Dashboard remotely as what I would see from the PHP Dashboard when logged on locally. It can't even do that. Sheesh. You'd hear no argue against that from me. Missing dashboard overview stuff like widgets, status displays etc. is only icing on the cake really. For us it even starts below that with boxes that are licensed or paying TAC lite for running plus now unable to access all functionality of Nexus just because of some random serial number field not set up or running in a VM on a non-silicon-valley-cloud is getting really strange.

Damn it, George!

As a workaround, I installed the "cron" package and created a job to reset the permissions of config.xml just prior to scheduled nightly scp backups.

First impressions of the new GUI after a couple of hours of 'looking around': less than a pass. I will be interested to see when the entries for packages in the pull-down menus. I use Traffic Totals quite a lot and would be quite disappointed if not included. As for the pull down menus, I find that having to scroll in the menu quite annoying. Developers: how about tightening the spacing to scrolling is NOT needed.

@johnpoz I'm kinda out of ideas. Definitely a Proton issue—which is rare, but there's a few sites that give troubles.

@stephenw10 Also: Traffic Graph [image: 1786987584779-screenshot-2026-08-17-102607.png]

ThreatDB is downloading the MaxMind lists, and you can use them as aliases in firewall rules. However, the rule is not matching packets. I have opened a Redmine ticket: #17027

@keyser me too, this is one of the first thing I was looking for :-(, not ready for my use then.

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

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

Thanks so much!