Messages

Quad9 are located in Switzerland and seem to be ok:

https://quad9.net/about/foundation-council/

1.1.1.1 also seems O.K. to me (and it is by far the fastest DNS resolver I know of).

That looks as if 25.7.8 upgrade was done (potentially incomplete) and now you do not have internet access.

From what version did you start out? If it was < 25.7, see https://forum.opnsense.org/index.php?topic=48343.msg244891#msg244891

If that is your situation, you need to apply the fixes, preferably before the upgrade.

The GMKtec has 2x I226, so that is better than Realtek NICs (although you will want to use the NICs as virtio interfaces).

I see a problem with the WiFi uplink, though. You want that to be the WAN of your OpnSense, yet WiFi chipsets are badly supported under FreeBSD and OpnSense. You cannot set it up under Proxmox, either, because that should be connected only to your OpnSense's LAN side.

That was less of a problem if the WAN uplink were through one of the RJ45 interfaces and the other one was used for the LAN - but that would mean you need a switch to conenct both your main desktop and an AP.

Do not underestimate the setup, because OpnSense on Proxmox is special.

I personally do not like Router-behind-Router scenarios, because they tend to give all kinds of problems, see https://forum.opnsense.org/index.php?topic=42985.0, point 4. For one, you will have to do port forwards on both OpnSense and your outer router in order to give access from outside.
Also, if you need IPv6, this might get difficult to set up (if it works at all).

I do not really understand why you would want to keep the TP-Link in the loop, because that is a standard router without any ONT/modem inside, so OpnSense can do its jobs all on its own, so it is not needed (unless you must extend the reach via WiFi, which is problematic anyway).

Did you also take a look at this, especially the section about 'Network "hardware"'?

IDK how to exactly do the "multiqueue" setting on your platform, in Proxmox, it results in "queues=4" in the tap interface settings. I think this should be used with RSS on OpnSense itself.

IDK how you got the <WAN_GATEWAY_IP> into that rule at all, since I do not see where you could select that from the UI. Out of curiosity: How did you do that?

Your rule will never fire this way, because you do not see the packets your rule would select.

The target of a ping would be the WAN IP, which you can select from the dropdown as "WAN address". You could also use "this firewall". Your rule should simply be:

You cannot view this attachment.

If you want to be sure, create it in Floating Rules and move it to the top of the list.

If you need production quality, you should either consider delaying to apply upgrades until first glitches have been ironed out, or - even better - get a business license where code has had the chance to mature another few months over the community edition.

OpnSense CE, like many open-source products, is a trade-off: you get it for free, yet you are volunteering to test.

Du weisst aber schon, dass bei Hetzner für IPv4 eine strikte Bindung MAC <-> IP notwendig ist, oder?

Im Robot kann bzw. muss man deshalb auch separate MACs für weitere IPs setzen. Wenn der Virtualisierungshost z.B. Proxmox ist, definiert man typischerweise eine Bridge, dann muss man aber genau sortieren, wer ggf. welche MAC verwendet. Hetzner selbst beschreibt typischerweise ein Setup, bei dem der PVE seine MAC und die erste IP behält und die zweite MAC wird dann in der OpnSense gesetzt.

Siehe: https://docs.hetzner.com/de/robot/dedicated-server/ip/additional-ip-adresses/#nutzung-mit-virtualisierung-per-bridged-methode

Das ist hier beschrieben: https://forum.opnsense.org/index.php?msg=220167, in dem Thread geht es anfangs nur um Proxmox / OpnSense allgemein, denn auch dort gibt es Fallen.

Es gibt auch die Möglichkeit, OpnSense unter Proxmox mit nur einer IP zu betreiben, siehe hier: https://forum.opnsense.org/index.php?msg=248117

Und ja, manchmal klappt das mit dem Einrichten zusätzlicher IPs nicht.

Ich lege unter Firewall: Groups eine Interface Gruppe an, die alle lokalen VLAN-Interfaces enthält und nenne sie LOCAL. Die verwende ich dann als Interface in "Firewall: Rules: Floating". Wenn ich später weitere VLANs anlege, muss ich die nur der Gruppe hinzufügen und nicht jeder einzelnen Regel.

Es gibt eine "Abarbeitungsreihenfolge" der Regeln, siehe: https://docs.opnsense.org/manual/firewall.html#processing-order

Die greift noch vor der Reihenfolge innerhalb der dort dargestellten Regeltypen. Somit würde eine "Allow" quick-Regel in den Floating Regeln immer vor jeder eventuellen "Block"-Regel im Interface ziehen, mithin kannst Du in den Interface-Regeln nichts mehr verbieten, was in den Floating-Regeln erlaubt wird. Die Floating-Regel feuert und dann ist der Rest egal. Deswegen beschränke ich Floating-Regeln meist auf eine Interface-Gruppe "LOCAL".

Dazu auf dem WG interface ein Block, sodass, auch wenn auf der einen seite eine falsche flaoting regel vorhanden wäre, es nicht auf der remote Seite, das wg interface passieren würde!

Kritisch wäre, wenn auf "Deiner" Seite eine Floating-Regel etwas erlaubt, weil die vor den Interface-Regeln greifen. Wie gesagt, um das zu verhindern, nutze ich immer eine Interface-Gruppe für die "Nicht-WG" Interfaces (=VLANs) und nutze die in den Floating Regeln.

Ansonsten immer am lokalen Ende des WG-Tunnels filtern, der "andere" kann ja erlauben, was er will.

ICMP is a low-priority service that is not guaranteed to work. Some gateways do not reliably answer to those requests, especially when they are under high load.

Na klar. Du musst bei site-2-site das Wireguard-Interface praktisch genau so behandeln wie ein WAN. Wenn der Tunnel steht, bestimmst Du, was drüber hereinkommt.

Ich mache das immer explizit, indem ich in den WG-Interface-Regeln am Ende ein block auf Ziel any mache und ggf. davor spezifische Regeln. Du musst aber bedenken, dass Floating Rules eventuell früher ziehen als Interface-Regeln. Deswegen muss man dort genau darauf achten, für welche Quell-Interfaces diese Regeln gelten. Ich habe dafür zwei Typen: 1. "alle" - das sind dann beispielsweise DNS und NTP auf der Firewall und 2. Gruppe "lokal", das sind meine eigenen VLANs, die die WG-Interfaces nicht einschließen. Darin wäre dann z.B. Zugriff auf einen Log- oder Mailserver.

I already wondered how this was possible - for me, DoT works as expected as verified by a tcpdump. So it is only the column in the grid that display the wrong value, mainly a cosmetic problem.

Forget those TDP numbers.

First off, for the Intel N series, these are most often "TDP down" values which no manufacturer uses for sake of higher performance ratings. Even the N100 is often configured at 25 Watts TDP and for some BIOSes, you need special tricks to bring these down, which you will need when you have a passively cooled system.

Second, with normal load on the system, the numbers are often lower - take the Minisforum. 100W TDP is only for the CPU, but at max load. In reality, the CPU will likely use 8-10 Watts and the rest of the system ~15W, so the real power draw will likely be more like 35 Watts.

An N1x0 will be more like 20-25 Watts, the N355 (estimated) ~30-35 Watts.

Many IoT devices only support SLAAC, if they support IPv6 at all.

Other than that, you have to select the correct RA mode to instruct devices to use DHCPv6 for all interfaces where you want it.

To me, it does not make much sense to use DHCPv6, even if you want to identify devices, because with IPv6 privacy extensions and randomized MACs these days, you cannot effectively do that anyway. Therefore, I prefer to use SLAAC only: https://forum.opnsense.org/index.php?topic=45822.0