Recent posts

#1
26.1 Series / Re: 26.1.rc1 -> 26.1 rc2 ........
Last post by Maurice - Today at 02:29:34 AM
@spetrillo You're not on RC1, you're still on "Development". You need to switch back to "Community", as explained in the RC1 release announcement thread.

Cheers
Maurice
#2
Tutorials and FAQs / Re: OPNsense aarch64 firmware ...
Last post by Maurice - Today at 02:17:35 AM
yrzr has 25.7.x images for the R6S on GitHub. You could start with these and then switch to my repo for more frequent updates.

Bootstrapping from FreeBSD should work, too. Or you could build you own image. There's more than one way.

Pretty much everything should work, except for plugins from third-party repos (including Zenarmor). It would be up to them to offer aarch64 packages.

yrzr did a lot of the heavy lifting for OPNsense on aarch64, my repo probably wouldn't exist without their work.
#3
26.1 Series / Re: 26.1.rc1 -> 26.1 rc2 ........
Last post by spetrillo - Today at 12:55:50 AM
Here you go Franco!
#4
26.1 Series / [ISC vs. KEA] Is this DHCP Cli...
Last post by nero355 - Today at 12:14:30 AM
I was wondering if the following two function the same way or not :

ISC has : Ignore Client UIDs
QuoteBy default, the same MAC can get multiple leases if the requests are sent using different UIDs. To avoid this behavior, check this box and client UIDs will be ignored.

KEA has : Match client-id
QuoteBy default, KEA uses client-identifiers instead of MAC addresses to locate clients, disabling this option changes back to matching on MAC address which is used by most dhcp implementations.

I had the ISC option Enabled so now I have the KEA option Disabled and was wondering if the result is the same :

Ignore Clients sending anything else than their MAC Address when requesting a DHCP Lease ?!



I have tried reading about it in the KEA Documentation on their website, but there was nothing related to this that I could find...
#5
German - Deutsch / Spätes Update von 25.7.8 schlu...
Last post by K.Martinen - Today at 12:08:15 AM
Hallo

Ich habe mehrmals mit gleichem Ergebnis versucht OPN 25.7.8 dieser Tage zu aktualisieren. Die Meldungen sind immer wie unten nur gelegentlich variiert der Name des Pakets, aber nicht die Fehlermeldung.


***GOT REQUEST TO UPDATE***
Currently running OPNsense 25.7.8 (amd64) at Tue Jan 27 23:10:37 CET 2026
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (92 candidates): .......... done
Processing candidates (92 candidates):
pkg-static: mc-nox11 has a missing dependency: python39
Processing candidates (92 candidates)...... done
The following 27 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
hostwatch: 1.0.5

Installed packages to be UPGRADED:
cpu-microcode-intel: 20251111 -> 20251111_1
dpinger: 3.3 -> 3.4
filterlog: 0.7_1 -> 0.7_2
gettext-runtime: 0.23.1 -> 0.26
glib: 2.84.1_3,2 -> 2.84.4,2
libedit: 3.1.20251016,1 -> 3.1.20251016_1,1
libsodium: 1.0.19 -> 1.0.21
libucl: 0.9.2_2 -> 0.9.3
nss: 3.118.1 -> 3.119.1
openvpn: 2.6.16 -> 2.6.17
opnsense: 25.7.8 -> 25.7.11_2
opnsense-update: 25.7.8 -> 25.7.11
os-freeradius: 1.9.28 -> 1.9.28_1
os-theme-rebellion: 1.9.3 -> 1.9.4
pciids: 20251105 -> 20251206
pcre2: 10.47 -> 10.47_1
php83-phpseclib: 3.0.47 -> 3.0.48
png: 1.6.50 -> 1.6.52
py311-anyio: 4.11.0 -> 4.12.0
py311-certifi: 2025.10.5 -> 2025.11.12
py311-numpy: 1.26.4_10,1 -> 1.26.4_11,1
py311-pandas: 2.2.3_3,1 -> 2.3.3,1
py311-tzdata: 2025.2 -> 2025.3
py311-urllib3: 2.5.0,1 -> 2.6.0,1
suricata: 8.0.2 -> 8.0.3
unbound: 1.24.1 -> 1.24.2

Number of packages to be installed: 1
Number of packages to be upgraded: 26

The process will require 7 MiB more space.
24 MiB to be downloaded.
[1/1] Fetching cpu-microcode-intel-20251111_1.pkg: ..
pkg-static: cached package cpu-microcode-intel-20251111_1: missing or size mismatch, fetching from remote
Fetching cpu-microcode-intel-20251111_1.pkg:
pkg-static: cached package cpu-microcode-intel-20251111_1: missing or size mismatch, cannot continue
Consider running 'pkg update -f'
Fetching cpu-microcode-intel-20251111_1.pkg: ..
pkg-static: cached package cpu-microcode-intel-20251111_1: missing or size mismatch, fetching from remote
Fetching cpu-microcode-intel-20251111_1.pkg:
pkg-static: cached package cpu-microcode-intel-20251111_1: missing or size mismatch, cannot continue
Consider running 'pkg update -f'
Starting web GUI...done.
Partial update failure detected: attempting automatic cleanup.
No further actions will be taken. Please restart the update now.
***DONE***

Die "Lösung" war $Hier ein anderer Mirror. Kann es sein das <Default> als Download-quelle auf eine IP, einen Mirror verwies der jetzt nicht mehr aktuell ist? Das ist zumindet meine Annahme.

N.B. pkg update -f hatte auch keine wirkung.
#6
25.7, 25.10 Series / Re: Having trouble with DNSMAS...
Last post by nero355 - January 27, 2026, 11:59:32 PM
Are you looking for this : https://forum.opnsense.org/index.php?topic=9245.0 ??

Just modify it so it goes to your Pi-Hole :)

You can also run Unbound next to your Pi-Hole by the way : https://docs.pi-hole.net/guides/dns/unbound/
I am using this setup for many years now without any issues!
#7
25.7, 25.10 Series / Re: GeoIP list no more correct...
Last post by IPinfo - January 27, 2026, 11:39:52 PM
Hi,

My apologies for the delayed response. I quickly checked the file you shared, and I think there could be a data parsing issue of some sort or some kind of error that happened after the CSV was uncompressed.

It is not our data issue or something on our end. In the file, the total number of IPv4 addresses (expanded from the CIDR) is 45,075. It should be about 13.5 million.

I wish I could provide additional insights, but I am extremely confident it is not something on our end. A data level issue of this scale would be incredibly significant. I did not see any support tickets on our system.

If there are any issues in the future, check our website then let me know. We are always happy to help.

— Abdullah | DevRel, IPinfo
#8
General Discussion / Re: GeoIP not working
Last post by IPinfo - January 27, 2026, 11:25:39 PM
Hi,

I work for IPinfo. We have rate limits, but I am not 100% sure if this is affecting your ability to download our database. I am really not sure what we can do here. If you can download the database directly, you should be able to download it via OPNsense as well. Also, you mentioned you switched IP addresses, which should also reset your rate limit.

— Abdullah | DevRel, IPinfo

#9
26.1 Series / Re: 26.1.rc1 -> 26.1 rc2 ........
Last post by donks - January 27, 2026, 10:51:45 PM
My upgrade worked but threw an error due to a missing file.

Quote***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.1.r_9 (amd64) at Wed Jan 28 08:36:56 AEDT 2026
...

Installed packages to be UPGRADED:
   dhcp6c: 20250513 -> 20260122 [OPNsense]
   hostwatch: 1.0.6 -> 1.0.9 [OPNsense]
   opnsense-devel: 26.1.r_9 -> 26.1.r_31 [OPNsense]
   opnsense-lang: 25.7.4 -> 26.1 [OPNsense]
   os-isc-dhcp-devel: 1.0 -> 1.0_3 [OPNsense]

...

[5/5] Upgrading os-isc-dhcp-devel from 1.0 to 1.0_3...
[5/5] Extracting os-isc-dhcp-devel-1.0_3: .......... done
pkg-static: Fail to rename /usr/local/opnsense/mvc/app/views/OPNsense/DHCPv4/.pkgtemp.leases.volt.5NMo68svvktN -> /usr/local/opnsense/mvc/app/views/OPNsense/DHCPv4/leases.volt:No such file or directory
Skipping already installed legacy ISC-DHCP plugin...
Starting web GUI...done.
Partial update failure detected: attempting automatic cleanup.
No further actions will be taken. Please restart the update now.
***DONE***

For context, after the upgrade to RC1, I removed the ISC-DHCP related plugins, as I have already moved to kea DHCP.

Update: I noticed that the OS-ISC-DHCP-DEVEL plugin automatically keeps getting reinstalled. I remove it from the plugins, restart web-gui and can then see all ISC DHCP services removed. Shortly after the ISC DHCP services are restored and when I check plugins, the OS-ISC-DHCP-DEVEL has been installed.
#10
High availability / Re: CARP WAN VIP not reachable
Last post by chiro - January 27, 2026, 10:50:34 PM
Hi,
We recently ran into exactly the same behavior described in this thread, and after a fair amount of digging I wanted to share what we found and how we worked around it.


Symptoms (same as described above)

CARP works reliably on LAN / internal networks
CARP on the WAN interface behaves inconsistently
ARP resolution looks correct
Sometimes the first ICMP packet works
Subsequent traffic is dropped or blackholed

On the switches, we observed:
ARP table is correct (VIP → CARP virtual MAC)
MAC address table never learns the CARP virtual MAC
As a result, unicast traffic to the VIP is not forwarded reliably

Why this happens (key point)

This is not really a CARP bug, but an interaction between floating L2 identities and virtualized switching.

In virtual environments (ESXi + distributed switches in our case):
CARP replies ARP with the correct virtual MAC (00:00:5e:00:01:XX)
However, frames sourced with that MAC are not always learned by physical ToR switches
Even with Forged Transmits, MAC Address Changes, and Promiscuous Mode enabled

On LAN networks, this often works because:
Traffic stays inside the hypervisor or distributed switch
The physical switch is never involved
The CARP MAC does not need to be learned upstream

On the WAN, traffic must traverse physical uplinks:
The ToR switch must learn the source MAC
The CARP virtual MAC is never learned
Result: ARP resolves, first packet may pass, steady-state traffic fails

This explains why the issue appears WAN-only and why it is so inconsistent.


Workaround / design pattern that worked reliably for us

We solved this by separating HA control-plane from data-plane identity:
Keep CARP for state and master election only
Do not use the CARP VIP for production traffic
Create a plain IP Alias (no VHID) for the production IP
Move that alias between nodes based on CARP MASTER state


This way:
The production IP always uses the physical interface MAC
The switch can learn the MAC normally
CARP still provides HA logic and state sync
WAN traffic becomes stable and predictable


We implemented this using Monit and a small script that:
Adds the alias on the CARP MASTER
Removes it on the BACKUP node


Example logic (simplified):
if ifconfig | grep -q "carp: MASTER vhid 1"; then
    ifconfig vmx1 inet <PROD_IP>/24 alias
else
    ifconfig vmx1 inet <PROD_IP>/24 -alias
fi



Monit runs this every few seconds, so failover and failback are fast.


Conclusion

This seems to be a general limitation when using floating virtual MACs on WAN interfaces in virtualized environments, especially when traffic must traverse physical switching.
The workaround above has been stable for us and avoids relying on a MAC address that the physical fabric never learns.

Posting this in case it helps others who run into the same issue — happy to clarify or compare notes.