Messages

... was mich zu meinem Steckenpferd bringt: "Disable force gateway" sollte auch als Voreinstellung "aus" sein. Macht auch nur Sinn bei mehreren Gateways. Ich wünsche mir, dass als Voreinstellung das normale Routing greift, nicht der Hack, aber der Hack ist der Normalfall...

Out of morbid curiosity I set up DNSMASQ with SLAAC as the mode with the IP range of my ULA ffd0::1000 to ffd0::2000 (ULA truncated).

I'm fairly certain that it won't make a difference but a ULA is currently defined in the range of fd00::/8

If DHCP works but static assignments don't, you may want to try DHCP reservations. This way, your containers will always have the same addresses and you keep all the address assignment business in one place.

What I cannot deny though is that it might be confusing for some users.

Thanks for taking the time to explain the details. So I got confused just like a few others.

When it tried it, the legacy rules were visible in the new rules UI and they worked, at least as far as I could test it in a small test setup. I realised only after a while that I couldn't modify them.

You're sure?

Yes. Tried it with and without the legacy rules plugin.

And let me try to make this clear once again: This is not about migrating the rules from legacy to new. This is about restoring a complete configuration.xml from a <= 26.4 backup to a 26.7 instance. The legacy rules will be imported as new rules and that import is broken. It is however completely fine to import into 26.7 the rules that have been exported from 26.4.

Well, the solution that Maurice proposed, i.e. use NPT on smaller prefixes than 64, has the drawback of potentially colliding with other tracked interfaces that should not be subject to NPT. Unless, of course, there's code in OPNsense checking this.

With the new WAN tracking feature, while retaining the configuration in 2 places, at least we're using the same prefix numbering.

Hope that makes it clearer.

The confusion comes from the fact that the migration of rules must be completed before upgrading to OPNsense 26.7 or newer. If instead one takes a backup from 26.4 or earlier and just restores it, all the legacy rules show up as new rules. But they can not be selected, edited or deleted via the UI. The instance is borked. If you can't go back to a snapshot, the instance has to be installed from scratch. That's why 26.7 or later should not import the filter section of a legacy style config.xml.

Ich benutze auch für IPv6 DHCP. Dann sieht man die Leases und behält den Überblick was im Netz los ist. Deswegen benutze ich auch für Server DHCP mit Reservations.

Die Information kann man natürlich auch aus den gängigen Netzwerkverwaltungssystemem bekommen, aber typischerweise nur lesend und für ein Heimnetzwerk ist das für mich Overkill.

I tried this too. Unfortunately, the legacy rules will be imported showing up like automatic rules, i.e. they work but can't edited or removed. The legacy rules plugin doesn't help. While it shows the legacy rules in the usual way, it doesn't do anything to the broken import. I wrote about it here. It would be great to have the newer version of OPNsense to not import legacy rules.

Falls bei UDP große Verzögerungen zwischen aus- und eingehenden Paketen liegt, könnte die Firewall den Verbindungszustand bereits verworfen haben. Im Gegensatz zu TCP gibt es ja kein keep-alive. Ich selbst hatte das Problem noch nie und kann deshalb auf die Schnelle leider keine Stelle in der Konfiguration finden, wo man mit UDP timeouts spielen kann.

Ob es überhaupt daran liegt, kann man testen, indem man das Logging der FW für default Regeln einschaltet. Verspätete Antworten der UDP "Verbindung" laufen in die default deny all Regel.

Everything is explained in migration wizard.

Probably, except this isn't about migrating rules, it's about copying a configuration. This used to be a painless procedure in the past, but 26.7 poses new problems. Then again, I may be the last person in the world to still have instances of OPNsense with legacy rules. Then my first point doesn't apply. The other ones are still valid.

[Footnote:]

Please forgive me if this is old news.

• Restoring a configuration containing legacy firewall rules to an OPNsense instance 26.7

Importing a full configuration from a 26.4.1 instance with legacy firewall rules resulted in a 26.7 instance where the legacy rules showed up in the relevant interface sections and did seem to work, but the rules could not be selected, activated, deactivated, edited or deleted, as if they were automatic rules. Installing the rules-legacy plugin even before importing the config didn't help. The rules would show as legacy rules and as new style rules that couldn't be modified.

Another edit: If there are interface groups in the fw config, don't fiddle with the partial import feature. Just delete the whole "<filter>" section from the configuration xml file. This removes the rules but preserves the interface groups when importing.

My solution was to restart from scratch and perform a partial import with the firewall areas unchecked ( see footnote ), then export the legacy rules from the old firewall via migration assistant and import them in the new 26.7 instance.

• Editing floating rules

In the legacy world, floating rules could only be edited in the floating rules tab. After migration, these rules can be edited while having selected any interface they apply to. So, while working on one interface one may change the semantics and scope of the rule for any and all other interfaces, including deletion. This may not be the end of the world, but I can sense trouble down the line because of this.

• Automatic rules display

Expanding the automatic rules display while having selected all interfaces now produces a list of rules per interface. That would be a great tool to find out why 2 interfaces don't behave the same way, except the rules are all over the place because the list can't be ordered by interface, category or description. Sorting by interface doesn't change the processing order, so maybe this feature gets added.

Footnote: Partial config imports are pretty awkward to do since one has to check every area to import, carefully avoiding those you don't want. Moreover, if you check an area that isn't contained in the imported config file, you'll get an error message and you need to exclude them as well before you can retry. And of course, you have to reselect the config file. So please devs, make it a warning only, reserving error messages for show stoppers.

This has been stated many times before and I may have found another reason to stick to this rule: Running NDP proxy on a vLAN will also assign IPv6 addresses to devices on the respective parent interface.

Hello *,

I've just finished hacking dnsmasq into a useable state to replace my ISC DHCP instance. I came across 2 issues that I don't quite know how to handle best and would like to tap the forum for this. I have bolted dnsmasq into unbound via query forwarding.

I can't find a way to restrict dnsmasq to listen for DNS queries on 127.0.0.1 only. I don't want dnsmasq to be available as DNS server everywhere it is used as a DHCP server. It should only be visible to unbound as a forwarding destination.

To enable DNS reverse lookups, I have configured unbound to also forward "168.192.in-addr.arpa" to dnsmasq. It works well, reverse lookups for non-local IP addresses work, too, but I'm wondering if this solution is a bit too clever.

Version 26.7