Messages

I've now set hw.vtnet.csum_disable=0 on two OPNsense instances with vtnet interfaces (one amd64, one aarch64).
Will report back with anecdotal observations (remind me if I forget because everything works).

Code Select Expand

options=ec07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS>
Cheers
Maurice

It's still disabled in the OPNsense default tunables. You can change this in System: Settings: Tunables.

Cheers
Maurice

Are you talking about local overrides created by DHCP? Or a real local zone?
For the latter, neither dnsmasq nor Unbound are good options. These aren't authoritative DNS servers. BIND is and it's available as a plugin for OPNsense.

Cheers
Maurice

@neel I had a look: You currently can't build USB installer images (make serial / make vga) on aarch64. The build script wants to add a protective MBR to the image, but this only exists on amd64.

But building an iso image (make dvd) is possible, this has explicitly been enabled for aarch64.

OPNsense 25.7.9 aarch64 packages and sets released. Includes ndp-proxy-go 0.3.0.

Having some build issues with 25.7.9 after switching to my own fork of opnsense/core in 25.7.8. Stand by, I'll figure it out.

@franco No opnsense-update 25.7.9 with removed "pin" feature? Patching that locally on my build system is a bit of a pita...

@neel You mean a bootable USB image with the interactive installer? You should be able to build this with the official github.com/opnsense/tools. Have you tried that?
If you don't want to build everything from scratch, you can prefetch the sets from my repo (see first post).

We've also recently added aarch64 support to opnsense-bootstrap, so another option is to install FreeBSD 14.3 first (using one of their official images) and then convert it to OPNsense.


(Update 25.7.9 is in work.)

If your GUA prefix is dynamic, my general advice is to additionally deploy ULAs and use these in internal DNS zones.

Cheers
Maurice

I tend to agree. This seems to be one of those features from the pre-fork era which hasn't been touched ever since.
Since this only is an issue if you link to OPNsense from a different website, this probably never bothered too many users.

Feel welcome to open an issue (or pull request) on GitHub.

Cheers
Maurice

Just not sure why this update would not be included in the installer.

The installer images get updated twice a year and don't contain any changes made since the last major release. That's a little different to other software where you can typically download an installer for the latest version.

If you need to install the latest version directly, you'd have to build your own image (or use opnsense-bootstrap).

Cheers
Maurice

Some of the older Forum Threads suggest that I should enter the name of the wiki as another alternate hostname in OPNsense. That CAN'T be correct advice, can it?

It actually is correct advice. The Alternate Hostnames are used for two separate features: DNS rebinding checks and HTTP_REFERER checks (as indicated in the UI).

By entering the hostnames of OPNsense itself, DNS rebinding checks pass.

But for HTTP_REFERER checks to pass, you'd also have to enter the hostnames of websites which link to OPNsense, like your wiki.

Would it make sense to have separate fields for DNS rebinding hostnames and HTTP_REFERER hostnames? Maybe.

Cheers
Maurice

Seems

Good luck.

They'll need it. And don't forget plugins, documentation, release notes, ports like opnsense-update (and their man pages), ...

🤣

My general recommendation for setups which are a little more advanced is to bind services like DNS to loopback interfaces:

- Interfaces: Devices: Loopback, create a loopback interface, name it e.g. "Unbound".
- Assign the interface and configure it with static IP addresses (/128 ULA and /32 RFC1918 is fine).
- Services: Unbound DNS: General, set "Network Interfaces" to this loopback interface (only).
- In the DHCP / RA configuration, set the DNS server addresses to the loopback interface's addresses.
- Optional: If you want to force all DNS traffic to Unbound, forward port 53 to the loopback interface's addresses.

Cheers
Maurice

WiFi client mode is very actively being worked on so people can run current laptops with FreeBSD as their day to day OS.

Thanks for the clarification. Though it's debatable whether newly introducing limited support for 802.11ac in 2025 counts as "very actively". ;-) That's more than a decade behind Linux.

But since client mode is what @kernew wants (WAN via WiFi), this might actually be reasonable (when using a supported Intel WiFi module and being okay with good old 802.11ac + WPA2).

If the WiFi (on PCIE) doesn't work with Proxmox+OPNsense - will it work on a separate miniPC with only OPNsense (Intel N100/N150 and 4x 2.5G)?

The primary issues are WiFi in general and WiFi support in OPNsense, not Proxmox. WiFi just isn't very widely used in FreeBSD / OPNsense, even the docs say "results may vary". 802.11ac support for selected Intel adapters has recently been introduced with FreeBSD 14.3, but no idea whether it can be configured in OPNsense. Feel free to experiment, but documentation is limited, you won't get a lot of support in the forum and shouldn't expect things to "just work".

What are some other solutions for building my own network with internet 'from WiFi' (Deco S7)?

Depends on your requirements. OpenWrt generally is a good choice if WiFi support is a priority.

How do people solve the problem of having 'their own' network in hotels or on vacation?

OPNsense seems overkill for that.

Deco has 3x LAN ports and there's a chance I'll be able to connect via cable - so in that case: Deco > cable > GMKtec LAN1 and LAN2 > switch. And then from the switch to the AP, desktop, and the rest - will this improve the situation?

Definitely yes. You'll still be stuck with double NAT for IPv4 and questionable IPv6 support, but that'll always be the case if you're behind some other consumer router. If you need to allow incoming connections for remote access / VPN, you'll need to make configuration changes to the TP-Link (firewall rules / port forwardings).