Messages

Per the release notes there was no change to the nut package.  So what are you all even talking about? :P

With 2.8.5 the NUT widget reports an error.

Listed are the tail ends of ktrace for upsc in 2.8.3 & 2.8.5.

upsc - NUT 2.8.3

VAR SUA1000I ups.temperature "027.0"
    VAR SUA1000I ups.test."
 51229 upsc    RET  read 64/0x40
 51229 upsc    CALL  write(1,33258138185728,18)
 51229 upsc    GIO  fd 1 wrote 18 bytes
      "ups.status: OL LB
      "
 51229 upsc    RET  write 18/0x12
 51229 upsc    CALL  write(1,33258138185728,23)
 51229 upsc    GIO  fd 1 wrote 23 bytes
      "ups.temperature: 027.0
      "
 51229 upsc    RET  write 23/0x17
 51229 upsc    CALL  select(4,34899832816,0,0,34899832800)
 51229 upsc    RET  select 1
 51229 upsc    CALL  read(3,33258138055320,64)
 51229 upsc    GIO  fd 3 read 64 bytes
      "interval "0"
    VAR SUA1000I ups.test.result "NO"
    END LIST VAR SUA1"
 51229 upsc    RET  read 64/0x40
 51229 upsc    CALL  write(1,33258138185728,21)
 51229 upsc    GIO  fd 1 wrote 21 bytes
      "ups.test.interval: 0
      "
 51229 upsc    RET  write 21/0x15
 51229 upsc    CALL  write(1,33258138185728,20)
 51229 upsc    GIO  fd 1 wrote 20 bytes
      "ups.test.result: NO
      "
 51229 upsc    RET  write 20/0x14
 51229 upsc    CALL  select(4,34899832816,0,0,34899832800)
 51229 upsc    RET  select 1
 51229 upsc    CALL  read(3,33258138055320,64)
 51229 upsc    GIO  fd 3 read 5 bytes
      "000I
      "
 51229 upsc    RET  read 5
 51229 upsc    CALL  select(4,0,34899833232,0,34899833216)
 51229 upsc    RET  select 1
 51229 upsc    CALL  write(3,34918619370,7)
 51229 upsc    GIO  fd 3 wrote 7 bytes
      "LOGOUT
      "
 51229 upsc    RET  write 7
 51229 upsc    CALL  shutdown(3,SHUT_RDWR)
 51229 upsc    RET  shutdown 0
 51229 upsc    CALL  close(3)
 51229 upsc    RET  close 0
 51229 upsc    CALL  exit(0)

upsc - NUT 2.8.5

VAR SUA1000I ups.temperature "027.0"
    VAR SUA1000I ups.test."
 93660 upsc    RET  read 64/0x40
 93660 upsc    CALL  write(1,59259719200768,18)
 93660 upsc    GIO  fd 1 wrote 18 bytes
      "ups.status: OL LB
      "
 93660 upsc    RET  write 18/0x12
 93660 upsc    CALL  write(1,59259719200768,23)
 93660 upsc    GIO  fd 1 wrote 23 bytes
      "ups.temperature: 027.0
      "
 93660 upsc    RET  write 23/0x17
 93660 upsc    CALL  select(4,34912627584,0,0,34912627568)
 93660 upsc    RET  select 1
 93660 upsc    CALL  read(3,59259719086744,64)
 93660 upsc    GIO  fd 3 read 64 bytes
      "interval "0"
    VAR SUA1000I ups.test.result "NO"
    END LIST VAR SUA1"
 93660 upsc    RET  read 64/0x40
 93660 upsc    CALL  write(1,59259719200768,21)
 93660 upsc    GIO  fd 1 wrote 21 bytes
      "ups.test.interval: 0
      "
 93660 upsc    RET  write 21/0x15
 93660 upsc    CALL  write(1,59259719200768,20)
 93660 upsc    GIO  fd 1 wrote 20 bytes
      "ups.test.result: NO
      "
 93660 upsc    RET  write 20/0x14
 93660 upsc    CALL  select(4,34912627584,0,0,34912627568)
 93660 upsc    RET  select 1
 93660 upsc    CALL  read(3,59259719086744,64)
 93660 upsc    GIO  fd 3 read 5 bytes
      "000I
      "
 93660 upsc    RET  read 5
 93660 upsc    CALL  getpid
 93660 upsc    RET  getpid 93660/0x16ddc
 93660 upsc    CALL  fstatat(AT_FDCWD,2106259,34912628176,0)
 93660 upsc    NAMI  "/proc"
 93660 upsc    STRU  struct stat {dev=5509020405254355969, ino=538, mode=040555, nlink=2, uid=0, gid=0, rdev=0, atime=1769520096, mtime=1769520096, ctime=1770272166.850398000, birthtime=1769520096, size=2, blksize=4096, blocks=1, flags=0x800 }
 93660 upsc    RET  fstatat 0
 93660 upsc    CALL  fstatat(AT_FDCWD,34912628400,34912628176,0x200<AT_SYMLINK_NOFOLLOW>)
 93660 upsc    NAMI  "/proc/93660/exe"
 93660 upsc    RET  fstatat -1 errno 2 No such file or directory
 93660 upsc    CALL  fstatat(AT_FDCWD,34912628400,34912628176,0x200<AT_SYMLINK_NOFOLLOW>)
 93660 upsc    NAMI  "/proc/93660/file"
 93660 upsc    RET  fstatat -1 errno 2 No such file or directory
 93660 upsc    CALL  fstatat(AT_FDCWD,34912628400,34912628176,0)
 93660 upsc    NAMI  "/proc/93660/cmdline"
 93660 upsc    RET  fstatat -1 errno 2 No such file or directory
 93660 upsc    CALL  fstatat(AT_FDCWD,34912628400,34912628176,0)
 93660 upsc    NAMI  "/proc/93660/stat"
 93660 upsc    RET  fstatat -1 errno 2 No such file or directory
 93660 upsc    CALL  getpid
 93660 upsc    RET  getpid 93660/0x16ddc
 93660 upsc    CALL  fstatat(AT_FDCWD,34933438876,34912628176,0)
 93660 upsc    NAMI  "/proc"
 93660 upsc    STRU  struct stat {dev=5509020405254355969, ino=538, mode=040555, nlink=2, uid=0, gid=0, rdev=0, atime=1769520096, mtime=1769520096, ctime=1770272166.850398000, birthtime=1769520096, size=2, blksize=4096, blocks=1, flags=0x800 }
 93660 upsc    RET  fstatat 0
 93660 upsc    CALL  fstatat(AT_FDCWD,34912628400,34912628176,0x200<AT_SYMLINK_NOFOLLOW>)
 93660 upsc    NAMI  "/proc/93660/exe"
 93660 upsc    RET  fstatat -1 errno 2 No such file or directory
 93660 upsc    CALL  fstatat(AT_FDCWD,34912628400,34912628176,0x200<AT_SYMLINK_NOFOLLOW>)
 93660 upsc    NAMI  "/proc/93660/file"
 93660 upsc    RET  fstatat -1 errno 2 No such file or directory
 93660 upsc    CALL  fstatat(AT_FDCWD,34912628400,34912628176,0)
 93660 upsc    NAMI  "/proc/93660/cmdline"
 93660 upsc    RET  fstatat -1 errno 2 No such file or directory
 93660 upsc    CALL  fstatat(AT_FDCWD,34912628400,34912628176,0)
 93660 upsc    NAMI  "/proc/93660/stat"
 93660 upsc    RET  fstatat -1 errno 2 No such file or directory
 93660 upsc    CALL  select(4,0,34912628592,0,34912628576)
 93660 upsc    RET  select 1
 93660 upsc    CALL  write(3,34933446671,7)
 93660 upsc    GIO  fd 3 wrote 7 bytes
      "LOGOUT
      "
 93660 upsc    RET  write 7
 93660 upsc    CALL  select(4,34912628592,0,0,34912628576)
 93660 upsc    RET  select 1
 93660 upsc    CALL  read(3,34912628784,512)
 93660 upsc    GIO  fd 3 read 11 bytes
      "OK Goodbye
      "
 93660 upsc    RET  read 11/0xb
 93660 upsc    CALL  shutdown(3,SHUT_RDWR)
 93660 upsc    RET  shutdown 0
 93660 upsc    CALL  close(3)
 93660 upsc    RET  close 0
 93660 upsc    PSIG  SIGSEGV SIG_DFL code=SEGV_MAPERR

Did a quick trace of 2.8.5 and it appears to use /proc, whereas 2.8.3 doesn't. I don't know if this has anything to do with it.

Today I enabled Unbound on OPNsense and configured it to connect to Quad9's upstream servers with IP addresses 9.9.9.9 & 149.112.112.112. Below is an extract from my notes.

I also run Unbound on an internal system. It's been reconfigured to forward upstream to OPNsense.

Reading your post I then tweaked the settings in Unbound on OpenBSD and set "forward-tcp-upstream: yes". Using pftop on OPNsense I can watch the TCP DNS queries from OpenBSD. I also ran tcpdump of port 53 to OPNsense on OpenBSD.

I'm with iiNet who default to having a lease time of 1800 seconds. Their allowable lease time range is 300 to 3600 seconds. You could experiment with your Optus service and see what ranges you can obtain.

I dropped my DHCP lease time down to 300 seconds and monitored the DNS queries. My observations aren't conclusive but it appears OPNsense gracefully closes connections periodically and not necessarily when the DHCP lease is renewed.

Is there something preventing you upgrading your system to 26.1.7_3?

OPNsense DNS Configurations:

Quad9 already performs DNSSEC validation. Disable it in OPNsense:

1.   Services -> Unbound DNS -> Advanced -> General Settings
1.1.   Aggressive NSEC: un-ticked
1.2.   Strict QNAME Minimisation: un-ticked
1.3.   Apply the settings

Set up forwarders for all zones to upstream DNS servers:
2.   Services -> Unbound DNS -> DNS over TLS -> Custom forwarding
2.1.   Create a custom forwarding entry by clicking on "+"
2.2.   Leave the Domain field empty
2.3.   Server IP: 9.9.9.9
2.4.   Server Port: 853
2.5.   Verify CN: dns.quad9.net
2.6.   Description: Quad9 Threat-blocking with DNSSEC
2.7.   Click on Save
2.8.   Create another custom forwarding entry
2.9.   Leave the Domain field empty
2.10.   Server IP: 149.112.112.112
2.11.   Server Port: 853
2.12.   Verify CN: dns.quad9.net
2.13.   Description: Quad9 Threat-blocking with DNSSEC
2.14.   Click on Save

Disable System Nameservers:

3.   Services -> Unbound DNS -> DNS over TLS - > Use System Nameservers
3.1.   Ensure this option is un-ticked.
   N.B. This setting is also carried over to Query Forwarding.
3.2.   Apply the settings

Enable Unbound:

4.   Services -> Unbound DNS -> General
4.1.   Enable Unbound: ticked
4.2.   Listen Port: 53
4.3.   Apply the settings

I've attached the image of my System -> Settings -> General. Note, I've disabled the option to Allow DNS server list to be overridden by DHCP/PPP on WAN.

Also attached is an image of my DHCP client configuration settings. The Lease Requirements is where I've applied settings. My DHCP requests only asks for the subnet mask and default gateway - that's all.

Hopefully this helps you.

[Disable outbound NAT rule generation (outbound NAT is disabled)]

A fresh install of 26.1.2 sets the mode to Disable outbound NAT rule generation (outbound NAT is disabled).

With 26.1 we now use Source NAT and Destination NAT.

I would suggest you create your outbound NAT rules using Source NAT and enable the Log option there.

When creating rules, you can enable the Log option too.

The default installation includes two rules on the LAN interface which have the Log option disabled by default. To enable logging of these rules go to Firewall -> Rules [new];

• Enable Inspect
• Enter LAN network in the search field
• Click on link under Commands for Default allow LAN to any rule and enable logging, then save
• Click on link under Commands for Default allow LAN IPv6 to any rule and enable logging then, save

I must be the only one here who's seen many dupe macs on laptops and pc's.

I'm a network engineer for more than three decades and I have never seen a single duplicate MAC address. 🤷�♂️

I've only ever heard of this once and it was some 30 years ago, from someone I knew. They had supplied a school with new computers and installed NIC's in all of them.

The first computer connected to the network and worked just fine. When more computers were connected to the network, problems ensued and they were all failing to communicate - the root cause was the (cheap and cloned) NIC's, which all had the same MAC address.

The only time I would expect to see the same MAC address used more than once, is if the interface is configured with VLAN's.

Off-beat, I am aware of a Ubiquiti device failing spectacularly and deciding it wanted to claim to have the address for every ARP request seen on the network and offered its MAC address in response.

The main reason to leave Q-Feeds to update just after midnight is to see if the Events would be cleared, which they aren't. It appears there is a hard limit of 50,000 entries and once this is reached, no more entries are recorded.

I see now, these logs are taken from the filter logs. I thought I disabled the logging of the relevant rules later than the time in the Events view. ;)

I'm not sure what you mean by pf

My reference to PF is Packet Filter - pf.

I was referring to your Unbound image. I can't see the end of the URL feed_type and assumed you meant the IP feed.

I don't have many services open to the Internet, so gauging the "Quality" is not so easy as all the inbound connections I see being blocked are legitimate and do not pose any problems. It also depends on what miscreants are doing on any given day too.

The best way for me to gauge the quality of the lists I'm using is by what gets blocked internally and thus preventing connections to the Internet.

The blocks I do see from one of my lists is to a GitHub address. It does not seem to pose a problem because the firewall policy is sending a reject to the internal client, which then tries the next host. I also apply this policy directly on the WAN connection, so when OPNsense is updating Aliases with URL tables, the logs show these connections being blocked, but as there is more than one IP address associated with the FQDN, the next address is used.

In the past 24 - 36 hours I've noticed one of my other block lists preventing connections out to the Internet - I don't know if these are false-positives, but there is no perceivable problems from these blocked connections.

I am a weird one.  rather against installing a lot of plugins.

when I subscribed I opened a ticket and got instructions for manually adding an alias(url table IP) and how to add it as a blocklist to unbound.

--I may have gotten the idea from one of Patricks screen shots of his adguard configuration --

I am not having that issue

Hmm, I would expect blocking a table of IP's would be best performed in PF. I'm not sure how this would benefit Unbound.

True solution is to empty the folder "/var/db/qfeeds-tables/"
by running these commands:

I've made no changes on my end and left it to check at the time listed in the earlier screen-shot.

It is now back to daily updates and the time appears to be around the time I activated the installation - may be just a coincidence.

The main reason to leave Q-Feeds to update just after midnight is to see if the Events would be cleared, which they aren't. It appears there is a hard limit of 50,000 entries and once this is reached, no more entries are recorded.

Do these Events need to be deleted manually?

Im not sure "total amount of blocks" is a good metric without "quality of individual blocks".

I'm using the number of evaluations for each of the rules to calculate the percentages.

Code Select Expand

Around 8:30AM this morning, I moved the Q-Feeds rule to the top of the list. I've recorded the numbers from around 7:50PM tonight - see attached image.

Today's connections didn't appear to encounter any extraordinary behaviour, unlike yesterday. These are the numbers as of tonight:

         Evaluations      Packets      % Blocked
Q-Feeds:      54536         13426      86.627%
Bitwire-IT:      7293         6593      12.089%
Nothing Else:      700         700      1.283%

I haven't been tabulating the information, just doing some quick calculations at given points in time.

It would be good if the counters didn't reset overnight, at least I could then get data for a longer period - just to make quick calculations on the fly.

I'll look at integrating the Q-Feeds domains at some point, just to see if it picks up anything.

I installed Q-Feeds Communinty two weeks ago.

I created a rule to log all blocked traffic that otherwise wont be logged - the Default Deny rule has had its logging disabled.

Attached is a screen shot of the rules and the count of evaluations/blocked connections by each. 24-hours prior, the numbers were similar with the exception that FireHOL CIArmy had blocked 1 connection.

Doing the sums based upon the details of the evaluations for Q-Feeds and Nothing Else Blocked are;

Q-Feeds: 0.0632%
Nothing Else: 1.7778%

From these numbers, we can deduce Bitwire-IT blocked 98.159% of all blocked incoming connections.

Last night, after updating OPNsense to 26.1.7_3, which incidentally also updated Q-Feed Connector to version 1.5_3, I took this screen shot then disabled three of the listed rules.

Just took a screen shot of these rules a short while ago and you can see Q-Feeds blocked quite a few today. There was just one (persistent) miscreant that has attempted to telnet to my IP address and did so from 02:13am this morning, ceasing at 04:16pm this afternoon (14 hours).

It remains to be seen what Q-Feeds will block for me over the coming months.

Looking at Security -> Q-Feeds Connect -> Feeds, did the update interval change from 24-hours to 48-hours after the connector was updated to version 1.5_3?

The Q-Feeds Connector update was installed at the same time as OPNsense 26.1.7_3.

The .de DNS zone is broken. See here, follow the links - the top two are in English:

https://forum.opnsense.org/index.php?topic=51804.0

Very odd, using Unbound on OpenBSD the MX resolved.

Took a packet capture of queries from a test OPNsense installation and reviewed.

In OPNsense I then disabled:

Services -> Unbound DNS -> Advanced

- Harden Below NXDOMAIN
- Aggressive NSEC

Performed a DNS Lookup in OPNsense and received expected results.

Re-enabled the two settings above and it continues to work - perhaps the issue for .de domains is now resolved.

Mod note: Deleted the spam account and related messages.

Thanks Franco.

Cheers,

Larry.