Topics

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 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'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?

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.

I'm noticing huge throughput differences between development and production.  I had shaper configured to improve bufferbloat on a 400mb cable pipe from Spectrum.  Where I was previously getting ~350-350mb down/~20up I get ~50mb down/~20 up on dev.  I also had major issues with a Zoom last night where the video was buffering and dropping.

On the waveform bufferbloat test, I was previously getting +7ms down/+0 up with my shaper config on prod, I'm getting ~+26ms down/ ~+7ms up, and the bandwidth takes a nosedive.

I'm noticing that ntp queries are being misclassified as proxy.

Example attached.