Heimnetzwerk Ausbau/Verbesserung (Firewall, Netzsegmentierung)

[Zero_Official]

Wobei der TE will ja Proxmox drauf laufen zu lassen -1 Port

 

[Hammelkoppter]

Also der TE will sein Netz unterteilen um z.B. Mgmt Zugänge usw. abzusichern. Und dann werden hier L2(+)/L3 Switches als zentrale Routing Instanz angeführt. Vielleicht kann man ja ACLs auf dem Switch anlegen, aber ich stelle mir das jedoch etwas unkomfortabel vor (keine Objekte, nur stateless, ggf. fehlende Funktionen wie DHCP relay oder oder oder)

Warum soll der TE sich dann noch ne OpnSense hinstellen wenn sowieso alles am Switch geroutet wird. Da tut's dann auch ne Fritte oder was auch immer die das Nat und die Einwahl übernimmt.

Wenn schon Segmentieren (in diesem kleinen Umfeld) dann über ne Firewall. Ob er das jetzt virtuell oder als Baremetal macht muss er halt entscheiden. Man kann ja erstmal virtuell anfangen und wenn die Performance halt Mist ist, zieht man die Sense halt um. Sehe da erstmal kein Problem. kommt bei der Sense halt auch stark drauf an, welche zusätzlichen Services man laufen lässt.

 

[XXXBold]

Hallo zusammen und danke für die Inputs!

Habe mir nun folgende HW angeschafft:

• 1x TP-SG2016P als "Core" Switch mit POE
• 1x TP-SG116E
• 1x Unifi U6+ Acces Point (mit openwrt)

Wenn ich das richtig sehe sind 3 Netzwerke + WAN geplant und der MiniPC hat 4x LAN, die 1:1 auf diese aufgeteilt werden sollen. Das heißt die *sense braucht gar keine VLANs, weil sie physisch in diesen Netzwerken vertreten ist.

Doch, sind jetzt doch mehr Netzwerke (.100 LANManagement, .200 LANPrivate, .300 LANGuest, .1000 LANServer). Mit VLANs kann ich bei Bedarf auch noch weitere hinzufügen. Ausserdem funktioniert auf dem MiniPC ein RJ45 Port leider scheinbar nur mit 100Mbits, habe jetzt das lokale Management darüber laufen (Proxmox etc.)
Siehe hier falls da wer vlt ne Lösung weiss: https://forum.proxmox.com/threads/c...intel-i226-v-wrong-speed-on-eth1-port.147918/

Also der TE will sein Netz unterteilen um z.B. Mgmt Zugänge usw. abzusichern. Und dann werden hier L2(+)/L3 Switches als zentrale Routing Instanz angeführt. Vielleicht kann man ja ACLs auf dem Switch anlegen, aber ich stelle mir das jedoch etwas unkomfortabel vor (keine Objekte, nur stateless, ggf. fehlende Funktionen wie DHCP relay oder oder oder)

Naja, ich schaue mir die ganzen Features sicher mal an, am Anfang solls einfach mal laufen (und natürlich soweit sicher sein). Denke es ist sicher nützlich, dass ein Switch solche Sachen kann.

Warum soll der TE sich dann noch ne OpnSense hinstellen wenn sowieso alles am Switch geroutet wird. Da tut's dann auch ne Fritte oder was auch immer die das Nat und die Einwahl übernimmt.

Naja bisschen mehr soll die opnSense dann schon noch machen, aktuell denke ich da an:

• Wireguard VPN
• Generelle Firewallregeln (WAN/LAN)

Vorallem habe ich durch die HW und das System noch Möglichkeiten für weitere Services (zenarmor, werbeblocker, ...)

 

[XXXBold]

Okay, melde mich hier nochmal, hab etwas probleme mit der Konfiguration der VLANs. Funktioniert leider noch nicht wie geplant (siehe unten für meine Fragen)

Folgende Netzwerke sind definiert (In opnSense und auf den Switchen) (802.1q)

• VLAN 1: System VLAN (für untagged traffic, wird nur zum testen verwendet, und für direkten Zugang)
• VLAN 100: LANManagement (10.4.8.0 / 24) mit DHCP-Server auf der opnSense
• VLAN 200: LANPrivate (192.168.17.0 / 24) mit DHCP-Server auf der opnSense
  • Von diesem VLAN sollte auf LANServer zugegriffen werden können, aber nicht umgekehrt!
• VLAN 300: LANGuest (192.168.20.0 / 24) mit DHCP-Server auf der opnSense
  • Von diesem VLAN sollte e.v. auf LANServer zugegriffen werden können, aber nicht umgekehrt!
• VLAN 1000: LANServer (10.8.16.0 / 24) mit DHCP-Server auf der opnSense

Screenshot der Proxmox-Netzwerke:

Und der opnSense VM in Proxmox:

Interfaces in opnSense:

• LANManagementLocal (10.4.7.1/24, nur für lokalen, direkten Zugang)
• LANManagement (10.4.8.1)
• LANPrivate (192.168.17.1)
• LANGuest (192.168.20.1)
• LANServer (10.8.16.1)

Hier die Zuweisungen unter opnSense:

Die Gateways unter opnSense (bin mir nicht sicher, obs die braucht?):

Die VLAN Config aufm SG2016P:

Folgende Fragen:

Ich kann innerhalb der eigenen VLANs pingen.
In andere allerdings nicht, ausser auf deren GW: Beispiel, von der IP 192.168.17.100 funktioniert auf 10.8.16.1 (also das opnSense Interface) aber nicht auf andere IPs im selben Netz. Ich sehe dabei auf der Firewall in der opnSense keine Einträge (Log->Liveview), d.h. daran dürfte es nicht scheitern (Hab die auch mal komplett deaktiviert zum testen, selbes Ergebnis).
Könnte ich das jetzt über den Switch regeln? Habe da n bisschen rumgespielt mit den Layer3 Features (Interface und Static Routing), aber habs nicht hingekriegt:

Hier die Regeln der FW: LANPrivate:

LANServer:

 

[Bob.Dig]

Die Gateways unter opnSense (bin mir nicht sicher, obs die braucht?):

Nein! Gateways legst Du nur für die OPNsense selbst an, also so was wie WAN, keinesfalls für jedes LAN. Insgesamt erscheint es mir ein ziemliches Chaos zu sein. Lieber klein anfangen, statt alles auf einmal lernen/machen zu wollen.

 

[Raijin]

Die Gateways unter opnSense (bin mir nicht sicher, obs die braucht?):

Ein Gateway definiert ein anderes System, welches in ein anderes Subnetz führt. Am WAN eines Routers wäre dies zB der Provider bzw. dessen Gateway für die Kunden. Am LAN hat dieser Router aber kein Gateway, weil ja alles, was nicht im lokalen Subnetz liegt, zum WAN-Gateway gehen soll, denn das WAN-Gateway weiß wo's lang geht.

Die Clients im lokalen Netzwerk haben wiederum den Router als Gateway, weil dieser eben weiß wo's lang geht.

So sollte es auch in deinem Fall sein. Am WAN muss dein InternetRouter als Gateway konfiguriert werden, die übrigen Schnittstellen brauchen kein Gateway. Nur dann, wenn du zB das Server-Netz hinter einem weiteren Router isolierst, müsstest du am dorthin führenden LAN-Port ein Gateway in eben dieses Subnetz setzen, dann aber mit einer statischen Route und nicht als Standard-Gateway.

Ich kann innerhalb der eigenen VLANs pingen.
In andere allerdings nicht, ausser auf deren GW: Beispiel, von der IP 192.168.17.100 funktioniert auf 10.8.16.1 (also das opnSense Interface) aber nicht auf andere IPs im selben Netz.

Das kann daran liegen, dass ein Router bzw. OPNsense hier seine eigene IP-Adresse (auf einem anderen Interface) erkennt und dann antwortet, obwohl der Zugriff ins andere Subnetz blockiert wird. Gemäß Firewall routet er ja streng genommen nicht, sondern antwortet, weil er direkt angesprochen wird.

Wenn der Router aber tatsächlich zu einem anderen Ziel routen soll, muss die Firewall das auch zulassen.

Aber nicht nur das. Die Firewall muss natürlich auch die Antworten des Ziels erlauben. Man darf also dem Server-Netz den Weg ins Client-Netz nicht vollständig blocken, sondern muss Antwortpakete weiterleiten. Dies regelt man normalerweise über die connection states. Derer gibt es vier:

NEW : Verbindungsanfrage, das 1. Paket einer Verbindung (TCP SYN)
ESTABLISHED: Antworten auf eine akzeptierte Anfrage (TCP SYN-ACK und alle anderen Antworten)
RELATED: Pakete von artverwandten Verbindungen. zB bei FTP mit der Command und Data-Verbindung.
INVALID: Ungefragte/unerwartete Pakete, zB SYN-ACKs ohne dazugehöriges SYN.

Deswegen beinhaltet eine DMZ-Firewall meist eine "allow established/related" Regel, die auf besagte Antwort-Pakete triggert und nur diese zulässt, obwohl der sonstige Zugriff ins andere Subnetz (inkl. NEW) eigentlich geblockt wird.

Hinzu kommt, dass natürlich auch das Ziel selbst offen für eingehende Verbindungen sein muss. Diese kommen mit einer vermeintlich "fremden" Absender-IP beim Server an, nämlich eine IP aus dem Client-Netz. Die Server-Firewall muss dies zulassen.



Falls es bis hierhin immer noch nicht klappt, würde ich mal den Paketsniffer in OPNsense bemühen und die ein- und ausgehenden Pakete auf den beiden Schnittstellen sniffen. Dort solltest du eigentlich den Request des Clients auf der einen Schnittstelle rein- und auf der anderen rausgehen sehen. Gleiches gilt für die Bestätigung des Servers, nur eben andersherum. Je nachdem welche Pakete fehlen, siehst du wo es hakt. Wenn zB der Request korrekt zum Server-LAN rausgeht, aber kein Reply reinkommt, blockt womöglich die Server-Firewall selbst.

 

[XXXBold]

Nein! Gateways legst Du nur für die OPNsense selbst an, also so was wie WAN, keinesfalls für jedes LAN

Am LAN hat dieser Router aber kein Gateway, weil ja alles, was nicht im lokalen Subnetz liegt, zum WAN-Gateway gehen soll, denn das WAN-Gateway weiß wo's lang geht.

Okay okay verstanden, die Gateways sind entfernt, danke euch!

Wenn der Router aber tatsächlich zu einem anderen Ziel routen soll, muss die Firewall das auch zulassen.

Okay, habe jetzt mal testweise folgendes konfiguriert (Alles in+out erlaubt), habe aber immer teilweise dasselbe Problem:

Hinzu kommt, dass natürlich auch das Ziel selbst offen für eingehende Verbindungen sein muss. Diese kommen mit einer vermeintlich "fremden" Absender-IP beim Server an, nämlich eine IP aus dem Client-Netz. Die Server-Firewall muss dies zulassen.

Das müsste eigentlich gehen, resp. wie prüfe ich das (aktuell hab ich zum Test meinen Desktop mit 1x Ethernet vom Mainboard und 2 USB-Ethernet Schnittstellen und nen Laptop mit 1x Ethernet an den Switch angeschlossen (Beide Linux Mint 21), beide Firewalls sind aus)
Hier ip a vom Desktop:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether b4:2e:99:94:2b:15 brd ff:ff:ff:ff:ff:ff
    inet 192.168.17.100/24 brd 192.168.17.255 scope global dynamic noprefixroute enp4s0
       valid_lft 3988sec preferred_lft 3988sec
    inet6 fe80::b62e:99ff:fe94:2b15/64 scope link
       valid_lft forever preferred_lft forever
3: enx000acd44c694: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0a:cd:44:c6:94 brd ff:ff:ff:ff:ff:ff
    inet 10.8.16.100/24 brd 10.8.16.255 scope global dynamic noprefixroute enx000acd44c694
       valid_lft 3915sec preferred_lft 3915sec
4: enx000acd44c5cc: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0a:cd:44:c5:cc brd ff:ff:ff:ff:ff:ff
    inet 10.4.8.100/24 brd 10.4.8.255 scope global dynamic noprefixroute enx000acd44c5cc
       valid_lft 2269sec preferred_lft 2269sec
    inet6 fe80::20a:cdff:fe44:c5cc/64 scope link
       valid_lft forever preferred_lft forever

Der Laptop hat per DHCP die IP 192.168.17.101 (LANPrivate)

Ping vom Laptop nach LANPrivate geht (ging auch vorher), neu mit den Regeln gehts auch nach 10.8.16.100 (umgekehrt auch, macht auch sinn da alles erlaubt ist).
Vom Desktop aus geht aber "ping -I enp4s0 10.8.16.100" nicht. Liegt das daran, dass das Ziel wieder derselbe PC ist?

Insgesamt erscheint es mir ein ziemliches Chaos zu sein. Lieber klein anfangen, statt alles auf einmal lernen/machen zu wollen.

Was genau meinst du? Das einzige was mir wirklich kompliziert erscheint (abgesehen davon, dass es nicht geht^^) ist das Routen über den Switch.

Generell muss ja auch nicht alles von Anfang an gehen. Dachte ich staffel das ganze grob ungefährt so:

1. Kommunikation innerhalb eigenes Netzwerks (VLAN) möglich (geht)
2. Internet/WAN zugriff für Clients (geht)
3. Kommunikation zwischen den einzelnen VLANs, primär wichtig LANPrivate->LANServer (you are here)
   1. Wenn das hier geht, kann ich die installation im Heimnetzwerk vornehmen, muss noch nicht besonders sicher sein oder perfekt funktionieren, aber hier aufm Tisch alles testen ist n bisschen mühsam (Hängt sowieso alles noch hinter dem aktuellen Router, daher wird die Sicherheit nicht gefärdet)
4. 3., aber mit sinnvollen Regeln beschränkt (d.h. sauber, nicht wie aktuell im Test mit Holzhammermethode alles erlauben)
5. Weitere Kommunikation zwischen VLANs
6. Wireguard VPN für bestimmte VLANs für Zugriff übers Internet
7. Weitere Absicherung der Firewall
8. ...

Mal ein herzliches danke zwischendurch an alle, die hier helfen und gute Inputs geben! Ich weiss das zu schätzen, ist alles andere als selbstverständlich.

 

[Raijin]

Das müsste eigentlich gehen, resp. wie prüfe ich das (aktuell hab ich zum Test meinen Desktop mit 1x Ethernet vom Mainboard und 2 USB-Ethernet Schnittstellen und nen Laptop mit 1x Ethernet an den Switch angeschlossen (Beide Linux Mint 21), beide Firewalls sind aus)

Naja, das prüft man eben indem man sich die lokalen Firewall-Regeln des Servers anschaut. Unter Linux ist das in der Regel iptables oder nftables bzw. ein Frontend dessen, zB ufw. Wie gesagt, erstmal solltest du in OPNsense die Pakete cappen und gucken was von wo nach wo und wo nicht geht. Wenn der connection request OPNsense sauber am Server-LAN verlässt, vom Server aber keine Antwort kommt, ist mit hoher Wahrscheinlichkeit irgendwas am Server nicht in Ordnung, mutmaßlich eben an dessen Firewall. Aber auch der angesprochene Dienst selbst kann Regeln in seiner Konfiguration enthalten, die Verbindungen aus fremden Subnetzen ablehnen.

Dir bleibt nichts anderes übrig als mit tcpdump, WireShark oder ggfs eingebauten Capture-Funktionen den Paketfluss im Detail zu untersuchen. Durch scharfes Hinsehen und blindes Rumprobieren wird das nichts, weil du ggfs am falschen System rumbastelst, zB wenn der Client den Request gar nicht losschickt, du aber am Server rumdokterst. Also capture in OPNsense machen, gucken und anschließend ggfs am Client oder am Server mit tcpdump mitschneiden.

Vom Desktop aus geht aber "ping -I enp4s0 10.8.16.100" nicht. Liegt das daran, dass das Ziel wieder derselbe PC ist?

Möglich, ja. Solche Tests sind auch nur bedingt zielführend, weil sie keinen sinnvollen Anwendungsfall darstellen und sich ggfs anders verhalten als es in einem realen Szenario der Fall wäre. Wenn du Pings zwischen verschiedenen Subnetzen testen möchtest, mach das mit zwei autarken Systemen, aber nicht am selben Gerät von einer zur anderen Schnittstelle pingen.

 

[Zero_Official]

Auf die Frage oben was nicht geht...
wenn der Switch kein Vlan routet liegt es am Gateway.
Es gibt 2 Wege:
1 - Opnsense Routet intervlan> gateway Opnsense IP's
2- Switch Routet intervlan> Gateway Switch IP's.

Fall 1 Rules auf der Sense, Fall 2 ACL's auf dem Switch um abzusichern.

ich habe zb extra Vlan nur für WAN (default Gateway) als utag und andere Vlans ALS tag drauf beim Switch und Router.
dies erleichtert ACL Einstellung.

Also die VM Sense intervlan routen lassen halte ich blöde idee.



Die Regeln auf der Sense können zb. so aussehen:

 

[XXXBold]

So, das ganze läuft nun mal einigermassen, werde das mal einige Wochen so lassen und schauen obs damit Probleme gibt, bevor ich weitere Konfigurationen vornehme.

Aktuell siehts so aus:

• Netze können untereinander kommuniezieren wie geschünscht.
• Zugang von extern via Wireguard funktioniert (LANManagement + LANServer)
• Performance ist gut bei geringer CPU-Last (500/500 via Speedtest möglich, musste da ein wenig mit den Interfaceoptionen herumspielen...)
• LibreElec/Kodi scheint auch zu laufen, wurde aber noch nicht in der Praxis verwendet. Aktuell funktioniert da wohl die Hardwarebeschleunigung nicht korrekt, für 1080p scheints aber OK zu sein per CPU.

Möglich, ja. Solche Tests sind auch nur bedingt zielführend, weil sie keinen sinnvollen Anwendungsfall darstellen und sich ggfs anders verhalten als es in einem realen Szenario der Fall wäre. Wenn du Pings zwischen verschiedenen Subnetzen testen möchtest, mach das mit zwei autarken Systemen, aber nicht am selben Gerät von einer zur anderen Schnittstelle pingen.

Okay, habe gemerkt dass das wohl für einige der initialen Probleme verantwortlich war... mit unterschiedlicher Hardware hats dann deutlich besser funktioniert^^

wenn der Switch kein Vlan routet liegt es am Gateway.
Es gibt 2 Wege:
1 - Opnsense Routet intervlan> gateway Opnsense IP's
2- Switch Routet intervlan> Gateway Switch IP's.

Aktuell macht jetzt die opnSense alles was mit Routing etc. zu tun hat, will das auch erstmal so lassen und testen, wie es sich verhält.

Melde mich hier nochmal, wenns weitergeht.