Messages

I had the same problem. Here is what fixed it for me.

I did an update from 24.4.3 to 25.4.1 (VMs on proxmox).
I'm not using the default web GUI port, but I've never had to add the port to the IP settings in the HA configuration.
I have tried though, but it didn't help.

Since my firewalls don't have direct internet access, I had added the proxy environment variable as shown here so I can download updates.
https://docs.opnsense.org/development/backend/configd.html#extending-the-environment

That worked fine, but it broke the HA synchronization.
I can reproduce it. When I create the proxy.conf and restart configd, I immediately get the error message on the HA sync status page.
If I delete the proxy.conf and restart configd, I immediately see the status of the cluster again.

Maybe it will help someone else and save them from getting (even more) gray hair.

Hi, I have an opnsense Business FW currently running 24.10.2_8.

It uses IPv6 for Internet access, which might be the problem.

I get this message when I check for updates.

Code Select Expand

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 24.10.2_8 (amd64) at Tue Apr 29 17:07:09 CEST 2025
Strict TLS 1.3 and CRL checking is enabled.
Fetching subscription information, please wait... No CRL was provided for /CN=opnsense-update.deciso.com
No CRL was provided for /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=RapidSSL TLS ECC CA G1
No CRL was provided for /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G3
done
Fetching changelog information, please wait... [!!] CRL fetch failed for http://cdp.rapidssl.com/RapidSSLTLSECCCAG1.crl (HTTPConnectionPool(host='cdp.rapidssl.com', port=80): Max retries exceeded with url: /RapidSSLTLSECCCAG1.crl (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x2cfbcd3a9dd0>, 'Connection to cdp.rapidssl.com timed out. (connect timeout=None)')))
I have seen that cdp.rapidssl.com does not have an IPv6 address.

I assume this is the reason why it fails to fetch the required CRL.

Is my assumption correct?

It's not a big deal as it still works and I can download the updates thanks to deciso providing an IPv6 address on their update server.
It just takes a little longer to retrieve the updates. It looks like the crl download just gets skipped at some point.

Would still be nice to find out if this is the issue and if it can somehow be fixed.

Thanks.

UPDATE 5:
I disabled the outbound NAT rules and created a 1:1 NAT rule (set to nat NOT binat) for the whole network 10.10.0.0/24 to nat to 2.2.2.88/29.
I then let a ping from four different IPs (from within 10.10.0.0/24) on the pfsense run towards 1.1.0.10.
This worked flawlessly.

Did the same from the three Servers and again only one worked. 

UPDATE 4: When I NAT the three servers to different IPs from the 2.2.2.88/29 all three of them work.
Is it not possible to hide all of the 10.10.0.0/24 behind one IP?

So basically what I do now is

Server1:
10.10.0.143 NAT to 2.2.2.88

Server2:
10.10.0.159 NAT to 2.2.2.89

Server3:
10.10.0.162 NAT to 2.2.2.90

But I do not have enough IPs in the /29 thus wanted to hide all behind one IP.

UPDATE 3:
I switched the IPSec Tunnel to legacy but it behaves the same.
Currently pinging from three servers, one goes through and two don't.
The one that currently works did not work before and vice versa.
From the pfsense the ping always works.

I also activated this option "Disable legacy auto-added VPN rules" but it is still the "IPsec internal host to host" rule that keeps blocking.


I am out of ideas... :-(

UPDATE 2:
I set up a less granular outbound NAT rule specifying the whole 10.10.0.0/24 network and started a ping from two other Servers.
Result: One of the servers works the other does not.

And I now see strange behavior in the Firewall log. It allows but then also blocks...? What is the IPsec internal host to host rule?

Code Select Expand

      Interface         Time                 Source         Destination Proto Label
BLOCK IPsec 2025-04-10T09:08:24 2.2.2.88 1.1.0.10 icmp IPsec internal host to host
PASS  IPSec 2025-04-10T09:08:24 2.2.2.88 1.1.0.10 icmp IPsec internal host to host
NAT   IPsec 2025-04-10T09:08:24 10.10.0.143 1.1.0.10 icmp nat rule

UPDATE:
I just tested a ping from the pfsense with the servernetwork as a source and this works as well.
So this is even more strange.
It only does not work when the ping is started from one of the servers.

[Setup:]

Hey, so here is my setup and question.

TL;DR
Why do outbound or 1:1 NAT rules not work for routed networks (not directly connected)?

Setup:

• 2 Firewalls (pfsense and opsense)
• Servernetwork: 10.10.0.0/24
• Transfernetwork: 172.16.255.0/24
• NAT Mode: Hybrid
• IPSec Tunnel:
  
  • Local: 2.2.2.88/29
  • Remote: 1.1.0.0/14

The Server network is on the pfsense, and the IPsec Tunnel is on the opnsense.
pfsense and opnsense are connected via the Transfernetwork.

Transfernetwork IPs:

• pfsense: 172.16.255.2/24
• opnsense: 172.16.255.3/24

Routes:
pfsense:

• 1.1.0.0/14 GW 172.16.255.3

opnsense:

• 10.10.0.0/24 GW 172.16.255.2

FW rules (for testing):
pfsense:

• Servernetwork: any any allow
• Transfernetwork: any any allow

opnsense:

• ipsec: any any allow
• Transfernetwork: any any allow

2.2.2.88/29 is NOT a network on the opnsense but just something to NAT to. I got this from the remote end, they want NAT in the Tunnel.

So all traffic from 10.10.0.0/24 to 1.1.0.0/14 must be nattet to 2.2.2.88/29.
I created manual SPD entries for 10.10.0.0/24 and for 172.16.255.2/32 on the IPSec Tunnel (I am using connections NOT legacy).

Outbound NAT rule:

Interface: IPSec
Protcol: icmp (just for testing)
Source IP: 10.10.0.0/24
Src Port: any
Dest IP: 1.1.0.0/14
Dest Port: any
NAT IP: 2.2.2.88/32
NAT Port: empty
Log: enabled

Interface: IPSec
Protcol: icmp (just for testing)
Source IP: 172.16.255.2/32
Src Port: any
Dest IP: 1.1.0.0/14
Dest Port: any
NAT IP: 2.2.2.88/32
NAT Port: empty
Log: enabled

When I start a ping from any of the servers in the 10.10.0.0/24 network to 1.1.0.10 I can see these packets arrive on the opnsense on the transferinterface and I can also see them on the IPSec Interface but I do not see a hit on the NAT rule in the log.

When I start a ping from the pfsense to 1.1.0.10 coming from 172.16.255.2 (transfernetwork IP of the pfsense) I can also see these packets arrive on the opnsense on the transfernetwork interface and also see the packets on the IPSec Interface but here I see a hit on the according outbound NAT rule and also see ping replies from 1.1.0.10 going to 2.2.2.88 and the icmp reply is shown on the pfsense.
So exactly as expected.
But why does it not work for the routed server network?

I first thought opnsense does not NAT not directly connected networks but then I found this which tells me it should work the way I am doing it.
https://forum.opnsense.org/index.php?topic=34171.0

I also tested this with 1:1 NAT rules. It behaves the same with the only difference that I do not see a hit of the 1:1 NAT rule in the log for both IPs. So it works coming from 172.16.255.2 without showing a rule hit in the log but it does not work for traffic coming from 10.10.0.0/24.

I hope the setup is clear and you understand what my question is. 

I talked to the customer and it works now. Thanks a lot for the hint.

The Solution was to add the server's public ip (1.1.1.1) as a manual SPD entry on the Tunnel in CIDR notation 1.1.1.1/32.

The NAT rules are correct, as I posted them above.

Ok, I don't know why but because you mentioned it I tried it again and added 1.1.1.1 as a Manual SPD entry and it seems to work now.
I need to double check because I don't have access to the other side but I did see return traffic in the tunnel.

I don't know why it did not work before but well I did so many changes it might be that I had changed something else as well after removing the SPD entry.

Thanks for the help. I will check with the customer again tomorrow and let you know.

Thanks for your answer.
I wouldn't do it like this either but that's a longer story.

I have already tried what you suggest. I added 1.1.1.1 as a Manual SPD entry but that did not help and actually this is not what should be send into the tunnel.
It should be natted back to 192.168.20.1 before it is sent into the tunnel, otherwise, the server that had sent the initial request would drop the packets since it initially requested 192.168.20.1 and not 1.1.1.1.

Hey, I have a problem with an IPSec Tunnel and (double) NAT.

I have a Server on the Internet 1.1.1.1 that I want to reach from a Server connected to our FW via an IPSec Tunnel.

IPSec Tunnel:
Local Network/IP: 192.168.20.1/32
Remote Network: 10.201.0.0/16

Public IP on my FW on WAN Interface: 2.2.2.2
Server IP on the Internet: 1.1.1.1

The Tunnel is up and running.
Clients from the remote Network 10.201.0.0/16 always only connect to 192.168.20.1.
So when they want to access 1.1.1.1:80 they connect to 192.168.20.1:8080

I have a port forwarding rule setup on the ipsec interface saying.
Interface: IPSec
Source IP: 10.201.0.0/16
Src Port: any
Dest IP: 192.168.20.1
Dest Port: 8080
NAT IP: 1.1.1.1
NAT Port: 80

This forwards all traffic going from 10.201.0.0/16 to 192.168.20.1:8080 to 1.1.1.1:80.
I can see in the logs that this rule is working.

I then have an Outbound NAT rule on the WAN interface
Interface: WAN
Src IP: 10.201.0.0/16
Src port: any
Dest IP: 1.1.1.1
Dest Port: 80
Nat address: 2.2.2.2

I can also see in the logs that this rule is working.
Firewall rules are also in place and are working. I do not see any blocks and when I set the connected rules to log I can see that in the logs.

I also see traffic arriving at 1.1.1.1 with the correct source 2.2.2.2.
I can also see traffic coming back from 1.1.1.1:80 to 2.2.2.2 on the WAN Interface.

That is where it stops. The traffic is not sent back into the IPSec tunnel.
As said I do not see any firewall blockings.

It seems like the NAT is not working in the backward direction.
Do I need more NAT rules or should this work due to stateful NAT?

I have to correct myself. The certificates are synced but just not shown under the ACME client plugin certificate tab on the Backup Node.

And the HAProxy config sync works as well now after restarting the service on the Backup node.

Hi, I have two OPNSense configured in a cluster. The sync works fine so far when it comes to fw rules or similar.
What does not work is the sync of HAProxy configuration changes. They are not applied on the second node.

Also let's encrypt certificates are not synced which is a problem because I use those in HAProxy.
I found this https://github.com/opnsense/plugins/issues/589
but it does not say how it should actually be done.

Does that mean let's encrypt certs do not work in an OPNSense Cluster?

Any help is appreciated.