Recent posts

#1
26.7 Series / Re: Performance Issues on 26.7...
Last post by notspam - Today at 11:26:23 PM
Please edit the main header to:
[No-OPNSense-issue-/solved]
#2
General Discussion / Re: Roku DNS storm is impactin...
Last post by 0x - Today at 11:23:50 PM
I 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
#3
26.7 Series / Re: VLAN devices are on LAN IP...
Last post by tonys - Today at 10:31:38 PM
Quote from: dseven on Today at 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
#4
26.7 Series / Re: Renewed server certificate...
Last post by Ed V. - Today at 10:31:37 PM
Do you mean:

# 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.org
and
# 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):

# 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:
# 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

# 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
#5
General Discussion / Re: Roku DNS storm is impactin...
Last post by OPNenthu - Today at 08:55:32 PM
Another 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?
#6
General Discussion / Re: Roku DNS storm is impactin...
Last post by OPNenthu - Today at 08:43:25 PM
I 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.

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.
#7
26.7 Series / Re: Internal DNS only works fo...
Last post by rheilke - Today at 08:27:24 PM
OK, thank you. So, it will only work after the client asking has rebooted? That's going to be a pain. :( This also explains my nslookup results.

I always thought this was a server-side setting...

Thank you again, I've learned something new.
R
#8
General Discussion / Re: Roku DNS storm is impactin...
Last post by nero355 - Today at 08:26:01 PM
Quote from: lmoore on Today at 08:18:18 PMThe man page for unbound.conf(5) lists this option, is it what you are thinking of?

cache-min-ttl: <seconds>
            Time to live minimum for RRsets and messages in the cache.  If the
            minimum kicks in, the data is cached for longer than the domain
            owner intended, and thus less queries are made to look up the
            data.  Zero makes sure the data in the cache is as the domain
            owner intended, higher values, especially more than an hour or so,
            can lead to trouble as the data in the cache does not match up
            with the actual data any more.

            Default: 0 (disabled)

The setting in Services -> Unbound DNS -> Advanced is;

https://forum.opnsense.org/index.php?action=dlattach;attach=57351;image
I am aware of that option, but it was something that would basically run as an extension of Unbound.

However maybe that option made that piece of software obsolete now...
Haven't read anything about it for a long time :)
#9
General Discussion / Re: Roku DNS storm is impactin...
Last post by lmoore - Today at 08:18:18 PM
Quote from: nero355 on Today at 07:45:05 PMThere was also some additional piece of software for Unbound that can cache frequently requested stuff for you for longer periods based on your personal preferences, but I can't remember the exact name...

The man page for unbound.conf(5) lists this option, is it what you are thinking of?

cache-min-ttl: <seconds>
            Time to live minimum for RRsets and messages in the cache.  If the
            minimum kicks in, the data is cached for longer than the domain
            owner intended, and thus less queries are made to look up the
            data.  Zero makes sure the data in the cache is as the domain
            owner intended, higher values, especially more than an hour or so,
            can lead to trouble as the data in the cache does not match up
            with the actual data any more.

            Default: 0 (disabled)

The setting in Services -> Unbound DNS -> Advanced is;


#10
26.7 Series / Re: Internal DNS only works fo...
Last post by Monviech (Cedrik) - Today at 08:15:40 PM
Its a client setting, the client decides how to ask the DNS server for a name.

Clients either get it via DHCP option or you set it manually in them.

In dnsmasq its the "domain" setting in each range.

Here some context what a search domain is:
https://en.wikipedia.org/wiki/Search_domain

Here where we explained it for dnsmasq:
https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration

If it doesnt work, its entirely up to the client, the DNS server cannot do anything about it.