Topics

Dear all,

maybe the following issue has been reported previously, but up to now I was not able to find it. Since several weeks, a strange behavior started to happen on my site-to-site High-Availability openVPN connection. I was first looking at some changes on openVPN, but I then noted that sometimes, both master and backup on client side are telling that they are connected to the master server... which is strange, since I thought that when HA is configured, only 1 VPN connection should be active at a time.

It seems that some weeks ago (with an update of OPNsense probably deployed in March 2025), every time the master is getting synchronized with the backup (I use a cron script for that), the openVPN connection on the backup client is not "restarted", which means that it tries to connect, not taking into account the CARP status. This behavior is strange to me, if the initial statements remain true: the backup client takes over the VPN connection only if the master client is in trouble.

Can somebody confirm if this behavior is wanted? I am on Firmware 25.1.5_5, but the behavior existed on previous versions of the 25.1.5 release. Maybe even before, but this is speculation. I thought all the time that the issue was related to ma change or missconfiguration of openVPN, but it seems now related to the management of the connections only after the synchronization in the HA case.

Interesting detail: If I disconnect the WAN on the master client, wait some short time, then connect it again, the master client takes over the VPN connection and the backup releases its connection. But as soon as I synchronize the states again, both are trying to connect to the server, thus interrupting each other, which makes connection conflicts and reset the connection every 1-2 minutes.

Best regards,
Vincent

Hello,

I have upgraded my DEC690 from 8GB DDR3L to 16GB DDR3L with ECC, and added a second SSD of 1TB to the original 256GB SSD. After reassembling, I encounter cooling issues with the CPU. The design of the thermal contact between the CPU and the heat-sink does not provide a natural mechanical contact pressure, so that thermal paste or even thermal adhesive pads are not providing the required performance. Even with thermal glue, the results are not acceptable.

Does anyone know which material Deciso has used to provide an acceptable thermal conductivity between the CPU and the heat-sink? To my opinion, the thermal design is quite sub-optimal, because there is no controlled pressure applied in this zone (i.e., no screws or anything playing the same role).

Bonus question: if somebody knows how to check that ECC is really used, I would also be very interested. I tried with dmdidecode and with memtest86+, but no information related to memory (first) or ECC (second) could be displayed.

Best regards,
Vincent

Hello,

I have experienced the following strange and unwanted behavior:
I have 2 OPNsense Deciso DEC690 routers configured with CARP. Everything is working well (currently I am on version 22.1). However, I discovered, after the failure of the backup router (thermal issues), that devices which were not statically mapped with an IPv4 IP/MAC couple, have systematically failed to obtain an IPv4 since the backup router has failed. This is working properly when the backup router is on again.

The workaround I found is to delete the IP address filled in "Failover peer IP" under Services -> DHCPv4 -> [LAN1], since it corresponds to the backup router that has failed.

I am wondering if I am the only one experiencing this issue? Maybe I have misconfigured something and therefore obtained this strange behavior? Note that it only occurs with the devices that do not have a couple of IP/MAC mapped.

I do not use any MAC filtering or blacklisting/whitelisting.

Best regards,
Vincent

[but]

I am most probably doing something wrong, and it makes me crazy. Here is my config:

OPNsense 21.1.6-amd64
FreeBSD 12.1-RELEASE-p16-HBSD
OpenSSL 1.1.1k 25 Mar 2021

For all the tests, I am using Firefox (lastest version).

Let's consider the following:
- LAN1 (not a VLAN): Tor is configured to listen on this interface, using SOCKS5: when I configure Firefox with SOCKS5, it works perfectly. The check.torproject.org site is showing that Tor is configured successfully, and *.onion domains are resolved successfully.
- VLAN88 (on same physical interface as LAN1): Tor is configured as Transparent Proxy. The UDP trafic on port 53 is redirected to port 9053. All TCP traffic on all ports is redirected to the port transparent port 9040. The check.torproject.org site is showing that Tor is configured successfully, but *.onion domains are not resolved.

I am using Unbound as DNS resolver/forwarder. I have tried to add none, parts or all of the following commands that I found to make the *.onion domain name resolution work, but without success:

domain-insecure: "onion"
private-domain: "onion"
do-not-query-localhost: no
local-zone: "onion." nodefault

forward-zone:
    name: "onion"
    forward-addr: 127.0.0.1@9053
    forward-first: no

In my understanding, the transparent DNS port 9053 should be doing the *.onion resolution itself (i.e., without any interaction with Unbound), so I should actually not need to add anything in Unbound DNS! I am using exclusively DoT in Unbound, and my DNS servers are only added under "Miscellaneous". Maybe I am wrong here in my understanding, but all the rest was apparently running fine in the last months. The unbound.conf file looks fine.

Can somebody help me to figure out where is my understanding problem?

Hi,

I have 2 issues with my 2 OPNsense routers.

My configuration: OPNsense 21.1.5-amd64 ; FreeBSD 12.1-RELEASE-p16-HBSD ; OpenSSL 1.1.1k 25 Mar 2021
Cable Internet <--> FritzBox 6590 <--> 2x OPNsense DC690 with High Availability <--> LAN Switches and Devices

My cable ISP does not provide IPv6, therefore I am using HE out of the Fritzbox (i.e., the Fritzbox is establishing the IPv4 native connection, and then the HE IPv6 connection).

The DC690 are getting their IP addresses via DHCP. Each DC690 gets an IPv4 via DHCP and an IPv6 via DHCPv6 from the Fritzbox. These IP addresses (IPv4 and IPv6) are defined as static, so they are always the same after reboot or reconnection.

1. The first issue is about the Virtual IP. The IP of the DC690-1 is 172.18.0.101. The IP of the DC690-2 is 172.18.0.102. The Virtual IP (VIP) corresponding to both DC690 IPs in WAN side is 172.18.0.100. Since the 101 and the 102 are attributed by DHCP by the Fritbox and are always the same (because linked to their MAC address), how should I define properly the VIP, to ensure that it will always be 100?
I have tried to set it up in the Fritzbox in the same way as I do it for the two DC690 (i.e., DHCP uses the virtual MAC address and assigns always the same IP which is 100), but if it works quite fine when both DC690 are physically connected to the Fritzbox, it does not work any more when I remove one of the DC690, since the Fritzbox seems to attribute the 100 IP address to the DHCP WAN interface, and I loose then the internet access (not sure why)! Further, I want the 100 address to be declared as "exposed host" in the Fritzbox, so that all the traffic is routed to this VIP. How can I reach this properly? (I do not want to disable DHCP on the Fritzbox, since it would bring other issues).
Any advice how to do this properly? Maybe there is a conflict between the VIP 100 setup in the OPNsense router and the IP 100 assigned by the Fritzbox to the 00:00:05:00:01:01 virtual MAC address?


2. The second issue is quite strange and existed before I have setup the HA configuration and had any VIP (so please consider here that HA and VIP are disabled or not existing and only one DC690 is in the configuration). When I reboot the OPNsense router, in most of the cases, I am unable to loggin over the GUI anymore after the reboot, if I do not disconnect the WAN side of the router during the reboot (important: only during the reboot, since afterwards it seems to have no more effect). Maybe there is something related to DHCPv4 and/or DHCPv6 or Router Advertisement (RA), all provided by the output of the Fritzbox connected to the OPNsense DEC690? How could I investigate this issue and find out to what it is related?
Strangely, if I forget to disconnect the WAN during the reboot, I still have access to the router via SSH, internet is running, the devices on the LAN all get their addresses and gateway address. Any idea where to look to locate the problem?

Many thanks in advance.

Best regards,
Vincent

Maybe somebody found a solution to my problem. I am simply not able to update a dynamic IP through OPNsense (however, it works for my Google Domains, so I expect the issue to be related to the configuration "Custom" and "Custom (v6)" under the Dynamic DNS Service on OPNsense. As a further information: by using my Fritzbox, I am also able to update the IP dynamically, so I am also confident that the online settings at dynu.com in my account are correct (hostnames, passwords, etc...).

Here are my version information:
OPNsense 21.1.5-amd64
FreeBSD 12.1-RELEASE-p16-HBSD
OpenSSL 1.1.1k 25 Mar 2021

Here is my update URL (as stated on this page: https://www.dynu.com/DynamicDNS/IPUpdateClient/PFSense-IPv6):
https://api.dynu.com/nic/update?hostname=my-site.dynu.net&password=MY-IP-UPDATE-PASSWORD

In the logs, I am always getting the following if I insert the Result Match parameter "good|nochg|good %IP%":
/usr/local/etc/rc.dyndns: Dynamic DNS: (Error) Result did not match.

If I do not insert the Result Match parameters, I get the following (which sound good! but unfortunately does not change the IP address if I check on the dynu.com website):
/services_dyndns_edit.php: Dynamic DNS: (Success) IP Address Updated Successfully!

Full log:
2021-05-08T12:12:33 config[29964] /services_dyndns_edit.php: Dynamic DNS: (Success) IP Address Updated Successfully!
2021-05-08T12:12:33 config[29964] /services_dyndns_edit.php: Dynamic DNS: updating cache file /var/cache/dyndns_wan__6.cache: xxx.xxx.xxx.xxx
2021-05-08T12:12:33 config[29964] /services_dyndns_edit.php: Dynamic DNS (): xxx.xxx.xxx.xxx extracted
2021-05-08T12:12:33 config[29964] /services_dyndns_edit.php: Dynamic DNS (): Current Service: custom
2021-05-08T12:12:33 config[29964] /services_dyndns_edit.php: Dynamic DNS (): _checkStatus() starting.
2021-05-08T12:12:32 config[29964] /services_dyndns_edit.php: Dynamic DNS ( via Custom): _update() starting.
2021-05-08T12:12:32 config[29964] /services_dyndns_edit.php: Dynamic DNS (): running dyndns_failover_interface for wan. found igb0
2021-05-08T12:12:32 config[29964] /services_dyndns_edit.php: Dynamic DNS (): xxx.xxx.xxx.xxx extracted
2021-05-08T12:12:32 config[29964] /services_dyndns_edit.php: Dynamic DNS: updatedns() starting


It seems that the configuration is extremely simple, and almost everybody is doing the same on OPNsense, however, it is not working in my case and I have no more idea what to try. I have also tried to send the update through the LAN instead of the WAN (still no result).

Does somebody have a working configuration for Custom and also for Custom (v6)? My IPv4 and IPv6 addresses on WAN side are detected correctly.

Your help would be greatly appreciated.
Best regards
Vincent