Add connection child as option for manual SPDs, to make sure these are easily selectable we'll extend ModelRelationField to include a method to return it's value (so we can combine parent descriptions)
Add a new status although we didn't want to extend the functionality,
but this does look like a bug when loss indicator is used but not
properly reported.
PR: https://github.com/opnsense/core/issues/6231
o rename virtual_addr --> virtual_address in status call out
o add new endpoints to search connections and routes, kill sessions and service control
o remove old status page status_openvpn.php and change ACL and Menu registration
o offer two tab view on sessions / routes
o service controls (restart/start/stop) are shown for non client based records (p2p and client mode) or when no clients are connected.
o extend model with authgroup type (currently only for OpenVPN)
o add controller action to list user groups
o modify alias form to show group list in a similar way as network groups, simplify some of the code to prevent copying.
o add AuthGroup parser to glue the output of list_group_members.php and ovpn_status.py to a set of addresses per group for our new authgroup alias type to use
o hook 'learn-address' event in openvpn to trigger an alias update
Although theoretically we could pass addresses and common_names from learn-address further in our pipeline, for now we choose to use a common approach which should always offer the correct dataset (also after changing aliases and re-applying them). If for some reason this isn't fast enough, there are always options available to improve the situation, but usually at a cost in terms of complexity.
Replace a few easy spots. Eventually we want to call both
functions for each spot instead of doing both (in switching order)
or only one of them. They are both cheap operations since they
don't (re)start DNS processes any longer.
Cleanup alias handling uniforming operations so new types can be adopted more easily.
o move all pf actions to it's own class
o move all alias related modules to l`ib/alias`
o move AliasParser to alias.py to make update_tables.py more readable
o add targetted alias (type) updates (update a list of aliases including dependencies)
o cache non managed aliases as well, so targeted updates have the opportunity to nest these (interface or bogus aliases for example)
o refactor cleanup a bit to store and keep "txt" files for external aliases
o add `BaseContentParser` type which should be inherited by all parsers and wrap existing types into the new base class.
o add unit tests for all current parsers.
Eventually the old gui code should be replaced as well, but this is an easy to release step in between offering nearly the same output (p2p's presentation is aligned with server in stead of client) with code we are able to reuse for the openvpn aliases.
In case addresses are removed and reapplied the routes are gone
and other related interface configuration is missing. In these
cases do a full recycle even though the address did not change
visibly (which is good that we can detect it).
Also address the "miss" of the cached address clean now that we
know DHCP should not force-update us into a missing address
scenario during a renew.
PR: https://github.com/opnsense/core/issues/6338
This initial commit focusses on structuring the event flow around user and client registration, moving events to our new ovpn_event.py handler.
By supporting both deferred and direct authentication in user_pass_verify.php, we should be able to start with a cleanup patch for OpenVPN 2.5.x and work our way up to
a smaller fix for 2.6.x.
In preperation for 2.6, this commit also moves --cipher to --data-ciphers-fallback as suggested by the warning "DEPRECATED OPTION: --cipher set to '' but missing in --data-ciphers". Rename the option in the gui while there and add a note in the help text.
No need to register callbacks when stats are not enabled and no need to use
a circular buffer on the logger side since we don't need to append left. This avoids
the need for converting it to a list.
'proto' was set on to be deleted VLANs preventing them to be
deleted and also causing the new VLAN not to gain the proper
settings. Likely needs a reboot on systems where this bad
state was reached since the system will not delete stray VLAN
devices it does not know about anymore/failed to delete before.
PR: https://forum.opnsense.org/index.php?topic=32225.0
