Messages

bsnmpd provides features that the Zabbix agent and net-snmpd does not - notably, sensible names for interfaces and firewall metrics.

I decided to re-visit this and have a look at using the OPNsense API. Was easy to test with Curl, started to build a Zabbix template, but then I googled it and this year several different Zabbix templates which use the API to fetch all the useful stuff [and way more than can be collected with either SNMP implementation, Zabbix agent or combinations thereof], have been published on Github. So for my purposes, SNMP agent and Zabbix agent monitoring of OPNsense are obsolete now, and someone else did most of the hard work for me :)

if the system runs any other daemons or processes that may require memory.

Right. Is there any system on earth that doesn't run 'other daemons or processes' than ARC? :D
Anyway, from the graphs, yes I can see that ARC tops out once it gets to 1GB free, so it is behaving as documented.

Default on this firewall is 791400. So wow, there must have been a lot of connections.
I need to work out how to track and alert on PF state exhaustion.

Before I managed to disable hostwatch, I started getting alerts about the Zabbix agent on this host.
I checked the logs and saw
[zone: pf states] PF states limit reached
being logged every few minutes.
Will ARC memory usage cause problems for PF states being created?

Yes indeed this device has Hostwatch enabled and the others do not! I will disable it and see what happens. It had found 800 hosts, I wouldn't think that would require so much RAM to keep track of.

After a bit more reading, it seems like ARC memory usage on BSD can be considered as not really used, because it can be evicted as soon as memory is really needed by a process. That being the case, I think OpnSense management tools should take this in to account and not show me a scary yellow usage bar if it's not really "used".

Just looking over my firewalls in central management, one firewall stands out above all the others with RAM usage at 85%. Every other box is 25-35%. It seems to be ARC, which I believe is part of ZFS.
All firewalls are on 26.4 or 25.10 and have 8GB of RAM. Why would ARC usage be so high on one firewall?

Thank you. The answer seems completely obvious in retrospect. Coming from other firewall platforms where you cannot have multiple NAT policies apply to the same packet, I did not think of creating two rules. I have created an outbound rule, and I now have access to the flakey 4G router.

OpnSense 25.10.
I have an unreliable 4G router on one WAN and reliable internet on the other.
I am outside the firewall.
I want a NAT policy that gives me access to 4G router's web interface via the reliable WAN.
For this to work, it needs to translate the source and the destination IP when I make the connection but I don't see a way to do this in the OpnSense web interface.
Can this be done somehow?

Yeah, perhaps there are, but a) it's Azure b) I don't manage it so don't have access :-(

Same.

Code Select Expand

# ipsec statusall | grep ESTABL
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[131]: ESTABLISHED 112 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[134]: ESTABLISHED 76 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[139]: ESTABLISHED 18 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[133]: ESTABLISHED 95 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[138]: ESTABLISHED 38 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[136]: ESTABLISHED 57 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
4d094f8b-e147-4d3d-9380-d60d6184c77d[10]: ESTABLISHED 24 minutes ago, 192.0.2.99[192.0.2.99]...203.0.113.6[203.0.113.6]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[130]: ESTABLISHED 2 minutes ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]

Hasn't made any difference. Restarting the IPsec service got rid of all the older child SAs but it's still creating new ones.
I am going to delete and recreate.

Yes, the reqids are unique.
Each connection only has a single child SA.
I have changed to Trap+Start and will report back.

When enabled, every 20s, this is logged:

Code Select Expand

<30>1 2025-11-14T14:27:54+00:00 router charon 35057 - [meta sequenceId="13664"] 10[CHD2] <771e685b-783a-4fc6-9c54-6c49e07621c8|4456> CHILD_SA 0a06bd58-d311-4be4-b850-e21ee2405c88{65} state change: CREATED => INSTALLING
<30>1 2025-11-14T14:27:54+00:00 router charon 35057 - [meta sequenceId="13679"] 10[IKE0] <771e685b-783a-4fc6-9c54-6c49e07621c8|4456> CHILD_SA 0a06bd58-d311-4be4-b850-e21ee2405c88{65} established with SPIs c87529cf_i 0237a11e_o and TS 0.0.0.0/0 === 0.0.0.0/0
<30>1 2025-11-14T14:27:54+00:00 router charon 35057 - [meta sequenceId="13680"] 10[CHD2] <771e685b-783a-4fc6-9c54-6c49e07621c8|4456> CHILD_SA 0a06bd58-d311-4be4-b850-e21ee2405c88{65} state change: INSTALLING => INSTALLED
<165>1 2025-11-14T14:27:54+00:00 router charon 57611 - [meta sequenceId="13682"] [UPDOWN] <0a06bd58-d311-4be4-b850-e21ee2405c88> received up-client event for reqid 20

OPNsense 25.1.12-amd64
Using IPsec Connections, not IPsec Tunnel Settings.
Route-based VPN tunnel to Azure.
Tunnel mode.
Having the SA enabled seems to result in a new SA being created every 30-60 seconds or so.

[the one MODP_2048 entry below is a working tunnel, not related to this]

Code Select Expand

# ipsec statusall | grep bytes
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
0a06bd58-d311-4be4-b850-e21ee2405c88{45}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{36}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 248 bytes_o, rekeying in 6 hours
dafa61b0-baa3-4120-85bf-b6bf37d00487{24}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 14657534 bytes_i (142048 pkts, 0s ago), 28693760 bytes_o (127444 pkts, 0s ago), rekeying in 7 minutes
0a06bd58-d311-4be4-b850-e21ee2405c88{62}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{51}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{64}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{63}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{49}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{42}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{39}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{44}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{37}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{68}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 2604 bytes_o, rekeying in 7 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{57}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 248 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{50}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{33}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{28}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{58}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 372 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{53}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{38}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{54}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{43}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{35}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 372 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{34}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{55}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{32}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{30}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{48}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 7 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{41}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{29}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{59}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{56}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{52}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{46}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{31}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{47}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 496 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{65}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{61}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
Some of the alleged SAs have TX bytes on, none have any RX.
If I disable the policy, it stops creating SAs but none actually get deleted.
Behaviour is a bit puzzling, what is going on here? Clearly, my end thinks the SA is up if there are TX bytes, but why does it then bring up another?

Tried my first upgrade with Central yesterday. It seemed to work, only a small step from 25.10 to 25.10_2.
But there doesn't seem to be any useful information in Central about this. There is no log and after clicking Upgrade I wasn't really sure what it was doing. The "Ready to upgrade" and "Upgrade in progress" icons are the same colour which seems like an obvious missed opportunity. We know that new colours are quite cheap nowadays.