Messages

Der nächste Schritt wäre doch dann, Regeln in der Firewall einzustellen, damit die LAN-Schnitstelle mit der WAN-Schnittstelle kommunizieren kann bzw. Gateway mit der WAN-Schnitstelle.

In Firewall Regeln erlaubst oder verwehrst du einer Quell-Addresse Zugriff auf eine Ziel-Adresse, ggf. noch Ports und bestimmte Protokolle. Schnittstellen der OPNsense sind dabei nur insofern relevant, als dass du die Regel auf jener erstellst, an der das Quell-Gerät angeschlossen ist, also an dem der Traffic rein kommt.
Wo der Traffic raus geht, bestimmt die Routing-Tabelle. Ausgenommen sind Policy-Routing Regeln, die das normale Routing überschreiben.

D.h., möchtest du HTTPS vom LAN1 Gerät mit der IP 10.0.1.10 nach 1.1.1.1 erlauben, muss die Regel am LAN1 definiert werden, Protokoll TCP/UDP, Quelle ist 10.0.1.10, Quell-Port = jeder, Ziel = 1.1.1.1, Ziel-Port = 443. Und wenn HTTPS nach überall hin erlaubt werden soll, ist das Ziel "jedes".
Anfängerfehler, die hier nicht selten passieren, ist nämlich "WAN net" als Ziel zu setzen, das wäre aber nur das Subnetz, dem WAN angehört. Ebenso wäre die Gateway-IP hier falsch, auch wenn die Pakete tatsächlich dahin geroutet werden.

Innerhalb eines Subnetzes wollte ich nicht alles per DHCP umsetzen. Gewisse Geräte sollen IPs erhalten, das würde ich mit MAC Adressen Mapping umsetzen wollen. Spricht etwas dagegen?

Das meinte ich eigentlich. Statisches Mapping macht der DHCP Server.
Das ist einfacher und vor allem flexibler als die Netzwerkkonfiguration auf jedem Gerät zu machen.

Grüße

Well, I'd expect, that it would work with these settings. But the gateway is shown as offline, using 1.1.1.1 as monitoring IP.
You can ping 1.1.1.1 from inside your network, but obviously OPNsense can't.

This let me suspect, that outbound traffic on the WAN from OPNsense itself is not natted properly.
Are you missing the outbound NAT rule for the source range of 127.0.0.0/8?

Looks like 1.1.1.1 is assigned as a gateway for some reason.

What shows System > Gateways overview?

aqua is my wireguard interface

So you're running a Wireguard VPN on the webserver itself?
And the tcpdump should tell me, that responses go to the WG IP?

I guess, that what you see here, belongs to a different connection, but hard to tell due to the IP obscuring.

So obviously the webserver doesn't respond, if the access is coming from the internet (or outside of your LAN). You can also sniff the traffic on the internal interface to get sure.

meyergru already mentioned the most proper possible reasons for this issue. Did you verify them already?

To verify if the packet on port 36570 even arrive, start a packet capture on the WAN, filtering for port 36570, then try to access it from outside.

How is your WAN interface configured? Is it static or DHCP or PPPoE?
What is the interface IP?
What is the gateway IP?

Unter der Annahme, dass der Adressblock 10.0.0.0/8 für vtnet1 (LAN-Netzwerk) eingestellt wird, würde – wie im Screenshot (Screenshot 2025-08-17 at 21.00.07.png) – nur ein Subnetz erfolgen, oder nicht?

Ist eine Segmentierung dann überhaupt noch möglich?

Eine Segmentierung müsste doch dann über optionale Schnittstellen realisiert werden können. Ist der Ansatz so richtig ?
Bspw:
 

1. Management
    Netz: 10.0.1.0/24
    Zweck: Proxmox, OPNsense, Switches, Access Points
2.LAN (Standardgeräte, PCs, Server)
    Netz: 10.0.2.0/24
    Zweck: normale Endgeräte, Desktop, Laptop, NAS
3.IoT/Smart Home
    •    Netz: 10.0.3.0/24
    •    Zweck: Zigbee, Kameras, Frigate, Home Assistant, ESPHome, Sensoren

Würde man weiterhin auch nur auf ein Gateway setzen?

Ja, wäre so in Ordnung.

Ich weiß jetzt nicht, was du mit "nur ein Gateway" meinst.

Das Gateway, ist das Tor in andere Netzwerksegmente bzw. ins Internet. In jedem Netzwerksegment gibt es zumindest ein Gateway (wenn eine Kommunikation mit Geräten außerhalb möglich sein soll) (Standard-Gateway).
Geräte können nur mit anderen IPs innerhalb des eigenen Subnetzes direkt kommunizieren (Layer 2). Alle Pakete mit Zieladressen außerhalb des Subnetzes werden an das (Standard-)Gateway geschickt. Deshalb muss dieses eine IP-Adresse innerhalb des Layer 2 Subnetzes haben.

In 10.0.1.0/24 hätte OPNsense in deinem Beispiel z. B. die IP 10.0.1.1. Das ist dann das Gateway für die Geräte in diesem Netzwerksegment. Die OPNsense bekommt also die Paket und leitet sie gemäß der Zieladresse weiter, wieder über Layer 2.
In 10.0.2.0/24 hätte OPNsense 10.0.2.1, was die Gateway IP für das Subnetz ist. Usw.

Wenn du DHCP für die Zuteilung der IP Adressen nutzt, was ich empfehle, auch wenn sie statisch sein sollen (Static Mappings), dann verteilt der DHCP Server automatisch die jeweilige Interface IP als Gateway an die Clients.

Grüße

You have to nat outgoing traffic from OPNsense itself (127.0.0.0/8) to the WAN address.

All other traffic from networks behind has to be natted to the WAN VIP.

Hallo!

Habe ich nachteile, wenn ich auf das 8er Netz wechsel (Mehr Rechenleistung etc.)?

Mit dem 10/8 wollte ich sagen, dieser Bereich ist groß genug. Ich dachte aber daran, nur ein /24 daraus zu nutzen wie bspw. 10.15.14.0/24, oder auch ein größeres, falls nötig (/23).

Nachteile mit großen Subnetzen könnte es bei der Verbindung mit anderen Netzwerk via VPN durch Überschneidungen geben.
Ansonsten ergibt sich mehr Traffic (Broadcasts) nur durch tatsächlich mehr Geräte im Netz.

Welches Vorgehen wäre denn eine geeignetere alternative?
Grundlegend ist es alles in einem Haushalt.

Segmentieren soweit nötig.

Auch in einem Haushalt gibt es üblicherweise Geräte unterschiedlicher Vertrauensstufen. Bspw. IoT sollten in jedem Fall von PC, Laptop getrennt werden.
Diese Dinger sind oft mangelhaft abgesichert und könnten ein Einfallstor in dein Netzwerk sein, auch wenn sie nur eine Verbindung nach draußen aufbauen dürfen, und das muss die meisten erlaubt sein, damit sie funktionieren.
Also am besten IoT Geräte in ein separates Subnetz legen. Ebenso wirklich vertrauenswürdige Geräte (PC, Laptop mit gepflegten Betriebssystemen). Diese können dann vielleicht auch auf Proxmox zugreifen.
Ich habe dann noch ein zusätzliches Subnetz für den Rest (Smartphones, etc.) und für Gäste.

Mit einem VLAN-fähigen Multi-SSID WLAN AP lässt sich das recht einfach realisieren.

Explizit ist 10.0.0.1 Gateway druch OPNsense eingerichtet worden. Die IP für OPNsense ebenfalls. Jetzt habe ich Proxmox so eingerichtet, dass IP 10.0.0.2 für Proxmox dient und in Proxmox habe ich das Gateway 10.0.0.1 eingestellt. 

Sollte passen.

Add a domain override for the remote domain to Unbound and point it to the remote DNS server.

Remember that you have to use the FQN to access hosts on the remote site.

Hallo,

ich kenne das OpenWAF Plugin leider auch (noch) nicht.
Aber mir fällt dazu ein, du könntest auf die Firewall Regeln vergessen haben, die Port 80, 443 am WAN auf die WAN IP erlaubt.

Das Port Forwarding erstellt ja praktischerweise FW-Regeln automatisch. Nun musst du das aber explizit erlauben.

Auch denke ich, dass das Ding ein Log schreibt. Je nach dessen Einstellung müsste da ja der Zugriff ersichtlich sein.

Grüße

I am now playing with the thought of moving to the next step, which will include setting up wireguard to remotely fonnext into my home network. I think this requires putting my ISP's modem into "bridge" mode.

First of all, this requires that you get a public WAN IP from your ISP. If this is assigned to the modem, you can as well forward the used ports or all to OPNsense.
But get sure, that you get any, otherwise your network is not accessible from the internet.

I assume OPNsense does a decent job out of the box but I am still nervous so...

Yes, OPNsense is hardened out of the box. There is no incoming traffic permitted on the WAN.
So it's not less secure as your ISP router.

All traffic you want to pass in require a manually added rule on the WAN, e.g. to connect to the Wireguard server.

Best to start here: https://docs.opnsense.org/firewall.html

VPN: OpenVPN: Instances > "Static Keys" Tab

Hallo,

1.  Ist das so korrekt? Ich bin mir nicht sicher, ob die Darstellung des Netzwerkaufbaus so richtig ist. Besonders die Frage, wie ich über  das LAN-Netzwerk, das durch OPNsense verwaltet            wird, auf Proxmox zugreife, um weitere VMs zu erstellen, beschäftigt mich.
  2.  NIC für Proxmox reservieren? Sollte ich einen NIC für Proxmox als Worst-Case-Szenario freihalten? Falls ja, wie sollte ich das am besten konfigurieren?

Wenn du das ganze zuhause stehen hast, ist das okay so. Proxmox kann die durchgereichten SFP NICs nicht nutzen und braucht dann natürlich einen eigenen Anschluss von außen.

Ich nehme an, du würdest am vmbr0 VLANs betreiben, dann das entsprechende Netz (LAN) für Proxmox an einem Switch-Port herausführen und den Host daran anschließen.

Aber erstmals solltest du dich informieren, ob die SFPs auch in FreeBSD ordentlich laufen. Hier wäre die passende Quelle: FreeBSD 14.3 Hardware Notes

4.  SFP+ Port durchreichen? Macht es in meinem Setup Sinn, den SFP+ Port durchzureichen, oder gibt es eine bessere Lösung, um das zu integrieren?

Du kannst es auch mit Linux-Bridges auf Proxmox oder mit Open vSwitches lösen. Dann eben Proxmox nur auf der LAN Bridge eine IP vergeben.

Was da besser ist, hängt davon ab, wie gut die SFPs in der jeweiligen Umgebung unterstützt werden. Wenn du sie in Proxmox einbindest, kommen eben Linux-Treiber zum Einsatz.

IP-Bereich bei der Proxmox-Installation: Wenn ich Proxmox neu installiere, ohne einen externen Anschluss zu haben, welcher IP-Adressbereich wäre dann der sinnvollste, den ich für die Installation festlegen sollte?

Such dir einen aus.
OPNsene verwendet standardmäßig 192.168.1.1/24 am LAN. Aber das würde ich ohnehin nicht beibehalten. Das 10/8er Netz bietet wohl ausreichend Platz.

Die Frage ist nun: Ist das bereits ein sauberer Ansatz oder eher eine Quick-and-Dirty-Lösung?

Dass Proxmox im LAN liegt?
Wenn das LAN eine vertrauenswürdig Subnetz ist, ist das in Ordnung.

Proxmox sollte die OPNsense LAN IP als Gateway nutzen und keine IP auf einem anderen Interface haben.

Was das SFP-Modul betrifft – wenn ich es richtig verstanden habe, kann die zugewiesene Schnittstelle nicht gleichzeitig von anderen VMs genutzt werden?

Richtig. Auch das müsstest du von außen wieder über eine andere NIC verbinden.

Ich betreibe meine pfSense seit Jahren virtualisert auf KVM, LAN auf einer Linux-Bridge, auf der der Host eine IP hat, um darauf zuzugreifen. Das liegt dann ebenso im LAN, wie andere Geräte, die extern angeschlossen sind. Da gibt es kein Problem mit Zugriff. Die Firewall muss dazu ja nicht laufen.
Einzig den Proxmox solltest du im Griff haben. Wenn das nicht läuft, gibt es auch kein Internet im Haus. Meine Wartung mache ich halt, wenn die anderen schlafen (sollten).