Topics

1

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.

2

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

3

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!

4

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!