Messages

If that was the source of the block, would that not ALSO apply after a reboot?  Rebooting corrects the issue.  And FYI that is a default and recommended block on most internet facing WAN interfaces.

True, however generally for a WAN interface, where that option is used, the expectation is that NO communication w/ an RFC1918 / non-routable IP address would be necessary / desired.

Just a guess, but I could envision a reboot working due to something like the order of operations differing at boot time. For example, perhaps at boot time, the DHCP lease request is sent before that WAN rule is loaded. It would probably take a code review to determine the order of operations, and how it might differ during the boot cycle vs. when an interface is downed/upped to know for sure.


As a test / possible fix, I suggest you disable the block RFC IPs on WAN option, and instead add a custom WAN rule that blocks all RFC1918 IP sourced traffic to your WAN interface, but explicitly allow traffic to/from your ISP's DHCP server RFC1918 IP you mentioned, source or dest ports of UDP 67 and 68 (for IPv4).

If that does not fix the issue, then something else is at play (in which case I would look at the advanced DHCP request settings, as some ISPs can be very finnicky on the request parameters. Start by searching your preffered search engine for other customers of the same ISP w/ non-standard edge routers / firewalls).

Ultimately though, since you know that you need to be able to receive traffic from an RFC1918 IP in order to receive your DHCP lease from your ISP, it seems logical that you would not be able to leverage the option for blocking all RFC1918 IP space into your WAN interface, and leaving it enabled should be expected to lead to inconsistent results / problems. GL!

[THE FIX:]

I experienced the same issue w/ Unbound, but on dedicated instances not running on my OPNsense firewall -- same root cause and solution.


I originally found the fix detailed in this post on the official Unbound project mailing list archive:

https://lists.nlnetlabs.nl/pipermail/unbound-users/2011-January/001608.html


THE FIX:

Reduce the infra-host-ttl value (in seconds) in Unbound's config file (unbound.conf) to a lower value that meets your needs. The default value (15 min / 900 sec) was way too high for my needs.

For example, to have Unbound recheck for restored connectivity every minute during an upstream network outage:

Code Select Expand

infra-host-ttl: 60


(I think the manpage could be clearer on this):

Code Select Expand


       infra-host-ttl: <seconds>
              Time  to live for entries in the host cache. The host cache contains roundtrip timing, lameness and EDNS support infor‐
              mation. Default is 900.


You indicated that you have enabled blocking private/bogon networks on your WAN interface. From the log output, it looks like your WAN interface is the gb0 interface, and it looks like the source IP of the DHCP server response is 10.82.240.1. That is an RFC1918 IP -- "private networks" -- which you've configured to be blocked.

Have you tried disabling the block of private / bogon networks to see if that resolves your issue? Looks to me like the DHCPOFFER response is being blocked by your OPNsense configuration because the source IP is an RFC1918 IP address.