Messages

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.

Looks like wireguard was just committed to the FreeBSD kernel.

https://www.phoronix.com/news/FreeBSD-WireGuard-Lands-2022

What are the current plans for incorporating into opnsense?

Hi all,

Was looking into ways to more easily configure my network to use both opnsense and a pihole for DNS filtering.  The pihole developers wrote up a guide using dnsmasq's edns client subnet support to pass IP information from opnsense to the pihole DNS resolver.  Reading through the man pages for unbound.conf, this appears to be possible, but opnsense configd doesn't appear to have support through the UI to enable or configure edns client subnet support in unbound.  franco or others on the team - is this something you've explored?

Pihole guide for client support with opnsense: https://pi-hole.net/2021/09/30/pi-hole-and-opnsense/#page-content

From the unbound.conf man page:

Code Select Expand

EDNS Client Subnet Module Options
       The ECS module must be configured in the module-config: "subnetcache
       validator iterator" directive and be compiled into the daemon to be
       enabled.  These settings go in the server: section.

       If the destination address is allowed in the configuration Unbound will
       add the EDNS0 option to the query containing the relevant part of the
       client's address.  When an answer contains the ECS option the response
       and the option are placed in a specialized cache. If the authority
       indicated no support, the response is stored in the regular cache.

       Additionally, when a client includes the option in its queries, Unbound
       will forward the option when sending the query to addresses that are
       explicitly allowed in the configuration using send-client-subnet. The
       option will always be forwarded, regardless the allowed addresses, if
       client-subnet-always-forward is set to yes. In this case the lookup in
       the regular cache is skipped.

       The maximum size of the ECS cache is controlled by 'msg-cache-size' in
       the configuration file. On top of that, for each query only 100
       different subnets are allowed to be stored for each address family.
       Exceeding that number, older entries will be purged from cache.

       send-client-subnet: <IP address>
              Send client source address to this authority. Append /num to
              indicate a classless delegation netblock, for example like
              10.2.3.4/24 or 2001::11/64. Can be given multiple times.
              Authorities not listed will not receive edns-subnet information,
             unless domain in query is specified in client-subnet-zone.

       client-subnet-zone: <domain>
              Send client source address in queries for this domain and its
              subdomains. Can be given multiple times. Zones not listed will
              not receive edns-subnet information, unless hosted by authority
              specified in send-client-subnet.

       client-subnet-always-forward: <yes or no>
              Specify whether the ECS address check (configured using
              send-client-subnet) is applied for all queries, even if the
              triggering query contains an ECS record, or only for queries for
              which the ECS record is generated using the querier address (and
              therefore did not contain ECS data in the client query). If
              enabled, the address check is skipped when the client query
              contains an ECS record. And the lookup in the regular cache is
              skipped.  Default is no.

       max-client-subnet-ipv6: <number>
              Specifies the maximum prefix length of the client source address
              we are willing to expose to third parties for IPv6.  Defaults to
              56.

       max-client-subnet-ipv4: <number>
              Specifies the maximum prefix length of the client source address
              we are willing to expose to third parties for IPv4. Defaults to
              24.

       min-client-subnet-ipv6: <number>
              Specifies the minimum prefix length of the IPv6 source mask we
              are willing to accept in queries. Shorter source masks result in
              REFUSED answers. Source mask of 0 is always accepted. Default is
              0.

       min-client-subnet-ipv4: <number>
              Specifies the minimum prefix length of the IPv4 source mask we
              are willing to accept in queries. Shorter source masks result in
              REFUSED answers. Source mask of 0 is always accepted. Default is
              0.

       max-ecs-tree-size-ipv4: <number>
              Specifies the maximum number of subnets ECS answers kept in the
              ECS radix tree.  This number applies for each qname/qclass/qtype
              tuple. Defaults to 100.

       max-ecs-tree-size-ipv6: <number>
              Specifies the maximum number of subnets ECS answers kept in the
              ECS radix tree.  This number applies for each qname/qclass/qtype
              tuple. Defaults to 100.