* IPsec: cleanup phase2 parsing and implement per reqid spd policies. for https://github.com/opnsense/core/issues/4460
* IPsec: persist reqid and (try to) maintain previous choices for route-based IPsec while doing so.
In order for this to work we need a legacy config migration, which we stick to the IPsec model used to store key-pairs. (trigger via /usr/local/opnsense/mvc/script/run_migrations.php)
The phase2 edit should (try to) assure new and modified entries are being equipt with a reqid, in order to use them in the policy mappings and interface generation (route-based).
Ideally we should add this feature when a new kernel arrives since changing reqid's on existing connections and setkey policies will likely have side-affects.
------
Sponsored by m.a.x. it
When investigating log files it's often practical to see the context of a message after searching for it. This feature offers the ability to go to the page in question by clicking on a filtered result.
With this commit policies functionally work, but there's still some refactoring todo.
o migrate download filters to a policy
o remove download filter option
o point to policies in the download section
o (maybe) move single rule overwrites to policies as well.
Following a discussion in FreeBSD ports to simplify ports handling
the missing @version will no longer trigger a warning in recent
syslog-ng releases so it's better to remove this to ease future
transitions of the port (merged into one "syslog-ng" port then).
rc.configure_plugins is likely fixed, but rc.configure_firmware
has the same issue so make this more maintanable by moving the
async request to the system function and put the former call back
with the async flag set.
Should fix syslog-ng related package configure hangs with regard
to pkg-based bug in recent versions.
In 6f76b5f the displayName attribute was added as the first camel case
attribute being read from the search result. As various[^1] comments[^2]
for `ldap_search` mention the attribute names must be lower case, even
though the LDAP server might return them differently.
Using all lower case to access the returned attribute results in the
value of displayName actually being used as the full name of the user.
[^1]: https://www.php.net/manual/en/function.ldap-search.php#37317
[^2]: https://www.php.net/manual/en/function.ldap-search.php#28991
The associated nat rules remain a terrible construct, ideally we would make sure the automated rule matches a regular one, but if they do, the firewall_rules_edit.php page has to handle all sorts of corner cases leading to other unexpected behaviour.
This fixes a bug, cleaning this up would either need proper validations in the filter page or no extra validations at all (create/update, only note the relation, but don't try to enforce anything when associated-rule-id is set.
