Recent posts

#1

26.1, 26,4 Series / Re: VLAN - DHCP/Gateway Issue ...

Last post by nero355 - Today at 02:40:28 PM

Switch with POE+

Also UniFi or something else ?!

And how were you planning to assign the correct VLAN :
- Manually configure Tagged/Untagged a.k.a. Native VLAN assigned to the Switchport.
- Perhaps RADIUS Authentication ?!

[DNS-CloudFlare tag needs to be set on Host.]

#2

26.1, 26,4 Series / Re: DNSMasq - Am I missing som...

Last post by nero355 - Today at 02:28:58 PM

Hosts:

• .1-.89: Clients Static Reservation, use Pihole
• .90-.99: Clients Static Reservation, use Cloudflare.  DNS-CloudFlare tag needs to be set on Host.
• .100-.150: Clients Dynamic, use Pihole
• .200-.253: Infrastructure/Proxmox Static Reservation, use Pihole

I am curious :
What was the reason for choosing to set it up like this instead of having 4 seperate networks ?


Also :
Since you have a lot of Static DHCP Mappings of which a part needs to be outside the Dynamic DHCP Scope I think KEA would have been the better path forward ?!


FYI :
- DNSmasqd wants the Static DHCP Mappings inside the Dynamic DHCP Range.
- ISC & KEA want the Static DHCP Mappings outside the Dynamic DHCP Range.

#3

General Discussion / Re: Business license question ...

Last post by DEC740airp414user - Today at 01:36:10 PM

my Only disappointment with Opnsense is when buying a new appliance the business license starts from the day of your purchase:

I did not realize this on my 2nd appliance and will be losing 3-4 months of the latest license.

  when I setup the new appliance, I used my previous business licensing thinking I could then use the full new license when it expired. when it did expire and I put in the new key it showed I had 9 months remaining..

I then read the email from the appliance purchase and it said it started day of purchase.  live and learn

#4

26.1, 26,4 Series / Re: Change ISC DHCPv6 to KEA D...

Last post by Monviech (Cedrik) - Today at 12:16:53 PM

Hello,

0x17 cannot work with a reserved prefix range of 4 because 4 × /64 networks form a /62, and a /62 must start on a boundary divisible by 4.

Valid starts are:

0x10, 0x14, 0x18, 0x1c, ...

But 0x17 would require the range:

0x17, 0x18, 0x19, 0x1a

which crosses a /62 boundary and therefore cannot be represented as a single contiguous /62 prefix.

So if you want a reserved prefix range of 4, you'll need to use an aligned prefix ID such as 0x14 or 0x18.

Please note it is intentionally this way because you have to think about proper subnetting now. There are no assumptions and no magic left in the code.

I know this might seem a bit confusing at first, but it is essentially just normal IPv6 subnetting. The same alignment rules apply as when splitting IPv4 networks into smaller subnets.

#5

26.1, 26,4 Series / Re: VLAN - DHCP/Gateway Issue ...

Last post by dseven - Today at 12:03:39 PM

OPNsense is assigning the VLAN tag to the devices.

No, it's not (assuming by "device" you mean things like PCs, phones, etc.)

VLAN is a way to take a single physical LAN and logically divide it into multiple virtual LANs. "devices" are usually connected to the LAN via either an ethernet switch or a wifi access point. The devices themselves are not "assigned to" a VLAN, but the switch port or the wifi network to which they are connected is. Using VLANs in this way requires a "managed" switch - i.e. one with some sort of management interface which you can use to configure things like VLAN associations for each port.

Say you plug a PC into a switch port configured for VLAN 100. When the switch receives ethernet frames from the PC on that port, it will tag them with VLAN 100 before forwarding them on. This includes things like DHCP requests. When OPNsense receives ethernet frames tagged with VLAN ID 100, it processes them with its VLAN interface with that ID. The DHCP service would then respond accordingly for that interface (e.g. offering a lease for an IP address on the associated subnet). The DHCP response would be sent back through the same VLAN interface, and would be tagged with VLAN ID 100 and send back to the switch. The switch would strip the tag and forward it on to the PC.

In the case of a wifi device, it would connect to a specific "wifi network" (by SSID). The access point would be configured with associations between wifi networks (SSIDs) and VLAN IDs. When it receives frames for given wifi network, it will tag them with corresponding VLAN ID before forwarding them on, etc.

That's all simplified a bit, but hopefully it helps explain why OPNsense can't "assign a device to a VLAN".

#6

Virtual private networks / FreeBSD native TUN port of usq...

Last post by vamp - Today at 11:33:25 AM

I would like to share an experimental FreeBSD port of usque:
https://github.com/Diniboy1123/usque

The original project is an open-source reimplementation of the Cloudflare WARP client's MASQUE mode, using Connect-IP over QUIC/HTTP/3. It supports several operating modes, including proxy modes and a native TUN mode.

My fork adds initial FreeBSD native TUN support for the nativetun mode. The goal is to make it possible to run usque on FreeBSD/OPNsense and expose a normal tunnel interface, which can then be used manually with routes, firewall rules, gateways, etc.

At this stage this is not an OPNsense plugin yet, only a working FreeBSD-oriented code experiment. Routing, NAT, DNS and firewall integration are intentionally left to the administrator / OPNsense configuration. I am sharing it here in case others are interested in testing, improving, or eventually helping turn this into a proper OPNsense plugin.

Please note that this is not optimized yet, neither on the Go implementation side nor on the FreeBSD TUN handling side. It should be considered a proof of concept / possible implementation approach rather than a polished or production-ready solution. The current goal is mainly to demonstrate that native TUN mode can work on FreeBSD and to provide a starting point for further testing and optimization.

Current status / what works so far:

- Successful connection to Cloudflare WARP, including Zero Trust enrollment/configuration.
- Basic usque functions, such as registration and configuration handling, also work on FreeBSD.
- Native TUN mode successfully creates a FreeBSD tunnel interface.
- Communication through the tunnel works both towards the public Internet and towards another device/server connected through the same Cloudflare Zero Trust environment.
- Manual routing through the created TUN interface has been tested successfully.

In these issue, you found my modified fork: https://github.com/Diniboy1123/usque/issues/106

#7

26.1, 26,4 Series / Re: Change ISC DHCPv6 to KEA D...

Last post by jeans - Today at 11:22:41 AM

You should try with at least a reserved prefix range of 4.

Then 4x /64 are reserved, which results in a /62 prefix available for KEA. It will split this into two subnets. It will take the first /63 for the IA_NA pool, and for the IA_PD pool you will also have /63.

Thanks, that was a crucial tip.

For testing purposes, I've enabled IPv6 on only one interface for now, since I want to keep the addresses on that interface the same as before.
To do this, I entered the following in the interface settings: Assign prefix ID 0x17
Reserved prefix range 4.

When I then enter "Delegated Length 64" in the "Edit PD Pool" section, I get the following message again:   
"Dynamic prefix '2a00:xxxx:xxxx:xx17::/64' is too small to create a non-overlapping PD pool; split prefix length would be '65'."
However, if I enter the following in the interface: Assign prefix ID 0x16
Reserved prefix range 4
it works.
Unfortunately, I don't understand where my mistake is right now... But I'd really like to keep the 17.

#8

26.1, 26,4 Series / Re: i can no longer update fro...

Last post by caplam - Today at 11:07:21 AM

thanks

#9

26.1, 26,4 Series / Re: i can no longer update fro...

Last post by newsense - Today at 10:58:51 AM

Yeah looks good now and you're fully updated.

Feel free to remove ISC if you want.

#10

26.1, 26,4 Series / Re: i can no longer update fro...

Last post by caplam - Today at 10:52:25 AM

I wanted to see the packages output more than the kernel and base...that's why I asked for the full output.


Let's try another health check ?

i'm not at home and took some risks (did it with a vpn connection).
From what i saw all was running good until stopping suricata.
Here is the result of update check.

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.10 (amd64) at Sat Jun 20 10:51:10 CEST 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.1.10 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.10 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
mimugmail (Priority: 5)
>>> Check installed plugins
os-acme-client 4.16_1
os-apcupsd 1.2_3
os-caddy 2.1.0
os-cpu-microcode-intel 1.1
os-crowdsec 1.0.12
os-ddclient 1.31_1
os-freeradius 1.10.1
os-igmp-proxy 1.5_6
os-iperf 1.0_2
os-isc-dhcp 1.0_5
os-mdns-repeater 1.2
os-net-snmp 1.6_1
os-opnarp-maxit 1.0_4
os-q-feeds-connector 1.6
os-unifi9-maxit 1.4
os-wol 2.5_4
os-zabbix74-agent 1.19
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .
isc-dhcp44-server-4.4.3P1_2: missing file /usr/local/share/licenses/isc-dhcp44-server-4.4.3P1_2/LICENSE
Checking all packages............ done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.10 has 68 dependencies to check.
Checking packages: ..................................................................... done
***DONE***i don't use isc dhcp.