This contains roughly the same configuration items as our current isc-dhcp6 alternative, with the exception of not trying to implement dynamic ranges based on data received from dhclient6.
In terms of target audience, dynamic environments (receiving their "wan" type addressess via dhcp), should logically use dnsmasq for client configuration. Large (enterprise) setups usually are static by nature and may require prefix deligation to routers behind the primary one. In these cases Kea will be the tool of choice.
Both v4 and v6 share the same rc scripts underneath, which means reconfiguration happens per package (eventhough two services are registered).
Existing hooks for v4 have been extended with v6 data (firewall rules and staticmaps).
Advanced configurations can still opt out of config file generation and supply their own json config, same as implemented for v4.
The lease view still needs to be implemented, but that's likely a minor addition.
* Interfaces: Devices: Bridge - refactor to MVC for https://github.com/opnsense/core/issues/8353
* move existing properties to model which overlays existing config path
* add a simple wrapper script for [re]configuration which diffs and applies using the new _interfaces_bridge_configure() implementation
* Update src/opnsense/mvc/app/models/OPNsense/Interfaces/Bridge.xml
Co-authored-by: Franco Fichtner <franco@opnsense.org>
---------
Co-authored-by: Franco Fichtner <franco@opnsense.org>
* dnsmasq: Unify dhcp-option and dhcp-match in the same grid
Both dhcp-option and dhcp-match use almost the same fields in the form and concern the same options.
Unifying them could make sense to remove some duplicate code and potentially improving the UX.
* make plist and remove console log debug statement
This commit adds backwards compatible changes to the automation api and associated user interface. Although this is likely not the final state, it adds quite some improvements in making this a valid replacement for the current firewall user interface.
if no shaper (ipfw) rules are present, or these rules are disabled, ipfw will be disabled as well (firewall_enable="NO" and rc.ipfw onestop).
Traffic shaped via pf will not show up in the stats output of dnctl pipe|queue|sched show. Also, there is currently no logic to associate pipes/queues with pf rules.
* wizard: reimplement system setup, for https://github.com/opnsense/core/issues/8352
This commit implements our replacement for the setup wizard. The questions are roughly the same as in the legacy version.
Some less relevant options have been removed (pppoe ondemand for example) and isc-dhcpd has been replaced with dnsmasq.
Only standard tools have been used, a memory model to validate the data and simple input forms in tabs.
The in memory model acts as a wrapper around a legacy configuration data and a couple of component models to apply the requested settings.
Some legacy settings using isset() have been altered to use their empty() equivalent.
* wizard: as we're changing to dnsmasq as default, we need to make sure the console setup configures the same (https://github.com/opnsense/core/issues/8352)
Fix some small php arnings in the process, but further than that just rewrite the dhcpd console handling to use dnsmasq instead of isc.
Eventually we will need to rewrite the console tools as well, but let's try to keep this compatible with minimal impact.
* wizard: change other occurrences of isset($config['dnsallowoverride']) for https://github.com/opnsense/core/issues/8352
* wizard: sort listtags() and some other minor review comments for https://github.com/opnsense/core/issues/8352
* Captive Portal: WIP for migration to pf (https://github.com/opnsense/core/issues/8326)
Captive Portal: cleanup references to ipfw
Captive Portal: move accounting deletion to get action, update references and descriptions
Captive Portal: remove note
Captive Portal: move accounting to pf match rules
Captive Portal: cleanup and shorten code
Captive Portal: parser issue after refactor
Captive Portal: update logo in default login page
* Captive Portal: internal alias should not be editable
* Captive Portal: move to periodic accounting sync
* Captive Portal: update lighttpd zone config
* Captive Portal: ether rules for accounting
* Captive Portal: safe accounting fetch
* Captive Portal: move counter calculation to bgprocess
* Captive Portal: remove nested anchors, match anchors on interfaces as well
* Captive Portal: move service logic to captiveportal.inc
* Captive Portal: leftover test statement
* Captive Portal: properly initialize accounting result
* Captive Portal: cleanup sql
* Captive Portal: Implement backend requirements for RFC 8908
While here, the zoneid is provided to the client, even though there
there is no need to do so. Instead let lighttpd forward the
request with an added header containing the zoneid of the client
* Captive Portal: review feedback
* Captive Portal: from_not case
Rename previous "advanced settings" to "mobile & advanced settings" to guide people into the right direction, strongswan.conf contains both sets of data.
Keep legacy page for settings that are only relevant for the old components.
Since our pam authenticator hooks into the configuration, refactor to use the model as well.
Cleanup code in the model that was only used in the legacy glue.
This rather large commit implements most relevant dhcp options and rewrites dnsmasq's backend.
By default dnsmasq is disabled, eventually we do want dnsmasq enabled for dhcp services by default, but dns itself disabled. For this reason we support port "0" as implemented at dnsmasq (not listening for dns).
For cases where users want to integrate dns and dhcp services, the advise is to make dnsmasq listen on a non standard port and point unbound to the zones where dnsmasq is responsible for. This has the advantage of a direct connection between dhcp registered hosts and the requesting service. In these cases dnsmasq's dns service acts like a "connector".
In the long run we should deprecate `regdhcpstatic` and `regdhcp` as these either belong to legacy isc-dhcp or hook kea entries (which are better served via unbound).
The first mvc migration phase implemented IndexController.php, which we rename to SettingsController.php now as these results in more logical ui endpoints.
Since we don't bind to addresses directly (unless specifically configured and adviced only for static setups), we can skip the newwanip event which means we don't restart the service on interface changes. dnsmasq is able to filter the relevant networks on the fly, which is the advised scenario and can cope more easily with changes.
When different clients need to receive different options, we can use "tags" now. Requests can add tags to filter options which will be offered to the client, in the most simple scenario one would tag on a range or a host reservation, but more advanced choices can also be achieved using match statements (for example architecture [client-arch])
When services offer aliases which are less static, the current json option isn't very practical as we only want the package manager to ship files into these directories.
The new DynamicAliases namespace may contain simple php classes, which return a named set of aliases to merge into the set.
Since all of these classes are created on each alias query, it's highly advisable to keep their implementations as lightweight as possible.
We move the gateway recovery into the hook as a user and users
can do their on similar scripts to fetch current status and
inspect and react accordingly. We do so before filter reload
to avoid excessive reloads in the facility script(s).
What this loses is the ability to get the previous argments
for statistics, but OTOH it also reduces the risk for spurious
events as we only trigger on state transitions.
Allow import hooks to be overwritten or manipulated.
No functional changes but it allows to bootstrap a
/conf/config.xml before opnsense-importer (making it
skip import) or modifying the imported /conf/config.xml
afterwards.
As discussed the wizard will be removed and the legacy component
it is feeding moved to a plugin for 25.7 so it makes no sense to
drag this along any further.
* mvc/view: Create layout_partials/base_apply_button to centralize design of the standard Apply button
* dhcp/kea: Example implementation of layout_partials/base_apply_button
* mvc/view: Change edit_alert_id to global static default, add data-grid-reload and dynamic ids to base_apply_button partial
* dnsmasq: migrate to MVC/API, initial boilerplate for https://github.com/opnsense/core/issues/7905
* dnsmasq: migrate to MVC/API, work in progress for https://github.com/opnsense/core/issues/7905
* add general tab fields
* initial hosts tab with inline migration
* dnsmasq: migrate to MVC/API, replace current frontend for https://github.com/opnsense/core/issues/7905
More or less feature complete refactory of the current frontend, which should be a drop-in replacement for the legacy frontend.
The default migration will force an inline migration for aliases and domain ip addresses (which in legacy is a combined field).
* dnsmasq: migrate to MVC/API, missing isset() -> !empty() for https://github.com/opnsense/core/issues/7905
Introduces the isBanner property, which explicitly defines the message
as a banner, which doesn't necessarily have a relation to
the persistent property. While here, update the UI to remove
cursor events when the message doesn't have a location set.
above 95% usage triggers a persistent banner.
while here, fix a small issue that excluded persistent notification
types from counting towards the icon color used.
