Roadmap #4
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
MVP
Mid term
Future
I'm going to pick each item apart here for clarification
@speatzle wrote in #4 (comment):
I will finish touching on them later
@andrebrait wrote in #4 (comment):
First Step is booting the vm and running some tests on it in regards to service state making sure var got mounted and other basic things. Then taking a snapshot and run some config changes and see if service config changes as expected. What you have described is what i mean by "Traffic Tests" where i boot up nfsense with 4 interfaces and simulate traffic through it.
I think i already have a draft plan for this.
Mentioned above
I have qwen3.8-27 uncensored running locally, i just need to find the Time.
I have a locally stashed change but it lived in jsonrpsee so i want to wait for the API function Refactor and do it there instead.
nfsense already has a declarative JSON config, it is defined through structs in Rust. But because many of the options are relational and need to be verified (a Firewall rule points to an IP Address Object) i have created structdb. It uses rust macros to allow you to define foreign key relations and run validation to check these relationships. Garde is there for object level validation like allowed characters or max number. Unfortunately JSON schema just cant do the cross object validation the way we need it. But we can generate a JSON schema from the Garde definitions for use in the frontend (further down the roadmap).
As an alternative i have thought about just having root and loginuser in the Appliance like a Sophos UTM.
Yes, should be easy in either case.
The nfsense daemon runs as root and applies its full config. It needs root (or in the future a specially privileged User) to manage everything already. If a User does not have permission to edit these settings via its role it can't (should not be able to) change the nfsense config in the first place.
nfsense already generates a default config if it cant find one, this could be extended to also include DHCP on the interfaces by default, but if something goes wrong i would rather have it be dead (or reboot to the other version) than accessible by potentially the entire internet with its default password.
This would a subcommand for the CLI to be more like a guided setup where it lists the interfaces, offers to enable DHCP and just gives options like in opnsense.
Mentioned above
No, I mean Policy Routing where you have Rule similar to a Firewall Rule but which override Static Routing Decisions instead of blocking traffic https://en.wikipedia.org/wiki/Policy-based_routing
I wrote a setup manually using iptables years ago, it was a pain but worked. The pfsense/opnsense implementations have some routing limitations so i want to use proper vrf's like other Paid Firewalls do.
Currently the dashboard just looks like this:
I together with @adroslice have a rough plan for a user configurable Widget System. The listed Widgets are just the ones which we should have of the top of my head. Which ones should be in the default layout is up for debate.
yea, just needs its own config section, but requires considerations like if users should be able to edit settings of other users and if dashboards should be user specific, shared or both.
Firewall Service Mappings for matching Ports or Protocols:
Basically the contents of the linux distro /etc/services file but only include important ones in our default config so that Users don't need to recreate all the basic definitions.
I mean Groups of Address or Service Objects, they exist but everything that uses these objects for apply ignore or crash it if the type is Group currently:
Current state:
The config already has a config version and a migration mechanism, this is mainly for when you have a older fallback version installed which might get booted if something goes wrong with the new one but it cant read the newer config version.
I am not sure what that has to to with Failure detection? Currently the backend just restarts a service using systemd after writing the config but it does not wait for the Service to become fully ready since detecting that is different for every service.
I already have gotten a bunch of Nitro and Yubi keys for secure storage, this is more about setting up pipelines for dev and prod releases with different keys uploading them and ensuring that malicious actors cannot gain persistence in the pipeline or exfiltrate the signing keys even if the pipeline is compromised. I would not trust only AI with such security critical research.