Messages

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).

It would make way more sense to connect the wired WAN directly to OPNsense and the TP-Link device (in AP mode) to the OPNsense LAN port. You then could also use the TP-Link's additional Ethernet ports as a switch for your LAN.

If this is purely experimental and you can't get a wired WAN connection, I'd explore setting up the WiFi connection in Proxmox. WiFi support in FreeBSD / OPNsense is very limited.

For IPv4, you would indeed end up with (at least) double NAT.
For IPv6, it depends on whether the TP-Link device supports prefix delegation.

That's quite a challenge for a complete beginner. I'd recommend a simpler setup for your first steps with OPNsense.

Cheers
Maurice

Die saubere Lösung ist, den Local Zone Type auf always_transparent zu stellen (Unbound DNS / General, ganz unten). Dann werden Anfragen für die lokale Zone immer weitergeleitet, auch wenn Unbound dazu selbst Daten hat.

Grüße
Maurice

Done, works! Thanks a lot!

https://opnsense-update.walker.earth/FreeBSD:14:aarch64/25.7/latest/All/opnsense-update-25.7.8_1.pkg

And I created a cron job on the server for fetching the bogons daily.

Cheers
Maurice

Sure, done! That was one of the options we discussed back then.
How often do the bogons get updated? I'd probably just update them along with the changelog.

Cheers
Maurice

@Franco Changing the CORE_PACKAGESITE worked, but it has a side effect - changelogs and bogons can't be downloaded anymore.

We had a similar issue before (there is no aarch64 path on pkg.opnsense.org); you then hardcoded amd64 for downloading these:
https://github.com/opnsense/core/commit/f35db24e

But later, you replaced the hardcoded pkg.opnsense.org with opnsense-update -X:
https://github.com/opnsense/core/commit/b8b3da07

Result after changing CORE_PACKAGESITE:
Fetching changelog information, please wait... fetch: https://opnsense-update.walker.earth/FreeBSD:14:amd64/25.7/sets/changelog.txz: Not Found

Ideas?

OPNsense 25.7.8 aarch64 packages and sets released.

[Update 2025-11-27]
opnsense-update 25.7.8_1 released.

PPP interfaces don't really need a gateway IP address - it's point-to-point, there's no ARP involved.

@Monviech Could we work around this by assigning random (or static) dummy IP addresses to PPP gateways?

@charles As a workaround, maybe creating static gateways with random IP addresses works?

Cheers
Maurice