"Recent posts
#1
General Discussion / Re: Roku DNS storm is impactin...
Last post by yourfriendarmando - Today at 05:01:50 AMIf you want to shut down more of its telemetry, shut down access to Oracle related networks.
Do a lookup with a tool like
https://hackertarget.com/as-ip-lookup/
search for oracle
and load them into an alias, and make a Floating rule using the alias as destination.
You'll see a little more getting blocked than you think. It breaks WebEx, but I don't trust Oracle at all.
Do a lookup with a tool like
https://hackertarget.com/as-ip-lookup/
search for oracle
and load them into an alias, and make a Floating rule using the alias as destination.
You'll see a little more getting blocked than you think. It breaks WebEx, but I don't trust Oracle at all.
#2
Hardware and Performance / Re: [solved] Intel i226 Firmwa...
Last post by BrandyWine - Today at 04:23:51 AM@and,
Please list your cfg file.
Please list your cfg file.
#3
26.7 Series / Re: System Backup - os-git-bac...
Last post by Maurice - Today at 12:41:00 AMIf you don't want OPNsense itself to use NAT64, then you need to configure a DNS server without DNS64 in System / Settings/ General.
#4
General Discussion / Re: Roku DNS storm is impactin...
Last post by OPNenthu - August 06, 2026, 11:52:59 PMKettlebell drop is arguably the most therapeutic solution ;)
---
I did a few quick tests and spot checked the results in Unbound reporting. In order:
1) Using a Host Override with 127.0.0.1 as the IP and default host TTL (0).
You cannot view this attachment.
2) Using only the DNSBL policy with NXDOMAIN and the cache TTL in the DNSBL policy set to 72000:
You cannot view this attachment.
3) Using only the DBSNL policy with 0.0.0.0 (default) and the cache TTL in the DNSBL policy set to 72000:
You cannot view this attachment.
4) Reverting to Host Override but this time with host TTL set to 3600 in the override:
You cannot view this attachment.
---
I won't pretend to understand some of the things I'm seeing. The only case where the query showed any non-zero TTL in the reporting was with the default DNSBL return value (not using NXDOMAIN) in case #3. I don't know the source of that value though because it doesn't match anything I have configured in Unbound during that test.
Overall however, I can say that none of these has any observed effect on quieting down the Rokus. I'm not sure that chasing TTL tweaks is going to solve this. Remember also, I'm not trying to reduce the number of upstream resolutions. I'm trying to limit ads & trackers, but Roku software seems relentless and uncaring about TTLs in any case I tried so far.
The pf rate limiters remain effective for keeping the CPU under control, but I have yet to confirm if the Rokus behave well enough with this rate limiting. I plan to visit my parents this week and will see for myself how it's working then.
---
I did a few quick tests and spot checked the results in Unbound reporting. In order:
1) Using a Host Override with 127.0.0.1 as the IP and default host TTL (0).
You cannot view this attachment.
2) Using only the DNSBL policy with NXDOMAIN and the cache TTL in the DNSBL policy set to 72000:
You cannot view this attachment.
3) Using only the DBSNL policy with 0.0.0.0 (default) and the cache TTL in the DNSBL policy set to 72000:
You cannot view this attachment.
4) Reverting to Host Override but this time with host TTL set to 3600 in the override:
You cannot view this attachment.
---
I won't pretend to understand some of the things I'm seeing. The only case where the query showed any non-zero TTL in the reporting was with the default DNSBL return value (not using NXDOMAIN) in case #3. I don't know the source of that value though because it doesn't match anything I have configured in Unbound during that test.
Overall however, I can say that none of these has any observed effect on quieting down the Rokus. I'm not sure that chasing TTL tweaks is going to solve this. Remember also, I'm not trying to reduce the number of upstream resolutions. I'm trying to limit ads & trackers, but Roku software seems relentless and uncaring about TTLs in any case I tried so far.
The pf rate limiters remain effective for keeping the CPU under control, but I have yet to confirm if the Rokus behave well enough with this rate limiting. I plan to visit my parents this week and will see for myself how it's working then.
#5
26.7 Series / Re: Performance Issues on 26.7...
Last post by notspam - August 06, 2026, 11:26:23 PMPlease edit the main header to:
[No-OPNSense-issue-/solved]
[No-OPNSense-issue-/solved]
#6
General Discussion / Re: Roku DNS storm is impactin...
Last post by 0x - August 06, 2026, 11:23:50 PMI tried creating unbound overrides for the 2 URLs mine is spamming to unreachable addresses with TTLs of 86399
Didnt work
See some creative stuff in here, but I think im just going to explode this little plastic box with a 106lb kettlebell and call it a day
Didnt work
See some creative stuff in here, but I think im just going to explode this little plastic box with a 106lb kettlebell and call it a day
#7
26.7 Series / Re: VLAN devices are on LAN IP...
Last post by tonys - August 06, 2026, 10:31:38 PMQuote from: dseven on August 06, 2026, 09:50:21 AMAt the start, you had a bridge. Is that bridge now completely gone? Updated ifconfig output might be helpful.
Otherwise I'd tend to suspect that your WiFi is misconfigured...
@viragomann... here is the updated config and yes, the bridge is completely gone and igc3 is disconnected. Sorry about the confusion.
Notes:
- VLAN02 and VLAN03 are unresponsive from anywhere other than OPNSense itself. I can ping 192.168.20.1 and 192.168.40.1 but only when I'm logged directly into the OPNSense shell via SSH. I don't know what layer these pings are operating from.
- The VLAN networks are enabled in UnifiOS and labeled correctly as Guest and IoT with the appropriate tags (20 and 40 respectively). I highly doubt there is a misconfiguration in Unifi OS as it's the same as it always has been and worked just fine under all OPNSense releases up to and including 21.x. The devices listed in Unifi OS are shown on the correct networks (LAN, Guest, and IoT) but they all have LAN IPs. All of my problems started after upgrading to 26.7.x.
- OPNSense's ARP table clearly shows the issue - both VLANs are shown with IP's of 192.168.20.1 and 192.168.40.1 but none of the devices can reach them. Instead, OPNSense incorrectly dumps them into LAN IPs.
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
igc1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
inet xxx.xxx.xxx.xxx netmask 0xfffff800 broadcast 255.255.255.255
inet6 x cac%igc1 prefixlen 64 scopeid 0x2
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
igc2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: DMZ (opt1)
inet 192.168.30.1 netmask 0xffffff00 broadcast 192.168.30.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
igc3: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
media: Ethernet autoselect
status: no carrier
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
inet 127.0.0.1 netmask 0xff000000
groups: lo
enc0: flags=0 metric 0 mtu 1536
options=0
groups: enc
vlan00: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
groups: vlan
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
vlan01: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: Guest (opt2)
inet 192.168.20.1 netmask 0xffffff00 broadcast 192.168.20.255
groups: vlan
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
vlan02: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: IoT (opt3)
inet 192.168.40.1 netmask 0xffffff00 broadcast 192.168.40.255
groups: vlan
vlan: 40 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
#8
26.7 Series / Re: Renewed server certificate...
Last post by Ed V. - August 06, 2026, 10:31:37 PMDo you mean:
It looks like the CA Root is present and OpenSSL knows about it (existing soon-to-expire server cert):
Cross-checking to make sure that the current certs from CACert are loaded:
and
Code Select
# openssl x509 -noout -subject -in /usr/local/share/certs/rootX0F.crt
subject=O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority, emailAddress=support@cacert.organdCode Select
# openssl x509 -noout -subject -in /usr/local/share/certs/CACert_Class3Root_x14E228.crt
subject=O=CAcert Inc., OU=http://www.CAcert.org, CN=CAcert Class 3 Root?It looks like the CA Root is present and OpenSSL knows about it (existing soon-to-expire server cert):
Code Select
# hostname
charon.lan.null-route.us
# openssl s_client -connect charon.lan.null-route.us:443 | grep -i -e verify
Connecting to 2001:579:4c:2700:6662:66ff:fe25:7341
depth=2 O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority, emailAddress=support@cacert.org
verify return:1
depth=1 O=CAcert Inc., OU=http://www.CAcert.org, CN=CAcert Class 3 Root
verify return:1
depth=0 CN=charon.lan.null-route.us
verify return:1
Verify return code: 0 (ok)Cross-checking to make sure that the current certs from CACert are loaded:
Code Select
# certctl -v rehash
[snipped for readability]
found /usr/local/share/certs/CACert_Class3Root_x14E228.crt
590d426f: CAcert Class 3 Root
found /usr/local/share/certs/ca-root-opnsense-1.crt
590d426f: duplicate
found /usr/local/share/certs/rootX0F.crt
99d0fa06: CA Cert Signing Authority
found /usr/local/share/certs/ca-root-opnsense-0.crt
99d0fa06: duplicate
and
Code Select
# certctl -v list
localbase: /usr/local
destdir:
distbase:
unprivileged: false
verbose: true
[snipped]
found /etc/ssl/certs/590d426f.0
590d426f: CAcert Class 3 Root
found /etc/ssl/certs/99d0fa06.0
99d0fa06: CA Cert Signing Authority
[snipped]
590d426f.0 CAcert Class 3 Root
99d0fa06.0 CA Cert Signing Authority #9
General Discussion / Re: Roku DNS storm is impactin...
Last post by OPNenthu - August 06, 2026, 08:55:32 PMAnother observation I had is that the python process is exercised heavily even when I'm using the Host Override for these domains. I know that python is used for DNSBL processing in the OPNsense implementation of Unbound but I'm not sure why that would come into play when a host override is used. Could there be a python hook somewhere that is adding to the overhead?
#10
General Discussion / Re: Roku DNS storm is impactin...
Last post by OPNenthu - August 06, 2026, 08:43:25 PMI think I haven't had enough coffee yet today because I'm confused by the Git ticket that @newsense posted. Don't those cache settings already exist in the Unbound GUI?
I have them set to custom values on this firewall since long go:
You cannot view this attachment.
I agree that the Host Override I used has TTL 0, so that should probably be removed now.
The question then is: do DNSBL hits honor TTL settings? Or do those also have TTL 0? And for that matter, does forcing NXDOMAIN on DNSBL hits instead of 0.0.0.0 have a negative impact here as well because I use that.
I have them set to custom values on this firewall since long go:
You cannot view this attachment.
Code Select
root@firewall:~ # cat /var/unbound/advanced.conf | grep cache
msg-cache-size: 128m
rrset-cache-size: 256m
cache-max-ttl: 86400
cache-min-ttl: 300
I agree that the Host Override I used has TTL 0, so that should probably be removed now.
The question then is: do DNSBL hits honor TTL settings? Or do those also have TTL 0? And for that matter, does forcing NXDOMAIN on DNSBL hits instead of 0.0.0.0 have a negative impact here as well because I use that.
