Messages

Thanks for the confirmation here. I was snooping around hoping to find something like this thread. Not only do the device names look strange, but temps over 100C are generally "unrecoverable critical" (as in, "We should be dead, my friend"), so seeing the box humming along happily with those readings struck me as a red herring.

On the plus side, the updated interface in 25.1 looks great - thank you.

Not much to see. DNS settings are all blank (using unbound at localhost, which works fine when tested at Interfaces->Diagnostics->DNS).

The observed issues went away when I removed the os-sunnyvalley (after the Plugins page finally repopulated).

[Update]

I have this issue currently on 24.1.8-amd64.

After adding the sunnyvalley repo (because I intended to add so-sensei), attempting to check for updates hangs for a long period on this:

Code Select Expand

Updating SunnyValley repository catalogue...
Waiting for another process to update repository SunnyValley

Update check does complete after a long time.

Worse, the Packages and Plugins tabs are blank, so I cannot manage software.

I have:

* rebooted
* verified that DNS works (Interfaces -> Diagnostics)
* verified that all services are running (except iperf, which is normal)
* verified that all attached networks are working correctly
* Tried the suggestion above, with this result:

Code Select Expand

# pkg remove py37-pymongo
No packages matched for pattern 'py37-pymongo'

Checking integrity... done (0 conflicting)
1 packages requested for removal: 0 locked, 1 missing

Out of ideas. I'm down to the last resort option of reinstalling and restoring a config backup.

Update:

Right after I submitted this, the plugins page suddenly populated. The last time I was able to view it (right after adding the sunnyvalley repo), the installed plugins showed "(orphaned)" instead of "(installed)". Now, they say "(installed)".

I would guess there's a problem with the sunnyvalley repo (slow to respond? a dead mirror?) that is causing issues.

Just wanted to note here that adding the firewall's IP addresses to the "Listen Address" directive (and adding appropriate firewall rules) is sufficient to turn a standalone instance into a server. It isn't necessary to mess around with port forwards.

BUT - I don't recommend that. You are limited to accessing only the most basic configuration items, which is not adequate for a server instance. For one fun example, in this port's configuration, I found 'monuser' is "hardcoded" with "upsmon = master" in upsd.users, which gave my nut clients the ability to turn off my firewall. I sorta doubt most people want that.   :)

You can override anything you want manually in the configuration files, of course, but they will get clobbered sooner or later.

The Opnsense NUT port is fine (and appreciated) as a client, but I'd stick to a Raspberry Pi for the NUT server, until/unless the full suite of NUT configuration parameters is made available in the port.

Well, I'll be darned. Thank you!

So, the end result is that I can simplify my configuration, since I won't need unblock-lan-zones. Win-win.

Cheers, and thanks again.

Well. That's puzzling. Or I have no idea what I'm doing.

On a hunch, I UNchecked "Disable DNS rebinding check" in System->Settings->Administration, and sure enough, reverse lookups for overridden zones now work correctly without unblock-lan-zones. That is the opposite of what I'd expect the effect of "Disable DNS rebinding check" to be, based on the help text:

"When this is unchecked, your system is protected against DNS Rebinding attacks. This blocks private IP responses from your configured DNS servers. Check this box to disable this protection if it interferes with web GUI access or name resolution in your environment."

I'm not sure I understand why unchecking that allows PTR queries for private addresses, and selecting it causes them to fail.

Re: IPv6 addresses - PTR lookups for those were not affected in my case, because mine are publicly routed (I have an HE tunnel allocation). The IPv4 addresses are all in 192.168/16.

Thank you very much for the info.

Thank you for your note. Yes, the reverse zones are in the overrides (168.192.in-addr.arpa, as well as a v6 net block). PTR lookups from attached clients definitely don't work unless unblock-lan-zones is specified. I'm not anyone's expert on DNS, so I may misunderstand what is meant by "upstream", but the authoritative server is on a different network from the client, beyond the unbound resolver (via another LAN route, not the WAN).

What stands out to me is stability. Given the consistency of design and behavior, clear documentation of changes, and reliability of the update process over time, it seems clear that your development practices are very disciplined.

I ensure that I have configuration backups and a copy of the previous image before each upgrade, but I've never needed them. The same cannot be said for a lot of commercial software.

Salutations --

Just thought I'd note, as we close in on the drop-dead date for "Custom options" in the unbound GUI, that my use for this feature is to add this section:

server:
   unblock-lan-zones: yes

I forward requests for my own domain to an internal authoritative server using overrides, and the above declaration is needed to make the PTR lookups work for RFC1918 addresses. If you felt like adding a toggle for that in the GUI someday, that'd be appreciated; else I'm fine with adding it manually in /var/unbound/etc in future.

Thanks again for an outstanding piece of software.

Hmm ... I don't think that's it, because the same behavior is seen with IPv6, which is a simple firewall rule where port forwarding is not involved.  As with the v4 rule, if I change 'GEO_US_IPv6' to 'All', then traffic is passed.

I encountered this, and in my case, it's because the IPv6 gateway was not actually working. 

There is a setting under System->Settings->General which says "Prefer IPv4 over IPv6".  If you select that, and updates start working again, my guess would be that IPv6 is not correctly configured or is otherwise broken. 

Just a thought.

Salutations --

I have a feeling I'm missing something super-obvious, but I can't find it. 

I defined a firewall alias named GEO_US_v4, Type GeoIP / IPv4,  where Content selects only my country of residence (US).   I used this alias as a Source in a port forward rule to allow connections to one port.   I created a similar alias for IPv6, and applied it to a rule on the tunnel V6 interface.   Unfortunately, in both cases, it does not match traffic which I know is US-based. 

If I change only the Source in those rules to be 'Any' instead of my alias GEO_US_v[46], then traffic is allowed -- so I know that the traffic is reaching this rule, and I've not blocked it some other way.   The alias must be wrong somehow.

Is there something else I should consider here, or other information I can provide to help illuminate what I'm sure is my mistake?

Thank you...

Gah.  I just realized that this was already reported.  My apologies for the noise.

Salutations --

It looks like a recent update to the 19.1 series introduced an interface bug.  The web form for entering a custom NAT outbound rule won't accept valid input.  Steps to reproduce:

- install 19.1.
- update to 19.1.3.
- Go Firewall->NAT->outbound.
- Select Hybrid, then Add.
- Source address -> single host or network: 192.168.0.0/16
- translation/target -> WAN address (or whatever alias you used for the WAN interface)
- Save.

That should be all you need, and that worked fine in 18.x and also in a stock install of 19.1.  In 19.1.3, though, the response is: "The following input errors were detected: The field Destination bit count is required."

I think that's not right.  The only workaround I found was to save the configuration, re-install 19.1 from scratch, import the configuration, make the required changes to outbound NAT, and THEN update to 19.1.3.  This worked fine.

Since outbound NAT is an exceedingly rare change, barring a major network re-architecture, this workaround is not a big deal.  Just thought I'd let you know.

Thank you!

Fair enough.  Reverting to the default wildcard binding does seem to have satisfied it and resolved the issue.

Thank you very much for the info.