Messages

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

Right. SLAAC is meant to give IP adressed to clients. They can even take up random IPs (e.g. with privacy extensions). Those are for outbound access, mostly.

If you want to make your clients addressable by name, you can use these mechanisms:

1. IPv4 only (this is the simplest and my recommendation): Do not bother to make your clients addressable by IPv6 at all.
2. Via DHCPv6. While this works, the DNS entries hold as long as your DHCP lease time and thus, may be wrong with dynamic prefixes.
3. With static prefixes: Use SLAAC and hope that the client uses EUI-64 (potentially among others). Then you can statically namen your clients via PREFIX:EUI-64. In this case, you can also use DHCPv6.
4. With dynamic prefixes: ULAs may be your friend, but note that they are prioritized LOWER than even IPv4 - contrary to popular belief).

Because most people have dynamic prefixes, I prefer to use 1., but with SLAAC for outbound access only. This is all covered here: https://forum.opnsense.org/index.php?topic=45822.0

Mir stellt sich die Frage, was Du genau vorhast:

a) Dein Netzwerk aufzubauen und vorab zu spezifizieren, was Du willst und dann dokumentieren wie Du es genau gemacht hast?
b) Dich beraten zu lassen, wie der Übergang Deines Wünschens zur Realisierung geht?
c) Einen allgemeinen Leitfaden für den A-bis-Z-Aufbau zu schreiben?

Die Probleme hast Du selbst schon benannt:

a) Das wird dann sehr spezifisch für Deinen Aufbau / Deinen Provider / Dein gewünschtes Setup. Der nächste Anwender mit geringen Netzwerkkenntnissen scheitert am ersten Unterschied zu Deinem Setup - ggf. bereits beim Verbindungsaufbau zu seinem Provider.

b) Ja, das hätten alle gerne, dass sie durchgecoacht werden - allerdings: da lernst Du nichts bei (Zitat: "fällt es mir leider schwer, mich über längere Zeit in technische Dokumentationen zu vertiefen") und stehst am Ende vor der Situation, dass Du das nicht warten kannst. Das ist potentiell gefährlich. Ich sage es immer wieder: wer OpnSense mit einem Consumer-Produkt wie die Fritzbox verwechselt und glaubt, sein Netzwerk damit "irgendwie sicherer" zu machen, irrt.

c) Wie Patrick schon schrieb: Anleitungen gibt auf drei Ebenen:

1. Bücher wie "Der OpnSense-Praktiker" - als Überblick und Starthilfe.
2. Tutorials, die bestimmte Themen im Zusammenhand behandelt.
3. Die OpnSense-Dokumentation für einzelne Teile im Detail.

Ich kapiere gerade nicht, wo Du da zwischen willst.

Das ist doch eine reine Geschmacksfrage. Du kannst das auf drei Arten lösen:

1. Indem Du der Anlage beibringst, öfter Keep-Alives zu senden, um die Ports offen zu halten.
2. Global auf der Firewall alle Ports länger offen zu halten.
3. Lokal in der spezifischen Regel die spezifischen Ports länger offen zu halten.

Ich würde das Übel an der Wurzel anpacken und 1 nehmen - aber das schrieb ich ja schon. Denn: andere SIP-Geräte machen das selbst richtig.
Nummer 2 ist eine Notlösung mit offensichtlichen Drawbacks. Nummer 3 hat den Nachteil, dass Du nächstes Mal dran denken musst, dass da noch "versteckte" Optionen nötig sind.