Messages

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.

Thanks

What is the meaning of the Expires column? No tooltip, no units, not present in screenshot on current documentation.

Right, just worked that out. For some reason, that didn't run so I just did it manually and I don't need the UI stuff anyway so removed it.

There is a plugin os-speedtest-community in the mimugmail repository which includes the CLI version.

Is this still true? I installed this on 25.1 but can't work out what the speed test executable actually is.

Code Select Expand

# pkg info -lx os-speedtest-community
os-speedtest-community-0.9_6:
        /usr/local/opnsense/mvc/app/controllers/OPNsense/Speedtest/Api/DownloadController.php
        /usr/local/opnsense/mvc/app/controllers/OPNsense/Speedtest/Api/ServiceController.php
        /usr/local/opnsense/mvc/app/controllers/OPNsense/Speedtest/IndexController.php
        /usr/local/opnsense/mvc/app/models/OPNsense/Speedtest/ACL/ACL.xml
        /usr/local/opnsense/mvc/app/models/OPNsense/Speedtest/Menu/Menu.xml
        /usr/local/opnsense/mvc/app/models/OPNsense/Speedtest/Speedtest.php
        /usr/local/opnsense/mvc/app/models/OPNsense/Speedtest/Speedtest.xml
        /usr/local/opnsense/mvc/app/views/OPNsense/Speedtest/index.volt
        /usr/local/opnsense/scripts/OPNsense/speedtest/install_speedtest.sh
        /usr/local/opnsense/scripts/OPNsense/speedtest/opn_speedtest.py
        /usr/local/opnsense/service/conf/actions.d/actions_speedtest.conf
        /usr/local/opnsense/version/speedtest-community
        /usr/local/opnsense/www/js/widgets/Metadata/Speedtest.xml
        /usr/local/opnsense/www/js/widgets/Speedtest.js
        /usr/local/www/widgets/include/speedtest.inc
        /usr/local/www/widgets/widgets/speedtest.widget.php

I was under the impression that this functionality was deprecated by Google, so have changed my backup method to Oxidized.

OK.....not the fault of the edge Opnsense firewall...the issue was the downstream L3 router, just routing the replies coming back from the internet, back out to the edge firewall again. Once I told it to just route things to the correct places, it's now working.
No wonder OpnSense and I were very confused!

You wouldn't happen to have synproxy enabled on the pass rule for these sessions?

I have tried every option under state type on this rule, none of them work.

tcpflags on the dropped packets are 'SA'.
ICMP ping has the same issue.
If I click on the rule ID in the info popup, it opens a tab which then immediately closes itself.

The state table looks "reasonable" to me - the only oddity is that the matching rule is alleged to be "let anything out of the firewall itself", which this traffic is not. But I compared it to another firewall and that's the same matching rule name.

No, there is a single WAN gateway and a single gateway to reach these routed subnets on TNET.