Messages

That Sophos UTM firewall appliance is at least 10 years old, where did you buy it?

I'll assume the Intel SSD was new, as it only ran for 479 days and was turned on 69 times.

What's the state of the other Intel SSD in the RAID1 configuration?

In the Postfix plugin the default value is 51200000 Bytes.

I know it follows the convention of the original documentation.

message_size_limit
(I linked via Wayback Machine as I don't know why the Postfix site is currently offline)

But does anybody know why that is?

I mean it is calculated as 50x1024x1000 = 51200000 Bytes.

Shouldn't it either be 50x1024x1024 = 52.428.800 Bytes or 50x1000x1000 = 50.000.000 Bytes?

I know the diference between KiB and KB, MiB and MB etc. but why is it a mixed case here?

It would be really nice if Q-Feeds had its own blocked IP. Of course that would waste a public IP but then you could be 100% sure that the Q-Feeds blocklist works.

Otherwise it would be possible that the Q-Feeds list is not working and an IP is still blocked but by another blocklist.

With an own Test-IP you could also create an A-Record that points to the IP (maybe blocked.qfeeds.com).

Cloudflare uses similar test domains: https://developers.cloudflare.com/cloudflare-one/traffic-policies/dns-policies/test-dns-filtering/#common-test-domains

If successfully blocked you will get e.g. a "ERR_ADDRESS_INVALID" message (instead of a "DNS_PROBE_POSSIBLE" for a non-available domain).

There still seem to be some issues with strongSwan, I encountered another problem now in Phase 2, it showed as up but no side could reach each other.

But I found the issue when I looked closer at the Security Association Database (SAD), both connections had the same reqid. You can also see that the peer side was not sending any data (0 bytes).

You cannot view this attachment.

After manually changing the reqid to 100 Phase 2 works perfectly and now you also see the Ikeid.

You cannot view this attachment.

By the way is it normal that an IKEv1 connection has no Ikeid (the lower pair)?

Normally strongSwan should automatically use incrementing reqids for new connections. According to this discussion on GitHub this is possibly fixed in strongSwan 6.0, our business OPNsense (25.4.3_4) is still on version 5.9.14.

https://github.com/strongswan/strongswan/discussions/2687

I actually found the problem and I also have 3 possible solutions for anybody that encounters the same issue.

When I ramped up the debug level for CFG ("Configuration management and plugins") I found the culprit, the FortiGate device is sending a FQDN IKE ID.

Code Select Expand

2026-02-26T09:35:58    Informational    charon    11[CFG] <428065> remote id match: 0 (ID_FQDN: 31:39:35:2e:79:79:79:2e:79:79:79:2e:79:79:79)   
2026-02-26T09:35:58    Informational    charon    11[CFG] <428065> local id match: 1 (ID_ANY: )   
Searching this issue I found the following article from Fortinet: https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-FortiGate-sends-local-id-in-FQDN-type-when/ta-p/224888

• Solution 1: This is the easiest one, as the peer just has to remove the ID in the field "Local ID" in his Phase 1 settings, the FortiGate will then use the IP of the used interface (ID_IPV4_ADDR). That's the solution we now chose. Of course this only works if the IP equals the ID
• Solution 2: On the FortiGate leave the IP address you used as the IKE ID and add the line "set localid-type address" to your IPsec config. Untested solution.
• Solution 3: This could be handy if there is slow response on the FortiGate side, just copy the ID_FQDN from the verbose log into the OPNsense "Remote Authentication" section and into the "Remote Identifier" in "VPN: IPsec: Pre-Shared Keys". This is also untested.

But I still don't get why OPNsense/strongSwan always has the ID_ANY type for the local ID, despite setting a specific local ID.

Now there is only one weird observation left that I made when I had the CFG logs on verbose:

Code Select Expand

2026-02-26T09:27:20    Informational    charon    07[CFG] vici client 490 disconnected   
2026-02-26T09:27:20    Informational    charon    01[CFG] updated vici connection: 3*******-a***-4***-9***-2***********   
2026-02-26T09:27:20    Informational    charon    01[CFG] id = 195.yyy.yyy.yyy   
2026-02-26T09:27:20    Informational    charon    01[CFG] remote:   
2026-02-26T09:27:20    Informational    charon    01[CFG] class = pre-shared key   
2026-02-26T09:27:20    Informational    charon    01[CFG] id = 49.56.53.46   
2026-02-26T09:27:20    Informational    charon    01[CFG] local:   
2026-02-26T09:27:20    Informational    charon    01[CFG] if_id_out = 0   
2026-02-26T09:27:20    Informational    charon    01[CFG] if_id = 0
Why the hell is there an IP from South Korea as our local ID (49.56.53.46)?

Is this just a random IP from cache because our type is ID_ANY? Can anybody else please raise their log level and check what IP is shown here?

I've read a recommendation to disable the default and specify certain proposal instead.

I doubt the proposals are the problem because as you can see in the log a cipher is already negotiated.

Maybe it is complaining about the remote site's id. Possibly it's different from the IP address?

As you can see or can't see because I redacted the rest of the IP, the remote IP and remote ID are identical.

The FAQs of strongSwan have a section for the error message "no matching peer config found":

https://docs.strongswan.org/docs/5.9/support/faq.html#_no_matching_peer_config_found

So the problem can only be the ID or the proposals (which I already exluded as a cause).

The FAQ also mentions the allowed format for the ID: https://docs.strongswan.org/docs/5.9/config/identityParsing.html

I already tried to change the ID to the explicit <type>:<value> format under "VPN: IPsec: Connections: Local Authentication" to force the ID but it still shows "%any" in the log file.

I downloaded the swanctl.conf and it doesn't mention "%any" anwhere, this doesn't look right.

I also set the debugging level of "IKE_SA/ISAKMP SA" in "VPN: IPsec: Mobile & Advanced Settings: Syslog" to 2 ("More detailed debugging control flow") for some seconds, see also https://docs.strongswan.org/docs/latest/config/logging.html.

Here is the more detailed log, I don't think level 3 would make sense, it just shows hex data and "natd_chunk => 22 bytes @ 0x..." and similar messages.

Code Select Expand

2026-02-26T07:52:41    Informational    charon    10[ENC] <421129> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]   
2026-02-26T07:52:41    Informational    charon    10[CFG] <421129> no matching peer config found   
2026-02-26T07:52:41    Informational    charon    10[CFG] <421129> looking for peer configs matching 185.xxx.xx.xx[%any]...195.yyy.yyy.yyy[195.yyy.yyy.yyy]   
2026-02-26T07:52:41    Informational    charon    10[ENC] <421129> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]   
2026-02-26T07:52:41    Informational    charon    10[NET] <421129> received packet: from 195.yyy.yyy.yyy[500] to 185.xxx.xx.xx[500] (480 bytes)   
2026-02-26T07:52:41    Informational    charon    10[NET] <421129> sending packet: from 185.xxx.xx.xx[500] to 195.yyy.yyy.yyy[500] (456 bytes)   
2026-02-26T07:52:41    Informational    charon    10[ENC] <421129> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]   
2026-02-26T07:52:41    Informational    charon    10[CFG] <421129> selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048   
2026-02-26T07:52:41    Informational    charon    10[IKE] <421129> IKE_SA (unnamed)[421129] state change: CREATED => CONNECTING   
2026-02-26T07:52:41    Informational    charon    10[IKE] <421129> 195.yyy.yyy.yyy is initiating an IKE_SA   
2026-02-26T07:52:41    Informational    charon    10[IKE] <421129> remote endpoint changed from 0.0.0.0 to 195.yyy.yyy.yyy[500]   
2026-02-26T07:52:41    Informational    charon    10[IKE] <421129> local endpoint changed from 0.0.0.0[500] to 185.xxx.xx.xx[500]   
2026-02-26T07:52:41    Informational    charon    10[ENC] <421129> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]   
2026-02-26T07:52:41    Informational    charon    10[NET] <421129> received packet: from 195.yyy.yyy.yyy[500] to 185.xxx.xx.xx[500] (672 bytes)   
2026-02-26T07:52:40    Informational    charon    10[IKE] <421128> IKE_SA (unnamed)[421128] state change: CONNECTING => DESTROYING   
2026-02-26T07:52:40    Informational    charon    10[NET] <421128> sending packet: from 185.xxx.xx.xx[500] to 195.yyy.yyy.yyy[500] (80 bytes)(By the way when did the logs change direction from down to up because I saw old posts where the log goes from up to down? :) )

Also how would I know the default proposals? Even the swanctl.conf just says "proposals = default" and "esp_proposals = default".

It would be nice if there was a place in the GUI where you can actually see them.

I actually found the default proposals by setting CFG ("Configuration management and plugins") to level 2, here they are:

Code Select Expand

2026-02-26T08:18:01 Informational charon 15[CFG] <422831> configured proposals: IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/CAMELLIA_CTR_128/CAMELLIA_CTR_192/CAMELLIA_CTR_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/CURVE_448/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_CCM_16_128/AES_CCM_16_192/AES_CCM_16_256/CHACHA20_POLY1305/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_CCM_12_128/AES_CCM_12_192/AES_CCM_12_256/AES_CCM_8_128/AES_CCM_8_192/AES_CCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/CURVE_448/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048

Hi, I have a problem connecting our OPNsense with a FortiGate device.

Here is the IPsec log:

Code Select Expand

2026-02-25T15:00:59    Informational    charon    07[ENC] <353286> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]   
2026-02-25T15:00:59    Informational    charon    07[CFG] <353286> no matching peer config found   
2026-02-25T15:00:59    Informational    charon    07[CFG] <353286> looking for peer configs matching 185.xxx.xx.xx[%any]...195.yyy.yyy.yyy[195.yyy.yyy.yyy]   
2026-02-25T15:00:59    Informational    charon    07[ENC] <353286> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]   
2026-02-25T15:00:59    Informational    charon    07[NET] <353286> received packet: from 195.yyy.yyy.yyy[500] to 185.xxx.xx.xx[500] (480 bytes)   
2026-02-25T15:00:59    Informational    charon    07[NET] <353286> sending packet: from 185.xxx.xx.xx[500] to 195.yyy.yyy.yyy[500] (456 bytes)   
2026-02-25T15:00:59    Informational    charon    07[ENC] <353286> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]   
2026-02-25T15:00:59    Informational    charon    07[CFG] <353286> selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048   
2026-02-25T15:00:59    Informational    charon    07[IKE] <353286> 195.yyy.yyy.yyy is initiating an IKE_SA   
2026-02-25T15:00:59    Informational    charon    07[ENC] <353286> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]   
2026-02-25T15:00:59    Informational    charon    07[NET] <353286> received packet: from 195.yyy.yyy.yyy[500] to 185.xxx.xx.xx[500] (672 bytes)   
2026-02-25T15:00:58    Informational    charon    09[NET] <353285> sending packet: from 185.xxx.xx.xx[500] to 195.yyy.yyy.yyy[500] (80 bytes)
IKE IDs are set on both sides and proposals are on default on both sides. Any suggestion?

There is already an old working IKEv1 connection to the same peer with a different firewall (Sophos Astaro) so there won't a be firewall issue.

But I wonder why the line with "looking for peer configs matching" says "[%any]" for the IKE ID when I specifically provided that. Could that prevent OPNsense from finding the Pre-Shared Key combination in the list?

I now added a screenshot which states "When left empty %any is chosen as default" yet it still shows "%any" in the log despite a defined local IP address, is this a bug?

Great, thank you, our update scheme is delayed by one cycle (still at 25.4) to have the most stable version. I hope it will be included in OPNsense Business 25.10.2 when we update later in March.

Hi Stefan,

Thanks, it has been fixed. 👍🏻

Hi Q-Feeds,

I just wanted to mention that the banner in your notification mails doesn't look right in Outlook Classic, it's way too big. At home in my browser on outlook.com it looked fine.
 
Maybe you can fix this. If you don't have Outlook Classic for testing I can look at it after you did some changes.

We use DNSCrypt-Proxy instead of Unbound so it would be nice if we could also use the Q-Feeds blocklist there.

Welches Betriebssystem hat denn das Endgerät? Hat es vielleicht eine eigene Firewall oder einen MAC-Filter, welche die Verbindung unterbricht?

There is no documentation but it's in the source code:

Code Select Expand

        if ($_FILES['pictfile']['size'] > (10 * 1024 * 1024)) {
            $input_errors[] = gettext("The image file is too large. Please upload something smaller than 10MB.");
So file size is limited to 10 MB. I don't see a pixel limit.

I don't know if transparency is supported but I would suggest .png or .gif format for logos and .jpg for photos.

Maybe you are also in the process of hardening your Active Directory.

When you activate LDAP Signing on the domain controller this might break the OpenVPN connections for your users if you have configured LDAP connections to your DC via simple binds.

Sample error message in the OpenVPN Connect client:

Code Select Expand

⏎[Aug 20, 2025, 08:55:52] AUTH_FAILED
⏎[Aug 20, 2025, 08:55:52] EVENT: AUTH_FAILED ⏎[Aug 20, 2025, 08:55:52] EVENT: DISCONNECTED ⏎
The server log is more detailed and shows:

Code Select Expand

2025-08-20T08:55:52 Warning openvpn user 'ACME_HANNEBAMBEL' could not authenticate.
2025-08-20T08:55:52 Error openvpn LDAP bind error [00002028: LdapErr: DSID-0C090330, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v4f7c; Strong(er) authentication required]

Because LDAP Signing seems to be a Microsoft specific thing, see also LDAP Wiki we need to upgrade the connection from LDAP to LDAPS.

You need these prerequisites in the OPNsense configuration before you should enable LDAP Signing on your DC so you won't break your OpenVPN connections (which are using OpenLDAP for authentication).

1. (Self-signed) CA root certificate from the DC copied to "System: Trust: Authorities" on OPNsense ("Import an existing Certificate Authority").

Tutorials how to create a CA root certificate on the DC (without the server role "Active Directory Certificate Services") can be found here:

https://gist.github.com/magnetikonline/0ccdabfec58eb1929c997d22e7341e45
https://schweigerstechblog.de/ldaps-ohne-windows-ca-aktivieren-microsoft/ (German)

Make sure the private key is not of the type "BEGIN ENCRYPTED PRIVATE KEY" because then you will get the following error in OPNsense:

You cannot view this attachment.

("Invalid private key provided")

You can decrypt the key in OpenSSL like this (it will ask for the password):

Code Select Expand

openssl rsa -in ca.key -out ca_plain.key
If you forget to add the CA certificate you will get this error when you test your credentials:

You cannot view this attachment.

("error: error:0A000086:SSL routines::certificate verify failed (unable to get local issuer certificate")

2. Modify the existing server in "System: Access: Servers" to use either "StartTLS" or "SSL - Encrypted" instead of "TCP - Standard" in "Transport".

You cannot view this attachment.

3. Make sure you are using the FQDN of the DC as the hostname instead of an IP address. Otherwise you will get the following error when you test your credentials:

You cannot view this attachment.

("error: TLS: hostname does not match name in peer certificate")

There is a new BIOS/BMC/SUM bundle containing:

BIOS: 2.3 (04/14/2025)
BMC: 04.04 (06/04/2025)
Supermicro Update Manager (SUM): V2.14.0-p9 (10/22/2024) - unchanged

See link in previous posts.