Topics

Just a quick report that I upgraded from the 25.7.11 development version to 26.1.r1, so far without issues.

Switching back to Community doesn't replace the automatically installed os-isc-dhcp-devel plugin with the non-devel version, but I think that's expected. It's an additional manual step which might be worth mentioning in the upgrade instructions.

I keep hostwatch disabled for the time being, so no statement about that.

Cheers
Maurice

Hey everyone,

Inspired by the recent hostwatch experience, I wanted to start a bit of a meta discussion about the Development / Community / Business versions of OPNsense and when to use which. It was my understanding that Development is for public testing, Community is ready for production (although a bit bleeding edge) and Business is extra stable for critical use cases.

From what I see on GitHub and the forum and from my own experience, hostwatch is still in the development phase. For example, a serious issue was reported a month ago and is still open. Nonetheless, it was now moved to the Community version and enabled by default. This feels like a beta test, which I was under the impression you needed to opt-in for by switching to the Development version.

Not blaming anyone, just interested in your opinions about what level of maturity you (can) expect in which version.

Development = beta, Community = stable, Business = extra stable?
Or Development = alpha, Community = beta, Business = stable?

Personally, I mostly use the Community version and occasionally switch to Development when I really need a feature which has not yet been released.

Cheers
Maurice

Upgrade from 25.1.11 to 25.7.r2 went smoothly on four systems so far (switched to Development to unlock the upgrade and back to Community afterwards).

I noticed that the reset to defaults button in System: Settings: Tunables is missing. There is just an empty box where it used to be. Is that on purpose?

Cheers
Maurice

I gave Kea a try by replicating my ISC DHCPv6 configuration.

ISC (works): PD range from ::80:0:0:0:0 to ::f0:0:0:0:0, PD size 60.
Kea (new): Prefix ::80:0:0:0:0, prefix length 57, delegated length 60.

But Kea doesn't merge the range and instead literally leases 0:0:0:80::/60 to 0:0:0:f0::/60.

Any hints appreciated.

Cheers
Maurice

I'm currently experiencing issues with a straightforward dual WAN system: Two gateways, both marked upstream, the primary has priority 1, the secondary priority 2. Gateway monitoring is enabled for both. Default gateway switching is enabled globally. There's also a gateway group where the primary gateway is in tier 1 and the secondary is in tier 2. Trigger level is member down.

When the primary gateway fails, failover to the secondary works fine, both for the default route as well as for the policy rules using the gateway group.

Not so when the primary gateway comes back online. It reliably gets marked as active in System: Gateways: Configuration, but the default route (System: Routes: Status) as well as the policy rules (Firewall: Diagnostics: Statistics: rules) frequently (but not always) stick to the secondary gateway indefinitely.

I remember having had similar issues in the past and that significant improvements have been made in this context. But apparently this hasn't been truly resolved for all scenarios. Are there known open issues in this area? Can't find anything obvious on GitHub at the moment.

The reason why I'm currently noticing this is the primary WAN having more frequent outages, so this might not be a recently introduced issue.

Primary WAN: DHCPv6, request prefix only, interface address configured via optional prefix ID / interface ID setting
Secondary WAN: SLAAC

Cheers
Maurice

The good:
- Condensed information in table view, without having to expand sections.
- Sortable!
- Routes!
- Very detailed information in "Info" view.

The bad:
- Missing information, even in "Info" view: Delegated IPv6 prefix, DNS servers. This was there in the old overview.
- No DHCP reload button for DHCPv6 interfaces without DHCPv4. We fixed this a while ago in the old overview, but it seems it didn't make it to the new one.

The ugly:
- IPv6-only interfaces show "Link Type none".
- Status is only indicated by colour, the shape of the plug symbols is the same. Not great if you have issues seeing red / green.

What are your thoughts?

Cheers
Maurice

I'm trying to build the OPNsense core package with my own fingerprint added to the trusted fingerprints:

Code Select Expand


cd /usr/tools
make clean-core
make fingerprint > /usr/core/src/etc/pkg/fingerprints/OPNsense/trusted/myfingerprint
echo "/usr/local/etc/pkg/fingerprints/OPNsense/trusted/myfingerprint" >> /usr/core/plist
make core


The resulting OPNsense pkg doesn't include my fingerprint though. What might I be doing wrong?

Cheers
Maurice

[Configure OPNsense to use the repository for downloading updates and plugins]

Hello all,

After testing OPNsense on ARM64 (aarch64) virtual machines for some time, I've decided to make my firmware repository public. It can be used for installing updates and plugins on existing OPNsense aarch64 systems, for quickly building aarch64 images and for turning a stock FreeBSD aarch64 release into an OPNsense installation. Updates typically get published within 24 hours of the official amd64 updates.

https://opnsense-update.walker.earth


Configure OPNsense to use the repository for downloading updates and plugins

• Add the fingerprint to OPNsense:
  

  fetch -o /usr/local/etc/pkg/fingerprints/OPNsense/trusted https://raw.githubusercontent.com/maurice-w/opnsense-core/stable/25.7/src/etc/pkg/fingerprints/OPNsense/trusted/opnsense-update.walker.earth.20250717

• Change the firmware mirror:
  'System: Firmware: Settings'
  Mirror    (custom)
                  https://opnsense-update.walker.earth

Build aarch64 images

• Follow the instructions on https://github.com/opnsense/tools
• Before invoking make arm or make vm, prefetch the sets:
  

  make prefetch-base,kernel,packages MIRRORS=https://opnsense-update.walker.earth

For building VM images, my fork of the OPNsense tools allows configuring the default console. Sample VM images are available in the releases section.


Turn a stock FreeBSD 14.3-RELEASE into an OPNsense installation

fetch https://raw.githubusercontent.com/opnsense/update/master/src/bootstrap/opnsense-bootstrap.sh.in
sh ./opnsense-bootstrap.sh.in -r 25.7 -A maurice-w -R opnsense-core

None of this is supported by Deciso or the OPNsense core team! Use at your own risk.


Thanks to everyone who contributed to OPNsense-aarch64. I only use the tools others have created.

Cheers
Maurice

GitHub Sponsors is available as an option if you'd like to support these efforts.

The public key for my 25.7-aarch64 packages and sets is:

Code Select Expand

-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkhhwmtv1L9kc72AL54u6
KDXwJnbNzvh5vJsAJ1XiZ9G/g5AMdHRZeGxd2ymtLNdJCyTo21a6vOqw93cqQekL
hnL8rFk16LJhCNV6JUK/51584JLOxh+yWngbpMkQ1+cvF/0KSPYPH7FzbyWA+Rir
2EejICLc5UpRXqnHCJeczyjew6acW2oTRB9LAZyl/2dqdM4j4GtF1E/1qgbGCTh6
gGsdLyXSKElvvmVVwmIEJz5H0RrjiXck44KKUi7stiI8CzaWvXfNn6nG9Jw007pq
wQ0P+cTIg2iDLjIf9uHDAwLr3djKT7eU5uK5Gr3x7JdHzO4QSiYHSSdlSFLO5Pux
4YBwpB0WXn0+LO7OKRbZRG3SjS7T23yAkiq+ss/Md3VCPdcXozsehRYwD25ar1uP
3OKWEf3HB8KAjZsg6UBBgF1wFDiyBQ9GeOuAAbi8CUJ9zZK4qCPORyy9cLI0FPfL
+lqlHfjICPVyvlMXn2tP1ktt/ax11KOUg9VvSkYg8RHu38t0f+8X6vbPwKifaNvT
QK7K9eJkh54VMZcVvsiXTgqmYVHdNhdR/DoExfI1VPPqxf6WhjHTiTbIJOw2N5Mv
gcGRkUARQXLjqFjraKB/dOygTDUmFawG/hqlZ8SVO5fFeQ2GudaYIeOshxBAVfe0
rKYTZl4VTpQSdgeKfr9wwR0CAwEAAQ==
-----END PUBLIC KEY-----


There are (at least) three ways to set up an OPNsense VM:

• Install from scratch using an installer image,
• use a preinstalled FreeBSD VM image and convert it to OPNsense using opnsense-bootstrap,
• build a preinstalled VM image using the OPNsense tools.

I've always preferred the last method and recently streamlined and documented my workflow:

https://github.com/maurice-w/opnsense-vm-images/blob/master/README.md

Thanks a lot to Franco for patiently explaining some of the more obscure build steps!

Cheers
Maurice

[tag]

Hello everyone,

I've recently built lots of OPNsense images. Took me a while to understand targets, devices, extras etc., but I think I've got it now. With one exception: versions. I'm struggling to reproducibly build a specific OPNsense version (like Git tag 23.7).

According to the opnsense/tools readme:

   VERSION: a version tag

So building a 23.7 DVD should work like this:

Code Select Expand


# cd /usr
# git clone https://github.com/opnsense/tools
# cd tools
# make update dvd VERSION=23.7


The resulting image is named OPNsense-23.7-dvd-amd64.iso, but identifies as OPNsense 23.7_15. And make info says:

Code Select Expand


tools /usr/tools 23.7_1 5616784d9 master
src /usr/src 23.7_6 6cf2e77cb stable/23.7
ports /usr/ports 23.7_81 e9b5a0ed7 master
plugins /usr/plugins 23.7 f183c06d8 stable/23.7
core /usr/core 23.7_15 0ff09cab7 stable/23.7


It seems the heads of the master and stable/23.7 branches are used, not the tag 23.7. Probably a pebkac, maybe someone can shed some light on this.

Cheers
Maurice

I hope you're all doing well.

Oracle Cloud offers a VM shape based on Ampere Altra CPUs (VM.Standard.A1.Flex). It's more affordable than AMD / Intel shapes and has a generous free tier, so I decided to give it a try. I built an OPNsense-23.1.11-ufs-vm-aarch64.qcow2 image, imported it as a custom image and used it to create an Ampere instance. If you know your way around OCI, this is pretty straight forward and works surprisingly well. Initial interface assignment and root password change can be done with the cloud shell. Next, you can allow access to the Web GUI by adding an ingress rule to the VCN security list, then configure everything else as usual.

I did have to patch extras.conf to enable the serial console menu out of the box, other than that it's a standard VM build:

Code Select Expand

make update DEVICE=ARM64
make vm-qcow2,20G,off DEVICE=ARM64

The main caveat is the lack of a public update / plugin mirror for aarch64. If there is interest in this, I might consider running one. I also thought about making the image available as an OCI community image, but knowing that cloud images are part of Deciso's commercial offerings, I'd rather not. Feedback welcome.

If you want to build it yourself, here are two lessons I had to learn the hard way:

• Don't use the FreeBSD 13.1 OCI partner image for your build system. It has only 800k inodes, you will run out a few hours into the build. Instead, import FreeBSD-13.1-RELEASE-arm64-aarch64.qcow2 as a custom image. This has 6M inodes.
• OCI custom images default to BIOS boot, which doesn't work with FreeBSD / OPNsense aarch64 VM images. To enable UEFI boot, click Edit image capabilities and Save changes (you don't have to change anything).

Cheers
Maurice

Hello devs,

There are currently two ways to configure domain overrides in Unbound: The 'Domain Overrides' tab on the 'Overrides' page (/ui/unbound/overrides/) as well as the dedicated 'Query Forwarding' page (/ui/unbound/forward).

Both create identical 'forward-zone' entries. 'Domain Overrides' adds them to domainoverrides.conf, 'Query Forwarding' adds them to dot.conf.

'Domain Overrides' also adds entries to private_domains.conf: 'domain-insecure' for all zones, 'private-domain' for forward lookup zones, 'local-zone' (typetransparent) for reverse lookup zones. 'Query Forwarding' does none of this, which makes it unsuitable for zones with private addresses and may break DNSSEC validation.

'Query Forwarding' allows specifying a custom port, 'Domain Overrides' doesn't.

I wasn't actively following the development when 'Query Forwarding' was added. Could someone bring me up to speed what the intention behind creating this page was? It seems 'Domain Overrides' is primarily meant for forwarding private zones to internal DNS servers, while 'Query Forwarding' is only suitable for forwarding queries to public DNS servers. Is this assumption correct?

Thanks
Maurice

The default sort order is:

IPv4 default route
other IPv4 routes
IPv6 default route
other IPv6 routes

Once changing the sort order by clicking Proto / Destination / Gateway etc., there seems to be no way back to the default sort order (other than clearing browser cookies).

Am I missing something?

Cheers
Maurice

When creating a dynamic gateway and enabling "Dynamic gateway policy" on its interface, can it be used for policy based routing? The "gateway" has no IP address, the destination is directly reachable.

I can't get this working. Before digging deeper, some input whether this is actually supported would be nice.

"Doesn't work" means: When selecting the dynamic gateway in a firewall rule, the rule shown in pfInfo doesn't have a "route-to" option. When enabling "Skip rules when gateway is down" in the advanced firewall settings, the rule doesn't show up in pfInfo at all. That would suggest the gateway is considered down, but gateway monitoring is disabled and it is shown as online.

man pf.conf(5) suggests route-to doesn't require an IP address:

Code Select Expand

The route-to option routes the packet to the specified interface with an optional address for the next hop.
https://www.freebsd.org/cgi/man.cgi?query=pf.conf

Background: I'm trying to get WireGuard PBR working without the "fake gateway IP address hack" suggested in the docs: https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html
@mimugmail once mentioned that dynamic gateway policy should work, but I couldn't find a confirmation that it actually does: https://forum.opnsense.org/index.php?topic=15105.msg86564#msg86564

Thanks!

Maurice

<edit>
This was indeed a missing feature and it's now fixed: https://github.com/opnsense/core/commit/cdf328078bd3e16e1f4beb9b0d6956595fb59c67
</edit>

When connecting via ssh, I'm now directly presented with the command prompt. No more menu which shows interface information, allows a config restore etc.

Anyone else seeing this? Is this the firmware UI rework mentioned in the release notes?

Cheers

Maurice

I'm now on 20.7.b_136 and noticed that the Interfaces widget doesn't show Virtual IPs any more. Is this intentional? I liked it with the VIPs. :-)

Cheers

Maurice

Hi,

After upgrading from 19.1 to 19.7, OPNsense has issues dealing with gateways which have an IPv6 link-local address:

I have two gateways with a statically configured link-local address (fe80::42%hn1, fe80::42%hn2). After the upgrade, the IP addresses were completely gone for both gateways. Re-entering the addresses was not possible: After clicking "save", the address is gone again. Only after entering the addresses without the zone index was I able to save them. But without the zone index gateway monitoring doesn't work.

Similar issue with the WAN_DHCP6 gateway (where the gateway IP address is assigned automatically via RAs from the ISP): The zone index is missing so gateway monitoring doesn't work.

This might be the same issue, although the description is a bit vague:
https://forum.opnsense.org/index.php?topic=13506.0

[Edit]
The following PHP error seems to be related to this:
PHP Warning:  vsprintf(): Too few arguments in /usr/local/etc/inc/util.inc on line 986
[/Edit]

Cheers

Maurice

Hi all,

I'm trying to get a simple Dual WAN / Dual LAN setup running:
Two WAN interfaces (DHCPv6), two LAN interfaces (LAN1 tracks WAN1, LAN2 tracks WAN2). The WAN1 gateway (WAN1_DHCP6) is the default one. To get traffic originating from LAN2 being routed via WAN2, the gateway is set to WAN2_DHCP6 in the allow-all firewall rule for LAN2 (Policy Based Routing).

No success. LAN1 works just fine, but there is no Internet access from LAN2. This is not a DNS issue (DNS servers are set to external public servers in Router Advertisements). A traceroute from a host in LAN2 to a public IPv6 address doesn't get further than the first hop (router). As expected, switching the default gateway to WAN2_DHCP6 gets LAN2 working and breaks LAN1 Internet connectivity.

Ideas? This should be pretty straight forward, but maybe I am missing something.

Cheers

Maurice

[This is not about requesting a prefix from an upstream router / ISP, but about delegating prefixes to downstream routers in the LAN.]

This is not about requesting a prefix from an upstream router / ISP, but about delegating prefixes to downstream routers in the LAN.

I have a static /48 from my ISP. OPNsense is used as a distribution router and should delegate /56 prefixes to other routers connected to its LAN interface.

Prefix Delegation Range and Prefix Delegation Size are properly configured in Services / DHCPv6 / LAN and downstream routers successfully request prefixes (visible in Services / DHCPv6 / Leases / Delegated Prefixes).
However, OPNsense doesn't seem to add routes for the delegated prefixes to its routing table. So clients connected to the downstream routers can't access the Internet.

Is this working for someone? If so, am I missing something? Or could this be a bug?

Hello all,

This is my first post! :) I'm currently virtualizing a router by migrating from an old embedded Linux box to a fresh install of OPNsense 17.7.7_1 in a Hyper-V VM. Pretty straightforward so far, but now I'm stuck at setting up stateless DHCPv6 for the LANs.

In the existing setup, clients use SLAAC for address autoconfiguration. Clients which don't support the RDNSS / DNSSL options in RAs (like older Windows versions) use stateless DHCPv6 for DNS server and domain information.

In OPNsense, the Router Advertisement "Assisted" mode seems to be the only one which sets the required A and O flags in RAs. But it also sets the M flag which indicates stateful DHCPv6. There seems to be no "A + O flag only" mode. Also, the DHCPv6 server can not be enabled unless you specify an address range.

I've never used an IPv6 router which doesn't support this, so I'm not sure whether this is really missing or I just can't figure out how to configure it (these are my first steps with OPNsense).

Thanks

Maurice