Messages

1. You need to create firewall rules for each but the first (V)LAN (this already has an "allow any -> any" rule).
2. You should not mix tagged and untagged VLANs on the same interface (it causes all kinds of subtle problems). Unifi does this and even prefers it, you did well to separate all VLANs on one pyhsical interface and untagged DEBUG on another.
3. Be careful / do not use VLAN 1: Many manufacturers, including Ubiquiti, use that to denote "untagged". For some, it it only how they handle the untagged (V)LAN internally, others handle VLAN 1 and untagged the same. If you do not want to think about this, simply do not use it.

You can still use ISC, even with the current OpnSense release. It it just not well supported, since officially, it is EOL and therefore moved into a plugin.

Also, Kea is not the preferred path that Deciso supports. That would be DNSmasq and it seems to support much of what you are aksing for.

I still like Kea better and hope that the situation will get better when more native Kea features would be integrated into OpnSense, like DNS registration for clients or generic DHCP options. If you lack specific features, open a feature request on Github or see if there already is one open.

Did you try disabling "Use graphics acceleration when available."?

[it]

Your question shows that you need to learn a lot about networking:

Your wish is understandable, but this is not how these things work (tm). First, domain names and "traffic" (presumably denoting traffic from specific IPs) are different concepts.

Imagine this: A DNS name like "www.xyz.de" can resolve to a whole set of IPs, some of which may also be used to host other websites, say "www.abc.de". While there is a way of resolving IPs to a DNS name, this a. not guaranteed and b. resolves to only one (i.e. either www.xyz.de or www.abc.de or often, not even one of them.

A real-world example would be a cloud hoster who hosts hundreds of websites on one server. Thus, you may end up in www.xyz.de -> 192.168.1.1 and www.abc.de -> 192.168.1.1 (among others), but when you actually look at 192.168.1.1, you may find "server.cloudhoster.de".

Now, when your firewall inspects an IP packet from 192.168.1.1, how should it determine if this packet should get blocked, because you want to block www.xyz.de? All it knows is that this IP resolves to server.cloudhoster.de. And "*.xyz.de" is even worse than just "www.xyz.de", because it denotes all subdomains of xyz.de, which you can cannot even iterate on - you must ask for any specific name in that zone, because *.xyz.de itself resolves to no IP at all.

That is why what Cedrik says does not work for you: You can block those IPs that a specific name www.xyz.de resolves to, but that will not cut it for *.xyz.de.

So much for that: It is impossible on the "traffic coming from any domain".

If you put your question differently, you may end up with a different result. For example, you can use a DNS block list that can be used to prevent the DNS resolving of specific domains.

Whenever a client on your network tries to access a blocked DNS domain, it first must resolved the DNS name to an IP - and it gets none, thus preventing access, from, say, a browser on that client, effectively blocking access from your LAN to that domain (but not the other way araound).

So, there you have it:

- There is bad domain names that you do not want your LAN clients to have access to - block them via DNS block lists. That only covers outbound access!
- There are bad IPs (not neccessarily related to domains) which you can block incoming by other means, such as Firehol, AbuseIPDB, Blocklist.de or via the QFeeds plugin. You can even block specific GeoIP ranges or ASNs. Look up what those are, it is all in the documentation.

That being said: If you really want to use a pro tool like OpnSense, you will need to learn the concepts behind it. Otherwise, you will end up taking risks you do not understand. This may all sound condescending, but it is just a fair warning.

Welcome to the forum!

Das RAM ist das eine, die CPU hat aber nur ca. 1/3 der Performance eines N100 - für Gigabit-Speed eher ungeeignet, DSL mag noch gehen.

Interesting, I did not find any release notes on the download page for the BIOS update.

Again, the CVE is most probably adressed by a microcode update that is also in the OpnSense microcode package - and if the functional update was not for for anything that kept your OpnSense instance from working (well, obviously not), then what does it fix (for you)?

Also, if you use your search engine chi (I did), you will find references to that boot problem and the probable microcode cause, so you do not have to investigate.

To conclude - and only IMHO:

1. You now know how to fix the boot problem, even with 1.15 applied.
2. I explained why I think that neither security upgrades via microcodes not functional upgrades warrant BIOS updates after installation (mind you, provided that you keep OpnSense current, which you did not). You are entitled to your own opinion, of course.
3. I gave pointers to the probable root problem of this failure which you may or may not care to investigate.

After OpnSense has booted, the BIOS does not control much any more (except from vPro features, that is). So if the BIOS is viable to control your hardware (fan control, disk drivers for boot phase), it should never need an update, unless hardware is changed or CPU microcodes must be applied.

Since OpnSense offers a way to update the microcode independend of the BIOS, you actually do not need to update the BIOS any more - this is even more true if the only reason to update the BIOS is in fact updated microcode. I think this may be true for most systems older than 5 years.

I think this is true of your BIOS 1.15, especially, because there are no release notes as to why there is an update - maybe security patches are not even mentioned for "security by obscurity" reasons. Matter-of-fact, there are no functional reasons given, either.

I think that the 1.15 BIOS may have Intel microcode update from september 2025, so you probably need some very recent UEFI code to fix the problems caused by that. Other than that, there are probably only the microcode updates in there that caused Dell to issue that release.

Since it may be only the UEFI code that causes problems (and not the FreeBSD kernel), you could skip the BIOS update and only use the OpnSense microcode package. That is applied after the UEFI bootloader has finished.

Another possible trick would be to use BIOS boot instead of UEFI boot - OpnSense can do both.

I would guess that your OpnSense installation is a little older. You must know that OpnSense does never upgrade the actual UEFI bootloader.

Yours may be incompatbible with your current BIOS / microcodes in version 1.15.

So, once back to the running 1.14 release, you could try to manually upgrade the UEFI bootloader and then try again to upgrade your BIOS.

See this - not exactly your situation, but the instructions on how to update the boot loader probably still work. Patrick is the expert on these matters. Be careful about your specific partitioning.

That depends. Cliets are free to use many IPv6 at the same time: LL, ULA and GUA, and also multiple ones of the latter.
For outbound access, they have means to determine what is best (like if they use privacy extensions, they will use a random GUA preferably). For inbound access, they will react to any of them. So, if you want to have a permanent DNS handle, you would use the EUI-64 GUA (or ULA for dynamic prefixes).

As said, many clients derive that from the MAC, Windows does not, but AFAIK, the EUI-64 part still is static.

For Ubuntu and other Linuxes, I normally see MAC-derived EUI-64 parts with SLAAC, so IDK what the reason is that your see otherwise - maybe some DHCPv6 service is in play?

Now we are almost back to what I wrote in post #6:

Because you have to provide the conduit anyway (which is the hardest part), I would always prefer to do the inhouse cabling all by myself. That way, you can choose to use the original outlet in the basement if you so choose later on or extend that via a single-mode fibre cable to any location you need.

This can be done via a conduit and cable (as said, they are dirt cheap) or a system like Huawei, where you can even skip the conduit altogether and have the inhouse cabling pratically invisible glued to the wall (modulo wall breakthroughs).

It does not need to be, the gateway you are given can also further away than your counterpart. IDK how / if the Asus router shows its gateway.

If your prefix is static, you can create overrides in Unbound for any client, using its EUI-64. So you get <prefix(56 bits)>+<interface prefix (8 bits)>+<client-EUI-64> as IPv6 for usual clients.

Note that some clients (e.g. Windows) choose to use arbitrary suffixess instead of a MAC-derived EUI-64 for privacy reasons. I am not talking privacy extensions here with changing suffixes, but hiding the MAC, which could normally be derived from the suffix.

Yes, the WAN IP as well as the default gateway are on Plusnet. However, neither is reachable from here as well. This looks like a new development area where connectivity is not yet established.

On the other hand, if it works with an Asus router... I would check what WAN IP and default gateway you get with the Asus router. But heck, ask your ISP what is wrong there. Obviously, they give your the PPPoE credentials, so they must be able to deal with a different router.

Some ISPs detect a router change and give you a temporary non-routable network in which you can register your new hardware. Some do this for ONTs only, others even want to know when the router changes. Ask them, they must know.

Maybe your WAN IP is now something like 10.x.x.x, which would give an indication.