Messages

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.

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!