"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
Cheers
Maurice
#2
Tutorials and FAQs / Re: OPNsense aarch64 firmware ...
Last post by Maurice - Today at 02:17:35 AMyrzr 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.
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 AMHere you go Franco!
#4
26.1 Series / [ISC vs. KEA] Is this DHCP Cli...
Last post by nero355 - Today at 12:14:30 AMI was wondering if the following two function the same way or not :
ISC has : Ignore Client UIDs
KEA has : Match client-id
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...
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 AMHallo
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.
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.
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.
Code Select
***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 PMAre 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!
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 PMHi,
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
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 PMHi,
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
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 PMMy upgrade worked but threw an error due to a missing file.
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.
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 PMHi,
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):
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.
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):
Code Select
if ifconfig | grep -q "carp: MASTER vhid 1"; then
ifconfig vmx1 inet <PROD_IP>/24 alias
else
ifconfig vmx1 inet <PROD_IP>/24 -alias
fiMonit 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.
