Messages

1

24.1 Legacy Series / Re: Errors on upgrade

« on: June 14, 2024, 04:40:32 am »

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).

2

24.1 Legacy Series / Re: Errors on upgrade

« on: June 13, 2024, 08:42:20 pm »

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]

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]

# 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.

3

General Discussion / Re: NUT Remote Monitoring/Clients

« on: December 31, 2023, 07:03:53 pm »

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.

4

21.1 Legacy Series / Re: unbound: unblock-lan-zones

« on: February 03, 2021, 07:23:13 pm »

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.

5

21.1 Legacy Series / Re: unbound: unblock-lan-zones

« on: February 03, 2021, 08:26:46 am »

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.

6

21.1 Legacy Series / Re: unbound: unblock-lan-zones

« on: February 03, 2021, 12:44:59 am »

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).

7

21.1 Legacy Series / Re: THANK YOU

« on: January 31, 2021, 06:49:57 pm »

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.

8

21.1 Legacy Series / unbound: unblock-lan-zones

« on: January 31, 2021, 08:55:43 am »

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.

9

19.1 Legacy Series / Re: firewall allow via GEO isn't working

« on: March 30, 2019, 08:39:16 pm »

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.

10

19.1 Legacy Series / Re: Is This a Possible Bug (Updates fail if have wan ipv6 gateway enabled)

« on: March 30, 2019, 02:10:30 am »

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.

11

19.1 Legacy Series / firewall allow via GEO isn't working

« on: March 30, 2019, 02:05:24 am »

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...

12

19.1 Legacy Series / Re: 19.1.3: interface bug: NAT->outbound

« on: March 12, 2019, 04:07:13 am »

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

13

19.1 Legacy Series / 19.1.3: interface bug: NAT->outbound

« on: March 11, 2019, 08:47:15 pm »

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!

14

19.1 Legacy Series / Re: web service fails to start

« on: March 11, 2019, 05:21:51 pm »

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. 

15

19.1 Legacy Series / web service fails to start

« on: March 11, 2019, 04:57:20 am »

Hello all --

It looks like there's a startup order problem in some cases.  I'm finding that lighttpd fails to start at boot, but will happily come up if I issue "reload all services" at the console, and is stable after that.  /var/log/system.log has this to say at boot time:

Mar 10 20:29:15 fw01 opnsense: /usr/local/etc/rc.bootup: The command '/usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf' returned exit code '255', the output was '2019-03-10 20:29:15: (network.c.309) can't bind to socket: [<inet6addr>]:443 Can't assign requested address'

... where <inet6addr> is the LAN internal IPv6 address. 

This is the latest published stable build as of today (19.1.3).  The web service is configured to listen only on LAN.  There are three other ifaces present: WAN, WAN_V6 (HE tunnel), and DMZ.   The NICs in use are a 2-port Intel i350 (for LAN and DMZ) and an Asus onboard gigabit NIC (for WAN). 

Seems that lighttpd is trying to start before all interfaces are fully configured.  Connecting via ssh (or to the console) and issuing "Reload all services" clears it right up.

Let me know if there's other information I could provide that might aid in diagnosis.

Thank you!