Messages

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

Bei den Query Forwardings musst Du die IP-Adresse eines DNS-Servers deines Providers eintragen, nicht die IP-Adresse des SIP-Servers. Die DNS-Server findest Du z. B. unter Interfaces / Overview / WAN / Details / Dynamic nameserver received.
Der SIP-Port 5060 hat dort auch nichts zu suchen.

OPNsense verwendet in den Standardeinstellungen nicht die DNS-Server des Providers, sondern seinen eigenen rekursiven Resolver. Ist schließlich keine Fritzbox.

I was indeed wondering which mirror gets used with the default "(default)" setting. That's kind of obfuscated. 😅 But I eventually figured out that opnsense-update reads the "url" value from repos/OPNsense.conf, which does get set to CORE_PACKAGESITE at build time.

Until now, I didn't modify CORE_PACKAGESITE, hence I had to inject my mirror into config.xml.sample. Starting with 25.7.8 I will stop doing this since it's no longer necessary with the correct CORE_PACKAGESITE.

Modifying repositories/opnsense.xml isn't really necessary, correct. I just thought it would make sense to remove the amd64 mirrors while I'm at it.
Going forward, it might make sense to add an "architecture" property to each mirror in repositories/opnsense.xml. Mirrors could offer a single or multiple architectures. The GUI then could only display the mirrors which offer the system's architecture.

Cheers
Maurice

@franco

Looking better? Want to give it a try? Feedback welcome!

https://github.com/opnsense/core/compare/stable/25.7...maurice-w:opnsense-core:stable/25.7

If you use 2a02:898:331:1::/64 for the OPNsense LAN, you'll need a static route on the Proxmox host which routes this prefix to the OPNsense WAN address.

You added the route to vmbr1 (the LAN bridge). You need to add it to vmbr0 (the WAN bridge).

Hey Franco,

Nice!

I don't use maurice-w/opnsense-core for building OPNsense aarch64. When starting the build process, a script locally injects my fingerprints and custom mirror into opnsense/core and makes a plist-fix.

Your patch to opnsense-bootstrap might motivate me to change this. I'll look into it!

Cheers
Maurice

Der FQDN des SIP-Servers lässt sich bei vielen Providern nur über deren eigene DNS-Server auflösen, die OPNsense aber im Normalfall nicht verwendet.

Falls Du Unbound verwendest, dann kannst Du dort ein Query Forwarding für den SIP-FQDN auf einen DNS-Server deines Providers anlegen.

Grüße
Maurice