Messages

[Then it would be a local route and not pass to the WAN.]

Ah ofcourse, DHCP is a layer 2 responsibility.

Yes, there could be unintended routing issues if you have full 192.168.0.0/16 address range within your LAN.  Then it would be a local route and not pass to the WAN.

Great, as long as there can't be an unintentional leak that's perfectly fine.

Thanks for elaborating, I understand what's going on now.
Have a great day!  :)

192.168.100.1 is a common cable modem management address.  If the DOCSIS side of the cable modem goes out, the modem will assign your WAN an address in the 192.168.100.x range, typically with a 30 second lease.  This is done so you will still have IP connectivity to the modem management interface.

So, just be sure you really want to block this expected behavior.

Ah that explains a lot. My knowledge on DOCSIS is limited but the behavior you mentioned should indeed stay as it is now, thanks for clearing that up.

However, I'm still trying to understand how the DHCP lease could have been provided from a bogon ipv4 range while the firewall rules block those ranges before it arrives at the 'allow DHCP client on WAN' rule.

Furthermore I'm interested if this can cause unintended routing or collisions if both the WAN and a LAN interface are assigned to a 192.168.0.0/16 range.

Yes, the firewall rules that are visible in the screenshots are from the 'Automatically generated' section.
Enabling that option automatically generates the corresponding firewall rule.

A few hours ago my WAN access dropped.
When I investigated I stumbled upon my WAN interface having an assigned DHCP IP address: 192.168.100.13/24

I am not entirely sure but I expect that the DHCP server (or a relay) would need to be in the 192.168.0.0/16 range.
In which case, I would have expected the auto generated firewall rules to block the negotiation because the bogon is blocked before the DHCP negotiation is allowed. (unless the IPv4 DHCP server negotiated with the dhcpv6 port? ???)

It is not an issue anymore as my ISP has fixed the issue on their end. But I'm left with some questions.
If someone could help me clarify the questions I have, that would be much appreciated.

• How could this have happened? Looking at the firewall rules I would have expected the DHCP negotiation to be blocked.
• Could this be a security issue if one of my LAN networks is in the 192.168.0.0/16 range as well?
• Why is the IPv4 protocol in the dhcpv6 rules and vice versa for the DHCP rules? (see firewall screenshot)

Apparently I had one of the options for hardware offloading still enabled.
This didn't cause issues before 20.7 but disabling all hardware offloading fixed the issues.

[Versions]

I'm using unbound as an intermediate cache which is advertised through DHCP. But I'm getting DNS timeouts while using Unbound:

Code Select Expand


>nslookup google.com

Server:  opnsense.xxxxxxxx.xxx
Address:  xxx.xxx.xxx.xxx (opnsense box address)

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
Non-authoritative answer:
Name:    google.com
Addresses:  2a00:1450:400e:808::200e
          172.217.20.78


When I query 1.1.1.1 directly I'm receiving a quick response:

Code Select Expand


>nslookup google.com 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    google.com
Addresses:  2a00:1450:400e:808::200e
          172.217.20.78


I already have 'Forwarding Mode' enabled, changing this does not yield different results.
I have tried disabling Suricata but this does not have any impact.
Successive requests still result in DNS timeouts, the result should be cached on first query if I'm not mistaken.

Any suggestions on why this is happening and how to fix it?

Versions
OPNsense 20.7.1-amd64
FreeBSD 12.1-RELEASE-p8-HBSD
LibreSSL 3.0.2

Performance
Processor: Intel(R) Celeron(R) J4005 CPU @ 2.00GHz (2 cores)
Memory: 22 % ( 1752/7961 MB )
Load averages: 0.38, 0.23, 0.18