Add new component to manage IPsec connections in a similar format as `swanctl.conf` is defined (https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html). As this needs to work in conjunction with the legacy IPsec module, some minor changes are needed to the current state.
o VPN/IPsec/Pre-Shared Keys - add optional remote identifier (merges in `ipsec.inc`)
o VPN/IPsec/Virtual Tunnel Interfaces - new component to show existing VTI's and add new ones (as these are separate entities)
o VPN/IPsec/Connections [new] - configuration tool to build `swanctl.conf`
o Integrate MVC generated `swanctl.conf` into `ipsec.inc` (legacy overlays)
o Integrate manually configured VTI's into `ipsec.inc` (`array_merge(ipsec_get_configured_vtis(), (new \OPNsense\IPsec\Swanctl())->getVtiDevices())`)
o fix minor php warning when changing reqid's (`$local|remote_configured` initialisation when `$configured_intf[$intf]` not found)
As the output of pfctl -vvss can grow quite rapidly, it seemed like a good idea to run this code through a profiler. Some of the hotspots (like parsing addresses) are now cached in memory to prevent over enthusiastic computation, which can save quite some processing time. Pushing down the string join on which the pattern search should match does help prevent to prevent compiling a search string which turns out to be irrelevant later (no filter or ip[+port] filter).
The network (address) search handles (optional) ports as well now, which allows for patterns like `10.0.0.1:80` and `10.0.0.0/24:80`.
Since rule labels are directly hooked to the modification time of /tmp/rules.debug, we don't have to recalculate the offsets on every request. This patch saves the labels and the last modification time so we can refresh when changed or non-existent.
As the client still might have a state when being kicked-out, we should kill any state the client has while adding it to the alias. Apparantly our ssh messages are only catched partially, so add ".*Authentication error for .*" to the list as well. To ease testing, better detect the location of the timestamp so we can use a construction like this to feed amn existing log:
lockout_handler < /var/log/audit/audit_20221205.log
* unbound / overview: add client activity chart, include logarithmic scale on both charts
* unbound: remove tooltip from workaround datapoints
* unbound / overview: also end the x axis properly on log scale
* unbound / overview: prevent queries on non-existing database
* unbound / overview: replace cache hits with blocklist size and update icons
* unbound / overview: refactor rolling API call
Adds a reporting backend for Unbound as well as a dashboard showing an overview of interesting statistics:
Total DNS queries (over a maximum period of 7 days)
Blocked queries
Cache hits
local-data hits
A traffic graph with variable intervals
top N passed/blocked domains (with associated blocklist)
There are a couple of hardcoded values:
The underlying database is kept up-to-date for the last 7 days.
The ring buffer used to decouple unbound from the logging backend has a size of 100000 entries.
In very busy networks, db commits are done for a max of 4000 entries, which according to testing seems to be a good break-even point for DNS throughput vs. insert performance. Everything below this is flushed to the database every 5 seconds.
To facilitate the variable interval traffic graph, multiple views with varying detail in time slots are created: 1, 5 and 30 minute buckets. These can easily be extended should different intervals be necessary.
Not going to backport this, but in 22.7.x unique was called uniqueids and forcefully set to "yes", which according to the documentation (https://wiki.strongswan.org/projects/strongswan/wiki/connsection) is not compatible with a closeaction as this might lead to an avalanche of reconnecting children for the same connection. Although swanctl (https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html) doesn't explicitly mention an incompatibility, our defaults are different than the ones being configured nowadays. Adding the option does seem to make sense.
Media settings probe is suboptimal for hardware detection and
interfaces_hardware() already uses the function to decide where
to enforce hardware settings.
PR: https://forum.opnsense.org/index.php?topic=30923.0
this eases scriptable actions where a single unique entry should be pushed atomically to multiple hosts.
e.g. the below would add/set an alias named api_test_001 :
r = requests.post(
'https://192.168.1.1/api/firewall/alias/setItem/9a8fc804-0000-0001-99cb-283ca2d04e58',
verify=False,
auth=(api_key, api_secret),
json={'alias':
{
'enabled': '1',
'name': 'api_test_001',
'type': 'external',
'counters': '0',
'description': 'api_test_001'
}
}
)
print(r.text)
In theory we should be able to move the host routes for 6rd and 6to4
easily without repercussion, unless some part of the system tries to
reload the interface without calling system_routing_configure().
While here simplify the host route creation as we want to split
this out for a clean reset during a full routing table reload so
we can be sure all stale and disabled instances are removed anyway.
