Messages

Unifi's "native" intra-vlan L3 routing for switches is handled on vlan 4040, with the default addressing for that vlan as 10.255.253.0/24.  If no devices exist on that subnet when you enable a native Unifi vlan it will assign whatever device that is handling the routing the address 10.255.253.1.

I had been using opnsense as the gateway for all my vlans, but now I'm working through the process to try and migrate the vlan gateways to the Unifi environment.  opnsense needs to first have a vlan device tagged to vlan 4040 on one of your interfaces and configured with the IP address 10.255.253.1.  When you enable the native VLANs on the Unifi switch the switch will automatically create the interface on the Unifi device with the IP 10.255.253.2.  This becomes the transit interface for L3 routing from the Unifi switch to the opnsense firewall.

There are pros and cons here - the main pro being lower latency for LAN traffic.  The con is that ACLs on the Unifi switch are stateless so you don't get as much visibility and control of traffic between VLANs.  If you have IoT or other less trusted VLANs this might require a hybrid configuration where the gateway for more trusted VLANs like home wireless is the Unifi switch while less trusted like IoT use the opnsense firewall as the gateway to allow for stateful rules to manage traffic.

There are some oddities that I am still working through.  My management interface for the Unifi switches is on vlan 1 (untagged) and I am currently seeing lower latency but extremely slow HTTPS traffic with what looks like state errors coming back from the Internet routing in a weird direction.  kea also isn't properly assigning DHCP addresses; I haven't tried with dnsmasq yet.  The solution seems to be moving the management interface on all Unifi devices (as well as the Unifi OS/Unifi network server) to a tagged VLAN managed by the Unifi switch.  It may also require the use of sloppy states, but I haven't gotten that far yet.

Not sure if anyone else (meyergru?) has a Unifi setup where they could experiment with this design.

Following the thread I was able to update the i225-v NICs on my Protectli 4670 to 1.89 from the Billy Curtis github repo.

Based upon some research it seems the latest available firmware for the i225-v is 1.94, but the only publicly available version I can find appears to be a version of the i225-LM firmware that has been patched with a hex editor to work on an i225-v (https://djesko.eu/intel-i225-v-lm-nvm-1-94-fw/).  Has anyone tried this firmware or are they aware of a more "official" firmware image?

Has anyone tested this yet with a protectli device?

Dave posted several times in the past here, on reddit, and on the FreeBSD and OpenBSD mailing lists. LibreQoS is built on Ubuntu Linux and utilizes CAKE. CAKE was never ported to ipfw (or pf) in FreeBSD or OpenBSD. In theory if CAKE were implemented into BSD the Python and rust code in LibreQoS could be refactored for opnsense, but the level of effort required for that is way beyond me.

For now opnsense offers PIE and fq_codel for shaping.

Appears to have been user error on my part.

When using a NAT redirect rule back to pihole, the IP address tracked in pihole will be the opnsense IP. I did not have the opnsense IP in the client list for which adlists are being applied.

For anyone else using NAT redirect rules for DNS: if you are using a DNS filtering solution (pihole, adguard, etc) and also using ACLs in the solution to control which devices have add blocking applied, make sure the IP address for your opnsense device is added to the appropriate client lists in the DNS filter.

I've closed the ticket.

Thanks franco.  I've created a bug report with a more accurate title (https://github.com/opnsense/core/issues/8619).  Not clear on the root cause, but I can at least consistently replicate the changed behavior.  Prior to 25.1.6 I was able to redirect DNS traffic destined to unapproved DNS servers to my pihole.  After 25.1.6 the NAT rule isn't triggering and traffic to port 53 outbound to external servers is occuring.

I have DNS redirect rules set up for specific interfaces.  It seems that the update to 25.1.6 ("firewall: prevent source/destination inversion when multiple nets are selected") is preventing the NAT redirect from triggering.

I've been following Dave Taht's previous post (https://forum.opnsense.org/index.php?PHPSESSID=m3ojpa28lovvbjvj8g6c1eav2o&topic=39046.msg191249#msg191249) and couldn't work out from the bugzilla post if anything ever came of this.  Not sure if franco or others have a sense of what would be required to bring fq_codel performance to parity with Linux.

> FreeBSD 14.0 was released in November 2023.

FWIW, this is just a fact. If we act on release schedules by third parties we can't maintain our own schedules. If we don't look at quality of releases either we run the risk of complaints more than "why haven't you XYZ" as it ends up as "why have you XYZ" much more loudly ;)

Also keep in mind that when comparing to other projects they tend to market everything they did better as sensational, but don't really tell you they avoided FreeBSD 13 with all of its benefits and haven't really put an effort into backporting their changes into this stable version either so nobody who uses FreeBSD 13 can benefit from it in the interrim... which would have been a more standard FreeBSD release engineering policy. But all of this is what it is and we will reach an acceptable goal for ourselves eventually.

Totally fair.  :)  I'd expect the project team is thinking through the right balance.

[WARNING:]

I genuinely hope NOT! This is supposed to be a security platform, not a bleeding edge / use fresh untested code platform.

I mean, they can do what they want of course, but I definitely would not install the 24.7 release if it is FreeBSD 14.1 based. Too new for my tastes.

Seriously? I run FreeBSD 14.0 in (not OPNsense) production so even with the "never run a .0 release" recommendation 14.1 looks like a very reliable bet to me. I sincerely hope the team around Franco and Ad jump to 14.1.

Kind regards,
Patrick

I would tend to agree with Patrick.  FreeBSD 14.0 was released in November 2023.  Some components have been backported into opnsense already.  The code seems relatively stable, and there are noticable performance improvements.

It would be one thing if I were suggesting moving to the FreeBSD 15 codebase, but 14 seems fine so far.  The pfsense people have been running on the 14 codebase for a while, so we have some data from their efforts.  I recall franco suggesting that 14.1 could be an option at some point.  I for one would be happy to see the next release based on 14.1

One may test FreeBSD 14 kernel in OPNSense after selecting the snapshot

Code Select Expand

opnsense-update -zkbr 14-STABLE -a FreeBSD:14:amd64

WARNING:
1)ISC DHCPv4 (and probably ISC DHCPv6) will fail to start (at least in my setup) after applying the FreeBSD 14 kernel, which is due to [object "libcrypto.so.111" not found]. One should migrate to Kea DHCP before test.
2) In relation to [object "libcrypto.so.111" not found], "pkg" command and any binary in relation to libcrypto.so also not working. "pkg-static bootstrap -f" will not solve the problem, as basically all required binary/packages under FreeBSD 14 kernel is not available in OPNSense repo.

Test FreeBSD 14 kernel at your own risk!

This FreeBSD 14.1 kernel indeed boost up wireguard speed.
More information are in https://forum.opnsense.org/index.php?topic=40413.msg198242#msg198242

EDIT 1: add missing -b switch in code. Solely updating kernel without base file will lead to messed-up routing.
EDIT 2: add warning regarding failed ISC DHCPv4
EDIT 3: add warning regarding failed pkg command

I thought about testing on the new kernel, but as you point out base and ports/pkg haven't been updated in line with the kernel yet.

I am not sure if I am looking into the right place. In https://github.com/opnsense/src/blob/volatile/24.7/sys/conf/newvers.sh , looks like 24.7 will be in FreeBSD 14.1.

Code Select Expand

TYPE="FreeBSD"
REVISION="14.1"
BRANCH="BETA1"

If this is true, I really looking forward to test the BETA 24.7 as the performance gain in wireguard is really astonishing.

+1 for me as well.  :)

I recall seeing another post about this a while back, I couldn't find it with the forum search function.

I just saw that FreeBSD 14.1 beta 1 was released, and it's (currently) on target for a June launch.  The roadmap for the next release currently shows refactoring toward the FreeBSD 13.3 codebase.  Would there be any possibility of moving toward 14.1 this summer?  Between some of the updated Intel drivers, network/wireguard performance enhancements, etc I would expect there would be some tangible benefits.

I am running into an issue where I configure a DHCPv4 subnet with a DNS server IP other than the opnsense IP, save the subnet, and when I view the subnet the DNS server has been overwritten as the opnsense server IP.  I can confirm that the opnsense server IP is being handed out by kea.

So good news, bad news.  The bad news is that unbound is still failing after roughly 30 minutes.  The good news is that the patch allows me to restart the service without rebooting.

I'm running 23.7.2 on a brand new Protectli VP4670.  After a clean reboot, things seem to be running fine for roughly 30 minutes, after which unbound seems to be unable to resolve anything.  When I take a look at the logs, I see entries similiar to this:

2023-08-23T22:14:59-05:00   Error   unbound   [72972:2] error: SERVFAIL <connectivitycheck.gstatic.com. AAAA IN>: all the configured stub or forward servers failed, at zone . no server to query nameserver addresses not usable have no nameserver names

I was using DOT with cloudflare, but have also just switched to regular DNS resolution using system resolvers and get the same result.  After rebooting, unbound seems to be able to resolve again.

Has anyone else run into this?  franco or others with the project - any ideas?

Some thoughts/suggestions:

With the way I tend to use dnsbl, it would be ideal to have the dnsbl selection be configured on a per bl basis, with the ability to target/exempt the bl based upon IP, range, network, or alias.  The adlist targeting in pihole provides a great example here; in pihole, you create groups in the "Clients" module and then can target adlists using the "Group assignment" function.

My current configuration uses pihole as the DNS resolver that is handed out to DHCP clients, and opnsense unbound is used as the upstream DNS server for pihole.  If I had the ability to easily add custom blocklists and target blocklists individually, I would get rid of my pihole.