Messages

@mooh These firewall rules have nothing to do with the default route in the routing table.

I agree, it doesn't change the kernel routing. Thanks to your response I now understand the question better, so please ignore my comment.

Have you looked into the Firewall:Settings:Advanced:"Disable force gateway" setting? By default OPNsense creates a default policy route for traffic originating from the FW itself.

Same happening for me updating one of my DEC750s from 25.10_2. on the first one, the process went exactly as described, updating pkg first, then another check followed by an update to 25.10.1.

The other however, did not update pkg, produced the ,,danger" message, stopped screen updates around package 21 of 75 and the stopped responding altogether, 403 errors via https, immediate logout via ssh and on the console with the ,,sh: /usr/local/libexec/opnsense-auth: not found".

Speaking of the console, the output didn't look anything like OPNsense booting. Luckily, I created a snapshot before the first attempt at updating and so I was able to restore the system from that.

Back logged in via https, I noticed that pkg is already at 2.3.1_1. This is different from the other system and I have no explanation for that but shouldn't pose a problem as that is what the first stage of upgrading should yield anyway. So I started the update again. Again, the danger message popped up but the update procedure continued to the end and the reboot was successful. However, my maintenance window was up, so I didn't dig into the cause of the error message and instead booted the know-good snapshot.

That's the story as it happened Thursday evening between 19h and 20h. Today, I used another maintenance window, ran the update and everything went fine, no danger message, no nothing. This of course leaves me wondering: what has changed to yield 3 very different outcomes? Any changes to the update procedure and packages? If so, I can't find anything in the release notes.

Also, don't get carried away with the number of servers or pools. A large number of servers may not improve your results.

When choosing pools, it's best to learn what type of servers they're bundling. For me, I have chosen 2.de.pool.ntp.org because it includes IPv6 servers and they tend to work best for me.

Just to let everyone know: I just discovered that for the last 2 days squid has been crashing without restarting. It popped up while running ansible apt updates on a number of machines. As it turns out, squid crashes on every 3rd "apt update", wether ansible is running in parallel mode or sequentially. I have been unable to find anything in the logs nor any core dumps. Resetting nor re-installing the plugin has not helped.

Squid was only used here to work-around auto-proxy config problems debian had for a while some time ago. I solved the issue creating an interface group with the required FW rules and removed squid from the firewall.

Good advice. Of course it is best to search for <if>igb0</if> while replacing

For a while I had an old mac mini with additional thunderbolt ethernet ports as a backup for a DEC750. I used to download the config from the DEC750 and run it through sed (global search and replace tool) to replace all interface names, like "s/igb0/bge1/g" and so on. One may even map multiple interfaces from the old setup to one in the new one. Worked like a charm for me.

Just note down the interface names on the originating machine, log into a default installation on the destination machine and you'll see which interface names need to be replaced and how. Modify the config file and restore it on the new hardware. Same in your case, when changing interface adaptor cards.

Thanks for taking the time to respond.

I take it that such a rule cannot be written on a firewall group or floating rule level. So my question comes down to is there some sort of automatic variable that can used in a rule to fill in the <network> placeholder (ideally the broadcast bits as well)? Otherwise, that part of the interface configuration would be duplicated into the rule and create two places that need to be kept consistent without being obviously related. Same would be true for using an aliases for the directed broadcast addresses.

Ignore as in suppress in logs, etc. The general question being, is there a way to handle directed broadcasts other than on an interface basis.

In a network full of SMB devices, there's lot of IPv4 directed broadcasting to <network>.255:137, e.g. in 192.168.1.0/24 192.168.1.255:137. Is there a way to have a floating or firewall group rule to ignore such traffic?

At one of my sites, there's heavy use of network segmentation. Firewall groups keep the rules in check. In such a scenario, monitoring a group of interfaces can be extremely helpful. The interfaces within a group have already been named in a consistent way, i.e. they all share a common prefix.

Unfortunately, in Firewall: Log Files: Live View, selecting "interface contains" brings up the same menu list as "interface is", i.e. it is not possible to select multiple interfaces by matching their names as partial strings nor is it possible to select a firewall group.

The work-around is to create a composite filtering template, joining the individual results. Such a template however requires adjustment every time there is a change to a group of interfaces, but there is no obvious connection between them, making maintenance hard.

So my proposal is to either make "interface contains" a string match or allow firewall groups to be matched. At the very least, remove "contains" if it yields the same result as "is".

Heute morgen hat mein Telekom Glasfasermodem 2 zu Hause seine Firmware selbstständig auf 090144.1.0.009 aktualisiert und wieder hat's keiner gemerkt. Im Log meiner DEC750 mit 25.4.3 steht was von Link State Down / UP, das WAN Interface hat sich neu initialisiert und alles lief weiter, sogar mit gleichem IPv6 Präfix.

Mikrotik hat ne vergleichsweise gute Erklärung für VLAN Einstellungen. Nur die Beschreibung für Force VLAN ID ist sprachlich sinnlos.

Thanks for looking this up, meyergru. The discussion on github is taking a wrong turn, in my opinion. Other 2FA enabled systems use a two step approach, the 2FA only being queried after the account and password screen. The point is, the second screen will always be displayed, regardless of the correctness of the account/password pair, thus not giving away any indication of the correctness of the info in the first.

+1 for Patrick's point

It appears that in order to enforce OTP authentication the local database must not be used concurrently. However, when configured this way, access via ssh + password is lost. Thus, you can have it only one way or the other at a time. I think it should be possible to use both methods concurrently. Is there a way to achieve that?

P.S.: Please no discussion about ssh + password...