Messages

That is a fundamental question, but note: I never promoted to do that. Actually, I would do it only for good reasons, which do exist.

If you assume a Linux driver issue that can be exploited on the PVE host, OpnSense will not protect you. You can impede that somewhat by using passthru, where OpnSense itself drives the hardware, which could be useful for the WAN NIC. On the other hand that will undermine purposes such as Linux drivers often being more stable than FreeBSD ones, like for Realtek cards, where you would want to use virtio.

However, usually, you will have to reach the NIC via IP first and PVE does not have control over the network layer, such that your attacks must be crafted to reach the IP, but attack lower layers. Otherwise, the packets will not even get through to your system.

Most attacks aim at higher layers these days and you could argue that there are many more lower layer attacks which you cannot prevent. Think of Intel I226-LM adapters which allow for remote administration OUTSIDE anything your "machine" does by virtue of Intel vPro/AMT.

Note that the PVE interface itself is hidden "behind" OpnSense, on the logical LAN interface, which usually exists on a (virtual) bridge and is often reachable only from VMs behind OpnSense or internal clients. In the case of a cloud-hosted instance, you will probably allow access only through a VPN configured in OpnSense - at least I do it like that.

That way, the outside attack surface is small - and also, since OpnSense and all other instances are VMs in this case, I can always roll back to snapshots or backups.

Remember: there is no 100% security - this will always be a tradeoff.

My problem seems unrelated as of now, probably just a glitch. At least it never turned up again.

Siehe https://forum.opnsense.org/index.php?topic=42985.0, Punkt 3.

Yes, I can shift order within multiple groups.

But what happens with rules that once where in the floating rules that apply to only one interface during migration?

AFAIU, they will become an interface rules by virtue of them having only one interface. So, say I have an "Allow all but RFC1918" rule in a restricted group rule. If a floating block rule for, say, QFeeds was in the old rules only for one LAN interface to keep clients to connect to malware sites, it would get demoted to an interface rule and overridden by the group rule allowing essentially all internet traffic.

With the group rules residing "between" floating and interface rules, the "only one interface switch" effectively causes an implicit shift of two priority levels, or am I incorrect?

That would mean I have to place block rules somewhere else (at least if they apply to one interface only). I know that does not affect you, Patrick, since you block only on WAN inbound.


P.S.: I just tested that and found that floating rules that apply to one group only get shifted to the group section...

I see. Jumping to conclusions on my side, because I often did that via two rules, one blocking access to "internal net" and one allowing everyting else.
This was easier because you can then use a more concise rule description. But with only one "allow" rule, it works. One must remember to only use allow in the group rules.

I found a problem with how the new rules scheme will be handled with Patrick's approach:

Imagine a typical "Allow any to !RFC1918" rule for any non-privileged VLAN. Actually, it would be better to have "!internal net" instead, which applies to both IPv4 and IPv6, BTW.

In Patrick's and my scheme, you would be tempted to move that to the end of the restricted group rule instead of at the end of each individual interface rules - as is shown in Patricks ruleset above.

However, when you want to make any exception to that general rule, e.g. if you have a monitoring client in one of your restricted networks, you would simply place them before that last interface rule. Since the group rules are prioritized higher, you would have to move such individual rules to the floating section to preceed the group rules if you were to have a general group rule.

As a side note, this has the disadvantage of forcing most of the specific rules to the floating section, although they apply only to one VLAN, which makes things less transparent, but it still works.

However, this scheme breaks once you do the migration to the new rules: Any such specific floating rule that applies to only one interface will move to the interface section, where it now does not preceed the group rules any more and thus does not work.

Therefore, it would still be better to leave the "general" rule in the individual interface rules: It makes things clearer and survives a rule migration.


Somehow I had a hunch that this "one interface only" switch in the new rules scheme would cause problems., because it mixes up the priorities.

[keine]

Ihr wisst schon: "Geht nicht" ist keine valide Fehlerbeschreibung. Zum einen scheint Kea betroffen. Startet der? Wenn nicht: Welche Fehlermeldung erscheint? Wie sieht die dazu führende Konfiguration aus?

Am Rande: Ich nutze auch Kea und bei mir geht es. Das ist eine valide Beschreibung - ich erwarte ja auch keine Problemlösung.

*phew* What a rabbit hole :-)

I wonder what percentage of people can still follow what we are talking about here... ;-)

Yet, I had only the typical "Block RESTRICTED to local networks" and "Allow any to internet" rules in the RESTRICTED group, which I switched out for explicit interface rules at some point. Unless you have a large number of VLANs, it seemed more explicit that way to me.

Made me laugh, Patrick, because I have exactly the same distinction between "internal" and "restricted" (this one even with the same name).

As for your question: Look under Firewall: Groups, the interface group have an assigned "sequence" which I believe to determine the order.

Siehst Du, die Subnetzstruktur wäre mit OpnSense eben kein Problem (mit VLANs).

Der Reverse Proxy läuft auf der OpnSense und reicht namensbasiert von seiner IP 10.1.0.3, wo er auf 80/443 lauscht zu dem (oder den) Webserver(n) im "LAN" (= DMZ) durch. Er kann u.a. die Beantragung von Zertifikaten machen. Ob es Caddy oder HAproxy ist, ist dabei ziemlich egal und man kann es natürlich auch mit IPv4 only machen.

Unterschätze den späteren "Umbau" nicht - es ist wahrscheinlich einfacher, gleich alles richtig zu machen - besonders, wenn die Frau und die Kinder dann nerven, weil das Netz wieder nicht mehr funktioniert.

[0]

Das kannst Du so machen, wenn es auch eine sehr eingeschränkte Nutzung für OpnSense ist, bei der ggf. Blocklisten oder GeoIP erst nach der Fritzbox wirken. Wie Du weisst, sollte man die Angriffsfläche möglichst minimieren. Auch wird das alles in Bezug auf IPv6 schwierig - ich habe keine Ahnung, ob/wie man die IPv6-Präfixe delegieren kann oder ob Du das brauchst/willst.

Ich würde aus pragmatischen Gründen auch das Port-Forwarding nur auf der Fritzbox machen und auf der OpnSense anstelle von Port-Forwards oder Firewall-Regeln lieber einen Reverse-Proxy einsetzen, aber das hast Du ja schon gelesen. Eins davon musst Du auf jeden Fall tun, weil auf einem typischen "WAN" Interface per Default kein eingehender Traffic zugelassen ist (NAT musst Du dort dann auch abschalten).

Was die Subnetze angeht, solltest Du vielleicht noch dies lesen. Ohne Not würde ich weder ein /16 definieren noch 192.168.0.x/24 nutzen.

Richtig ist, dass Du damit eine DMZ schaffen kannst, die nur ins Internet kommt und keinen Zugriff auf interne Geräte hat. Das wäre aber eleganter auch mit einer OpnSense "vorne" möglich.

Man kann das mit den zwei Beinchen schon machen - ich mache das manchmal mit Proxmox. Aber wenn man das tut, muss man eben darauf achten, welches der Interfaces die Default-Route bekommt.

Für Dein Szenario bietet es sich eher an, dass Du für die DMZ-Systeme ausschließlich die DMZ konfigurierst und dann den Zugriff vom LAN in die DMZ erlaubst (ggf. limitiert auf Management-Clients). Das ist unabhängig davon, ob man den DMZ-Systemen Zugriff ins Internet gibt - die Default-Router sollte jedenfalls über die OpnSense laufen, damit man es zentral managen kann. Ein Weg vorbei ist ein No-Go, wie Patrick ja schon schrieb.

Yes, for starters: why is the source "This firewall" - you should have the list of clients that will be forced to use your local DNS there.

See this, point 29 and what is linked there.

What is the question?

If that MTU works for you, you could probably distribute it network-wide with DHCP option 26 and there is also an RA option to send it, but as I said, IDK if those work for most clients.

Ah, so you only got problems because of PPPoE. Yes, you should use the same MTU as on WAN, because if you do not clamp your MSS, you may experience problems with sites that have defect PMTUD.

You can also try this - but only if your ISP supports mini jumbo frames... if that works, you can use the "usual" 1500 byte MTU and problems as this will be resolved. There is no 100% guarantee, though.