Messages

Had the same issue...

I saw running NTP processes listening on the selected interfaces but looks like on initial boot maybe the service checker didn't align?

I was able to force kill the PIDS from the command line and restart NTP from the web UI and its reflected properly now.

Bump, I have the same issue but using DNS01 as the validation.

I was able to go back into each certificate and click on renew/issue to fix the issue.

I've noticed since I've added a blocklist into Unbound to protect the EDGE of DNS queries that it is not loading the blocklist via URL on boot-up or so the new dashboard reflects the "Size of blocklist" is ZERO.

I currently have it configured for https://dbl.oisd.nl/ and I know this list works since when after a reboot I can go in and restart Unbound and the "Size of blocklist" shows properly now.

Not sure if this is a dashboard "quirk" or Unbound is not truly loading the list on boot.

EDIT: Looks like in the logs for today when I rebooted to install 23.1.1 I see this:

Code Select Expand


<163>1 2023-02-15T15:10:53-05:00 firewall.lan unbound 71004 - [meta sequenceId="224"] blocklist download : unable to download file from https://dbl.oisd.nl/ (error : HTTPSConnectionPool(host='dbl.oisd.nl', port=443): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x8027ccf40>: Failed to establish a new connection: [Errno 8] Name does not resolve')))


How do I prevent this?

The right fix is likely that the owner:group of /var/db/nut remains nut:nut so that everything works. Unsure why this becomes uucp:uucp at some point.

Changing the permissions to 777 on /var/db/nut makes things work (DP is the UPS name)

Code Select Expand

root@*******:/var/log # ls -al /var/db/nut/
total 20
drwxrwxrwx   2 uucp  uucp    512 Jan 26 18:41 .
drwxr-xr-x  21 root  wheel  1536 Jan 26 18:37 ..
-rw-r--r--   1 nut   uucp      6 Jan 26 18:41 upsd.pid
-rw-r--r--   1 root  uucp      6 Jan 26 18:38 upsmon.pid
srw-rw----   1 nut   uucp      0 Jan 26 18:41 usbhid-ups-DP
-rw-r--r--   1 nut   uucp      6 Jan 26 18:41 usbhid-ups-DP.pid


This is definitely not a good fix in any way, it is very bad and insecure but it gets me going for now until the right solution is found or this is fixed.

Changing to 777 allowed for it to start. Least that is a work around for now.

Same boat here, worked fine in 22.x series.

Code Select Expand


root@firewall:/var/db # /usr/local/etc/rc.d/nut restart
nut not running? (check /var/db/nut/upsd.pid).
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic HID driver 0.47 (2.8.0)
USB communication driver (libusb 1.0) 0.43
Can't chdir to /var/db/nut: Permission denied
Driver failed to start (exit status=1)
/usr/local/etc/rc.d/nut: WARNING: failed precmd routine for nut
root@firewall:/var/db #


Code Select Expand


root@firewall:/var/db # ls -la nut/
total 12
drwxr-x---   2 uucp  uucp    512 Jan 26 17:53 .
drwxr-xr-x  24 root  wheel  1024 Jan 26 17:52 ..
-rw-r--r--   1 root  uucp      6 Jan 26 17:53 upsmon.pid
root@firewall:/var/db #


Also did a remove/install with no luck

I am using another plugin: Apcupsd
maybe try that one since you are using a APC UPS also.

I use NUT since I've use NUT on other systems in my home and have ways to monitor and pull data from them. Switching over to APCUPSd isn't an option for me sorry.

NUT does support this UPS fully without issues but not sure on the OPNsense why it wouldn't be working on localhost but it does on the LAN interface.

Any thoughts or things to try?

So I have latest version of everything and nut configured with standalone is spewing the UPS is unavailable but it is seen via USB.

I can QUERY the UPS via upsc using the LAN IP (192.168.xx.1) but not via 127.0.0.1 which is what UPSMON is trying to talk to when it is spewing out these errors.

Attached are my general settings.

So I was doing some playing today and noticed on my bare metal firewall I am getting 3-4Gbit/s AFTER a reboot using any interface. My server hardwar information can be found at https://bsd-hardware.info/?probe=30789867a9. These interfaces are X722 10Gbe running to an Arista DCS-7050T-64-R and the interfaces are configured as follows:

Code Select Expand


interface Ethernet47
   description Firewall - ixl0 - vl20,vl30,vl40,vl50
   mtu 9198
   switchport access vlan 20
interface Ethernet48
   description Firewall - ixl1 - vl20,vl30,vl40,vl50
   mtu 9198
   switchport trunk allowed vlan 20,30,40,50,60
   switchport mode trunk


Simple network configuration because I've been pulling my hair out trying to elimnate various variables (e.g., LAGG, VLAN, and even Straight Interfaces).

Now here is the weird part... On reboot I get the 3-4Gbit/s speeds BUT the moment I make some type of interface change the performance goes to the expected ~9Gbit/s.

These are the iperf speeds talking to devices on the same subnet so there is no intervlan traffic here so it should be nearly line speed of course but see how bad they are:

iperf3 -P8 going out ixl0, no VLANs:

Code Select Expand


[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   509 MBytes   427 Mbits/sec   11             sender
[  5]   0.00-10.00  sec   509 MBytes   427 Mbits/sec                  receiver
[  7]   0.00-10.00  sec   510 MBytes   428 Mbits/sec   14             sender
[  7]   0.00-10.00  sec   510 MBytes   428 Mbits/sec                  receiver
[  9]   0.00-10.00  sec   511 MBytes   428 Mbits/sec   23             sender
[  9]   0.00-10.00  sec   511 MBytes   428 Mbits/sec                  receiver
[ 11]   0.00-10.00  sec   509 MBytes   427 Mbits/sec   17             sender
[ 11]   0.00-10.00  sec   509 MBytes   427 Mbits/sec                  receiver
[ 13]   0.00-10.00  sec   510 MBytes   428 Mbits/sec   16             sender
[ 13]   0.00-10.00  sec   510 MBytes   428 Mbits/sec                  receiver
[ 15]   0.00-10.00  sec   510 MBytes   428 Mbits/sec   14             sender
[ 15]   0.00-10.00  sec   510 MBytes   428 Mbits/sec                  receiver
[ 17]   0.00-10.00  sec   509 MBytes   427 Mbits/sec    9             sender
[ 17]   0.00-10.00  sec   509 MBytes   427 Mbits/sec                  receiver
[ 19]   0.00-10.00  sec   510 MBytes   428 Mbits/sec   13             sender
[ 19]   0.00-10.00  sec   510 MBytes   428 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec  3.98 GBytes  3.42 Gbits/sec  117             sender
[SUM]   0.00-10.00  sec  3.98 GBytes  3.42 Gbits/sec                  receiver


iperf3 -P8 going out ixl1_vlan30:

Code Select Expand


[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.01  sec   487 MBytes   408 Mbits/sec    4             sender
[  5]   0.00-10.01  sec   487 MBytes   408 Mbits/sec                  receiver
[  7]   0.00-10.01  sec   487 MBytes   408 Mbits/sec    9             sender
[  7]   0.00-10.01  sec   487 MBytes   408 Mbits/sec                  receiver
[  9]   0.00-10.01  sec   487 MBytes   408 Mbits/sec    5             sender
[  9]   0.00-10.01  sec   487 MBytes   408 Mbits/sec                  receiver
[ 11]   0.00-10.01  sec   483 MBytes   404 Mbits/sec    8             sender
[ 11]   0.00-10.01  sec   483 MBytes   404 Mbits/sec                  receiver
[ 13]   0.00-10.01  sec   487 MBytes   408 Mbits/sec    0             sender
[ 13]   0.00-10.01  sec   487 MBytes   408 Mbits/sec                  receiver
[ 15]   0.00-10.01  sec   487 MBytes   408 Mbits/sec    0             sender
[ 15]   0.00-10.01  sec   487 MBytes   408 Mbits/sec                  receiver
[ 17]   0.00-10.01  sec   487 MBytes   408 Mbits/sec    0             sender
[ 17]   0.00-10.01  sec   487 MBytes   408 Mbits/sec                  receiver
[ 19]   0.00-10.01  sec   482 MBytes   404 Mbits/sec    0             sender
[ 19]   0.00-10.01  sec   482 MBytes   404 Mbits/sec                  receiver
[SUM]   0.00-10.01  sec  3.80 GBytes  3.26 Gbits/sec   26             sender
[SUM]   0.00-10.01  sec  3.80 GBytes  3.26 Gbits/sec                  receiver


Code Select Expand


root@firewall:~ # ifconfig ixl0
ixl0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN
options=4e507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
ether ac:1f:6b:c6:3c:0a
inet 192.168.50.1 netmask 0xfffffe00 broadcast 192.168.51.255
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
root@firewall:~ # ifconfig ixl1_vlan30
ixl1_vlan30: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: IoT
options=4600703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
ether ac:1f:6b:c6:3c:0b
inet 192.168.54.1 netmask 0xfffffe00 broadcast 192.168.55.255
groups: vlan
vlan: 30 vlanproto: 802.1q vlanpcp: 0 parent interface: ixl1
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
root@firewall:~ #



Now I moved the LAN interface (VLAN20) from the dedicated ixl0 to ixl1_vlan20 and the performance jumps back to normal as shown below:

Code Select Expand


[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.39 GBytes  1.20 Gbits/sec   31             sender
[  5]   0.00-10.00  sec  1.39 GBytes  1.20 Gbits/sec                  receiver
[  7]   0.00-10.00  sec  1.29 GBytes  1.11 Gbits/sec   26             sender
[  7]   0.00-10.00  sec  1.29 GBytes  1.11 Gbits/sec                  receiver
[  9]   0.00-10.00  sec  1.30 GBytes  1.11 Gbits/sec   34             sender
[  9]   0.00-10.00  sec  1.29 GBytes  1.11 Gbits/sec                  receiver
[ 11]   0.00-10.00  sec  1.33 GBytes  1.14 Gbits/sec   36             sender
[ 11]   0.00-10.00  sec  1.33 GBytes  1.14 Gbits/sec                  receiver
[ 13]   0.00-10.00  sec  1.23 GBytes  1.06 Gbits/sec   26             sender
[ 13]   0.00-10.00  sec  1.23 GBytes  1.05 Gbits/sec                  receiver
[ 15]   0.00-10.00  sec  1.55 GBytes  1.33 Gbits/sec   20             sender
[ 15]   0.00-10.00  sec  1.55 GBytes  1.33 Gbits/sec                  receiver
[ 17]   0.00-10.00  sec  1.47 GBytes  1.27 Gbits/sec   56             sender
[ 17]   0.00-10.00  sec  1.47 GBytes  1.26 Gbits/sec                  receiver
[ 19]   0.00-10.00  sec  1.37 GBytes  1.18 Gbits/sec   29             sender
[ 19]   0.00-10.00  sec  1.37 GBytes  1.18 Gbits/sec                  receiver
[SUM]   0.00-10.00  sec  10.9 GBytes  9.40 Gbits/sec  258             sender
[SUM]   0.00-10.00  sec  10.9 GBytes  9.38 Gbits/sec                  receiver


Code Select Expand


[root@firewall ~]# ifconfig ixl0
ixl0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: LAN
        options=48500b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,VLAN_HWTSO,NOMAP>
        ether ac:1f:6b:c6:3c:0a
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
[root@firewall ~]# ifconfig ixl1_vlan20
ixl1_vlan20: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: LAN
        options=4600703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
        ether ac:1f:6b:c6:3c:0b
        inet 192.168.50.1 netmask 0xfffffe00 broadcast 192.168.51.255
        groups: vlan
        vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: ixl1
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
[root@firewall ~]#


But if I run the iperf on the vlan30 interface, that wasn't touched, but attached via VLANs to the SAME interface now as vlan20 you can see the speeds are in "werid" state. The ifconfig of that interface is already posted above.

Code Select Expand


[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.01  sec   486 MBytes   408 Mbits/sec    5             sender
[  5]   0.00-10.01  sec   486 MBytes   408 Mbits/sec                  receiver
[  7]   0.00-10.01  sec   486 MBytes   407 Mbits/sec    3             sender
[  7]   0.00-10.01  sec   486 MBytes   407 Mbits/sec                  receiver
[  9]   0.00-10.01  sec   486 MBytes   408 Mbits/sec    6             sender
[  9]   0.00-10.01  sec   486 MBytes   408 Mbits/sec                  receiver
[ 11]   0.00-10.01  sec   486 MBytes   408 Mbits/sec   13             sender
[ 11]   0.00-10.01  sec   486 MBytes   408 Mbits/sec                  receiver
[ 13]   0.00-10.01  sec   486 MBytes   407 Mbits/sec    0             sender
[ 13]   0.00-10.01  sec   486 MBytes   407 Mbits/sec                  receiver
[ 15]   0.00-10.01  sec   486 MBytes   407 Mbits/sec    0             sender
[ 15]   0.00-10.01  sec   486 MBytes   407 Mbits/sec                  receiver
[ 17]   0.00-10.01  sec   486 MBytes   408 Mbits/sec    0             sender
[ 17]   0.00-10.01  sec   486 MBytes   408 Mbits/sec                  receiver
[ 19]   0.00-10.01  sec   486 MBytes   408 Mbits/sec    0             sender
[ 19]   0.00-10.01  sec   486 MBytes   408 Mbits/sec                  receiver
[SUM]   0.00-10.01  sec  3.80 GBytes  3.26 Gbits/sec   27             sender
[SUM]   0.00-10.01  sec  3.80 GBytes  3.26 Gbits/sec                  receiver


If I do something with this interface such as reassign it to another interface or even reassign the vlan to another interface the speeds will return to the expected state.

Now if I reboot ALL interfaces will be in this slower state until moved around but they will retain this fixed state on the touched interfaces until the next reboot.

Hardware CRC, Hardware TSO, and Hardware LRO are all disabled and VLAN Hardware Filtering is set to Leave default. All my system tuneables are set to default right now.

I am so confused and not sure what is going on but I need help and not sure what else to do. Willing to provide any additional debug information needed to help troubleshoot and test.

Thanks!

If your footprint allows it you could always strap a small 40/60MM FAN to the card to help dissipate heat. I know this isn't ideal but I've done that in the past with other devices than ran warm.

Quick other question for you since you have it running in OPNSense.

Do you know if the 1/2.5/5/10G option works in the latest version? I am interested in these cards in a future upcoming SuperMicro based off the Ice Lake-D line (https://www.servethehome.com/welcome-to-the-intel-ice-lake-d-era-with-the-xeon-d-2700-and-d-1700-series/3/, see SYS-110D-16C-FRN8TP) and it comes with two of them on the board. I was hoping to leverage those for my Fiber internet as it seems AT&T is deploying 2 and 5 service now but need a 2.5/5G port to work. 

If this is going to be a forced retirement/switch to os-ddclient please for the love of all things tech include AWS R53 support. I've scoured the ddclient github and can't find any pull requests and/or issues to support AWS R53. While I understand the need to move forward you can't move forward and remove a lot of features.

So I had MONIT configured to monitor NTP via the pid file that in 21.X was under /var/run/ntpd.pid and with the upgrade to 22.1 it is gone.

Code Select Expand


root@firewall:/var/run # ps auxww | grep ntp
nobody   41571   0.0  0.1  750856  23484  -  S    14:29     0:00.57 /usr/local/bin/node_exporter --web.listen-address=192.168.14.1:9100 --collector.textfile.directory=/var/tmp/node_exporter --collector.ntp --collector.devstat
root     87267   0.0  0.0   21768   6936  -  Ss   15:17     0:00.02 /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf
root     74685   0.0  0.0   12740   2348  0  S+   15:19     0:00.00 grep ntp
root@firewall:/var/run # ls -la /var/run/ntp*
ls: No match.
root@firewall:/var/run #


So where is the ntpd file now?

I had this problem until I read about turning OFF "Disable hardware TCP segmentation offload" and "Disable hardware large receive offload" under Interface->Settings. This allowed me to get ~9GBit/s

Code Select Expand


[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  1.34 GBytes  1.15 Gbits/sec                  receiver
[  8]   0.00-10.00  sec  1.34 GBytes  1.15 Gbits/sec                  receiver
[ 10]   0.00-10.00  sec  1.34 GBytes  1.15 Gbits/sec                  receiver
[ 12]   0.00-10.00  sec  1.34 GBytes  1.15 Gbits/sec                  receiver
[ 14]   0.00-10.00  sec  1.34 GBytes  1.15 Gbits/sec                  receiver
[ 16]   0.00-10.00  sec  1.34 GBytes  1.15 Gbits/sec                  receiver
[ 18]   0.00-10.00  sec  1.44 GBytes  1.24 Gbits/sec                  receiver
[ 20]   0.00-10.00  sec  1.36 GBytes  1.17 Gbits/sec                  receiver
[SUM]   0.00-10.00  sec  10.9 GBytes  9.32 Gbits/sec                  receiver


Prior to making this change I had ~1-3Gbit/s

I read online that if you have Intel NICs that supports LRO/TSO VMWare enables that and when you disable it with FreeBSD it conflicts and slows down.

I've configured HA failover following https://www.thomas-krenn.com/en/wiki/OPNsense_HA_Cluster_configuration as a guide.

I've got four internal interfaces:

• LAN - 192.168.14.0/23
• IoT - 192.168.24.0/23
• DMZ - 192.168.220.0/24
• GUEST - 192.168.215.0/24

The firewalls are configured as so:

• Firewall A - ALL VLANS configured as .2
• Firewall B - ALL VLANS configured as .3

The .1 for each of those VLANs mentioned above is configured as a CARP  and that is working fine.

On the DHCP side I have the .3 configured as the failover peer IP for Firewall A and for Firewall B the .2 failover peer IP is configured. All of them have 255 as the failover split right now.

When this is all setup and the sync is done I noticed some of the DHCP sync peers don't fully work. When I check sockstat for dhcp ports listening/established it seems 2 of the 4 are in a SYN_SENT state and the other 2 are established and working.

It seems the DMZ and LAN subnets are the ones in the SYN_SENT state and not working as seen here:

Code Select Expand


root@firewall:~ # sockstat -ss | grep dhcp
dhcpd    dhcpd      63054 4  dgram  -> /var/dhcpd/var/run/log
dhcpd    dhcpd      63054 5  stream /tmp/php-fastcgi.socket-1
dhcpd    dhcpd      63054 7  tcp4   192.168.215.2:519     192.168.215.3:8510                 ESTABLISHED
dhcpd    dhcpd      63054 14 udp4   *:67                  *:*
dhcpd    dhcpd      63054 15 tcp4   192.168.24.2:519      192.168.24.3:8511                  ESTABLISHED
dhcpd    dhcpd      63054 16 tcp4   192.168.215.2:519     *:*                                LISTEN
dhcpd    dhcpd      63054 18 tcp4   192.168.24.2:519      *:*                                LISTEN
dhcpd    dhcpd      63054 19 tcp4   192.168.220.2:52769   192.168.220.3:519                  SYN_SENT
dhcpd    dhcpd      63054 20 tcp4   192.168.220.2:520     *:*                                LISTEN
dhcpd    dhcpd      63054 21 tcp4   192.168.14.2:52770    192.168.14.3:519                   SYN_SENT
dhcpd    dhcpd      63054 22 tcp4   192.168.14.2:520      *:*                                LISTEN
root     syslog-ng  10178 20 dgram  /var/dhcpd/var/run/log
_dhcp    dhclient   65442 5  stream -> ??
_dhcp    dhclient   29199 5  stream -> ??
root@firewall:~ #


I do know on the LAN and DMZ subnets I have "Deny unknown clients" enable but not sure if that is causing any issues but it is a weird situation and welcome any guidance and/or help.

Hello!

I've recently switched over to this configuration as referenced here:

https://pi-hole.net/2021/09/30/pi-hole-and-opnsense/#page-content

I have four internal subnet/interfaces as LAN,IoT,DMZ, and GUEST which the firewall has an interface in each one ending in .1 and is completely accessible via those interfaces on those VLANs. I also have DNSMASQ setup in OPNSense setup to bind to those interfaces and here are my current DNSMASQ settings attached. I am also using the eDNS configuration to pass along the client IP for pihole based rules.

In the firewall under Settings->General I have the two piholes listed in the DNS servers as .8/.9 according to the guide posted above. I do have gateway switching enabled as I have a Fiber and a CELL backup but the DNS servers are NOT listed tied to any gateway right now.

For DHCP for the four VLANs I have NO DNS server set since OPNSense inserts the interface IP already as part of the settings.

Now here is the weird part I've been using this configuration since 21.7.2 and on so can't comment on older versions.

If I reboot the firewall for any reason (e.g. Upgrade, simple reboot, etc.) the clients querying the firewall's interface work once the interfaces all come up and work up until about the point of WAN newIP stuff and then I see ALL traffic to the pihole's come to a crawl/stop. The pihole's themselves are able to be queried directly without issues and can query the upstream internet servers (using google and cloudflare DNS over TLS but when the clients via the firewall are told to talk to the pihole's I get weird errors in the firewall's dnsmasq log file. Queries against the firewall for DHCP and static hosts configured in DNSMASQ work perfectly fine but anything DNSMASQ on the firewall has to send upstream to the pihole's throws the following error:

Nov 11 18:22:53 firewall dnsmasq[49246]: 5764 x.x.x.220/50108 query[A] gstatic.com from 192.168.14.220
Nov 11 18:22:53 firewall dnsmasq[49246]: 5764 x.x.x.220/50108 config error is REFUSED (EDE: not ready)
Nov 11 18:22:53 firewall dnsmasq[49246]: 5765 x.x.x.46/51708 query[PTR] 1.x.x.x.in-addr.arpa from x.x.x.46
Nov 11 18:22:53 firewall dnsmasq[49246]: 5765 x.x.x.46/51708 /etc/hosts x.x.x.1 is firewall.lan
Nov 11 18:22:53 firewall dnsmasq[49246]: 5766 x.x.x.46/59035 query[A] firewall.lan from x.x.x.46
Nov 11 18:22:53 firewall dnsmasq[49246]: 5766 x.x.x.46/59035 /etc/hosts firewall.lan is x.x.x.1

Above you can see .220 trying to query gstatic.com from the firewall and gets the EDE: not ready error but .46 queries a static IP from DNSMASQ and it returns the response no issues.

I did some testing and CANNOT fix this issue by stopping/starting DNSMASQ on the firewall and the ONLY way I can fix this issue is going to Settings->General and literally hit SAVE without changing anything and data flows upstream to the piholes without issue.

I did some research on the EDE not ready error and came across this link:

https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg15508.html

Any thoughts on this issue? Is it a bug, a mis-configuration. or something else?

Thanks!