Topics

1

23.1 Legacy Series / Kernel panic and boot loop when setting a vlan's parent to itself

« on: April 19, 2023, 10:08:39 pm »

Hi all,

during a lab session my students created a new VLAN with parent set to LAN. Then they modified the VLAN settings and chose the VLAN itself as the VLAN's parent. When clicking "Apply" OPNsense crashes immediately with a kernel panic and reboots after some time.

Since the configuration has been saved, OPNsense now crashes on each subsequent reboot causing a boot loop and making OPNsense unusable. I had to boot into single user mode and replace the configuration with a known good one to be able to get it back up and running.

This is on a Deciso DEC2685 running OPNsense 23.1.5_2-amd64.

Thanks
Arno

P.S.: I know that this setting doesn't make sense and probably not a lot of people tried that before, but since my students ran into it, it makes sense to me to report this issue.

2

23.1 Legacy Series / [Solved] Network alias not working

« on: April 11, 2023, 11:13:50 am »

Hi all,

today we ran into the situation that a firewall rule didn't work. The rule uses a network alias called "localnetworks" for network 10.197.216.0/21 as destination. Traffic to this network should be rejected, but the rule never matched.

The configuration of the alias looked ok to me. The alias was enabled.

When looking at "Firewall" - "Diagnostics" - "Aliases" and choosing the alias "localnetworks" from the dropdown there is no entry in the table. The table is empty.

What fixed it for us: Disable the alias, click "Apply", enable the alias again, click "Apply". Now the table is the Diagnostic area is populated again and the rule matches.

So far, so good.

Now when I click "Flush" in the diagnostic area, the network "10.197.216.0/21" is removed from the table. After this, the table stays empty. Looking at the documentation, this table should be repopulated immediately (cf. the Warning at the end of this section https://docs.opnsense.org/manual/aliases.html#hosts).

Is this the expected behavior here, i.e. should the table be left empty? If so, clicking flush has serious implications regarding the firewall rules.

Thanks
Arno

3

23.1 Legacy Series / Unbound recommended configuration for reverse lookup for private IPv4 addresses?

« on: February 23, 2023, 10:29:14 pm »

Hi all,

we are running OPNsense as a router for a smaller network inside another larger network. The inner network contains hosts with private IPv4 addresses only. The outer network contains subnets with public IPv4 addresses and also subnets with private IPv4 addresses. The hosts all have DNS entries in the larger network's DNS.

To be able to resolve the hostnames with the private IPv4 addresses in the outer network from within the inner network, we configured Unbound to forward queries to the outer network's DNS servers and we also disabled the DNS Rebind Check. This works for forward lookups. So far so good.

Though, with this setup reverse lookups for hosts in the outer network with private IPv4 addresses don't work because Unbound does not forward these queries to the upstream DNS servers in the outer network. This is expected and documented behavior. To work around this, we added "unblock-lan-zones: yes" to the "server" clause with a template as described in the OPNsense documentation. This seems to work - until now we haven't seen unwanted side effects.

Now the question is: is this a sensible configuration? Or should we refrain from this approach and take a different route? I would love to hear your recommendations.

Thanks
Arno

4

22.1 Legacy Series / Disable/tune sshlockout

« on: July 04, 2022, 06:10:51 pm »

Hi all,

I am teaching networking technologies for media networks at a university of applied sciences in Germany, where I heavily rely on OPNsense as the main router distribution for teaching and for our internal media networks.

Students can use OPNsense in our lab networks for their practical exercises. Now, it sometimes happens that students repeatedly enter the wrong user credentials for the Web GUI and the sshlockout kicks in. The only way to circumvent the 60 minute lockout is to restart the router which seems to clear the sshlockout table (or to connect from a different IP address and carry on with their tasks from this other machine).

Is there a way to either disable the lockout functionality for the lab routers or to tune the number of failed login attempts to a much higher value?

Any hint is much appreciated!

Thanks
Arno