Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - max-e-moose

#1
Just experienced this issue after an upgrade from 24.1.10 to 24.7.6. Was using AdGuardHome (53) -> Unbound(53530) before the upgrade.

The upgrade seemed to go well but AdGuard silently failed to start. No errors in any logs to point the way. This thread helped a lot. Thanks all.

Solution was similar to what others have noted: Fix errors in /usr/local/AdGuardHome/AdGuardHome.yaml

That YAML had been really messed up during the upgrade. There were duplicate/triplicates of some values spread around the file.

To regain DNS I disabled AdGuard then moved Unbound back to port 53.

I copied the YAML from the router to my PC, then deleted AdGuard from the router. Then re-installed a fresh instance of AdGuard and placed the original values back into the YAML file. There was still an issue with one of the DNS blocklist values so I excluded them from the YAML then AdGuard started up without issue. Manually re-added them via the AdGuard GUI.

Then changed the ports back so that AdGuard was the primary DNS server and Unbound was secondary. Crisis averted.

#2
Hi all,

Been lurking around here and using OPNsense for around 6 months. Very happy with it. Much appreciation to the devs and community.

Recently, I noticed my ISP connection was down so logged in to OPNsense to confirm what was going on. Sure enough there was no IP on the WAN. The connection had been down for around a half hour so I decided to reboot OPNsense. Maybe the connection would return, I derped to myself. It was nearing midnight.

After the reboot there was still no WAN connection but there were loads of services showing as stopped on the Lobby Dashboard. Acme, ddclient, dhcpd, unbound and a few others all showed as stopped. Odd. Some of those should be running, even without WAN. Give it a few minutes, they'll start up. 10 minutes later, refresh the page, no change. Hmmmm... OPNsense is usually very quick to become ready.

This is when the click happened. There were no issues with LAN connectivity at the time but those red stopped service icons got the better of me. I clicked start on dhcpd then immediately lost access to the Web GUI. All devices on the network stopped being able to communicate. Uh-oh. I f****d it.

It took a little while to figure out but I was able to get up and running again. Fixing it involved jumping into Single User mode, mounting the filesystem as read/write, and editing conf/config.xml using vi. The problem was caused by a line in the dhcpd section which had changed after I clicked start on dhcpd.


<dhcpd>
  <lan>
    <enable>1</enable>
    ....


When I compared that to the sample on GitHub, I noticed a slight difference on the "enable" line.


<dhcpd>
  <lan>
    <enable/>
    ....


I changed the enable line in my config to match the sample, saved and rebooted. Everything came back, including my WAN connection as the ISP was up again! ****. Hello 1:30am.

With that crisis averted, I wanted to flag this experience to the community as it seemed like this is not the expected behaviour from OPNsense in that scenario. Surely clicking on start dhcpd shouldn't have resulted in my system becoming inaccessible?