@marcosm Thanks for your Answer Ok I didn't see this as i was checking the config.xml file and not a backup export Good to know, will check with Sales when I get the go ahead from Management. Is there any Timeline you could share for the rest? From what I can see its not tracked on Redmine at least.

Thanks. If the API is still being worked on, it would be nicer to have a strict success: true | false bool for automation vs parsing a text field.

Currently the pfSense+ license itself isn't tracked by Nexus.

It'd be best to contact sales for that question :)

We'll have by-device fixed in the release.

@tkerr @tkerr not intending to install it on the pfSense, but on the automation server.

It's supposed to work. We'll work on a fix - thanks for the report!

@jwt I did in fact assume that the CoreDNS fork is being designed as a complete Unbound replacement—but only because it seems based on your description of ThreatGate, that 'full mode' will not be available without CoreDNS. Bit of an (il)logical jump there I suppose. I'll just have to hold my horses!

@luckman212 We don't have plans on doing temporary configuration because it raises problems for two areas: multi-administrator/multi-controller access which is the design goal of Nexus. For example, if one admin issues a temporary configuration but another applies a stored config, then there stored config ends up ovewriting what was pushed temporarily likelihood of split-brained configuration where the controller maintains a different state to what is on the host. This can happen already if a user does things outside of the configuration channels, such as making a pf rule change directly on the OS and not reflected in the config. Also, the Nexus controller process could restart from time to time (such as on updates), and in such cases would load from config and not know what is the authoritive on the temporary side. The closest thing you can do for dynamic tables is to use URL Table aliases, which makes pfsense pull the list from some URL you run. We could potentially add future Nexus capability to pull from both the URL and local files, with a manual trigger to make it load on demand.

@marcosm Ok thanks. Very handy!

@ldangpfng That's worked, brilliant! Thank you very much! :)

It will be available when the product is launched (including the correct link in the docs).

@marcosm Thanks. What licenses would I need if I want to test this in a lab?

This should be fixed in the next version.

+1 on wanting a Timeline and Costs, we currently have a few Customers that remain on a previous version to retain the ability to controll 3 Firewalls

By default it only manages itself but it can also become a controller which manages many clients. As for the referenced features, I can say that there are many features in our internal builds and we'll release more info when appropriate :)

I'll look into this for you. I can renew certificates that I created in the new GUI, but none of the others. It does seem that it uses the CA endpoint to renew regular certificates though. So you should be able to use system/certauth/{refid}/renew until it's fixed.

@philippe-richard use the new UI (by default it listens on port 8443), which will let you see the API calls, similar to the screenshot of the web devtools above, where the id is derived from a unique value of the rule entry. This is unlike the PHP pages which do not have an API and assume one admin accessing the page at any time, so submitting from *_edit.php?id=7 could end up hitting the wrong entry if two people are modifying the rules at the same time.

Actually, docs are hosted here. This is now linked in the readme.