Setup VLANs (vor allem für 2 WLANs)?

[underclocker2k4]

Siehe EDIT.

Beitrag automatisch zusammengeführt: Dienstag um 14:35

"Block alles nach RFC_1918" wäre das eine "doppelte Negation", wie Du sie hier ausdenkst. Glaube aber kaum, dass die Sense daraus ein "ist zweimal geblockt, ich lass das jetzt durch" machen würde.

Block RFC1918 ist NICHT die doppelte Negation, sondern die direkte Ansprache. (siehe oben)
Negation der Negation hat nichts mit 2x Block = erlauben zu tun. Letzteres (2x deny=allow) funktioniert bei FWs grundsätzlich nicht, da nach dem ersten Block die Paketbearbeitung abgeschlossen ist.

Und wer sagt Dir, dass jemand nicht Ranges aus 192.168.0.0/16 und 10.0.0.0/8 zusammen nutzt? Macht das nicht auch eine Fritzbox für Gäste WLAN? Finde die Idee nicht mal so abwegig.

Ich habe doch geschrieben, dass das 192.168.0.0/16 als Beispiel dient. Ich kann dir jetzt Netzgruppen bauen, die 10k Netze beinhalten. Das ist ein akademisches Spiel und trägt nichts zum Thema bei.

EDIT:
Und nur weil es im Netz diese Notation gibt, heißt das nicht, dass sie gut ist.
Wenn du mal ne Firewall mit 4-5stelligem Regelset hast, weiß du, warum es klare und strikte Notationen gibt.
Nicht alles was technisch funktioniert, ist auch sinnvoll im Einsatz. Das gilt insbesondere für Firewallrulesets.
Besonders dann nicht, wenn das Regelwerk lebt. Da wundert man sich nämlich, warum ne Regel nicht greift.
Der Grund ist dann in der Regel, weil einer weiter vorne mal "kreativ" war.

2ndEDIT:
Man füllt ein Firewallregelset in der Regel wie folgt:
Verbieten Firewall:
1. erlaube 1
2. erlaube 2
3. erlaube 3
4. verbiete alles/den Rest

Erlauben Firewall:
1. verbiete 1
2. verbiete 2
3. verbiete 3
4. erlaube alles/den Rest

 

[sch4kal]

Solange die Firewall nicht invers arbeitet und das tut keine, ist immer alles erlaubt und man stellt eigentlich nur Verbote ein.
Eine Firewall ist ohne Regeln erstmal ein Router/Switch und sonst nichts. Per default ist da alles erlaubt,bzw. nichts verboten.

Das ist falsch. Sowohl Juniper SRX (bzw. generell in Junos), als auch Fortinets haben eine, zumeist unsichtbare, oder nicht direkt sichtbare, deny any default Regel.

 

[besterino]

Ich hab das jedenfalls anders dargestellt: Zugriff auf die VLANs ist aktiv geblockt und die Regel ist auch als solche („Block“) angelegt.

Allerdings ist zumindest bei der pfsense so, dass die nirgends irgendwas routet. Also insbesondere nicht zwischen VLANs und auch nicht zwischen VLAN/LAN und WAN. Damit also irgendwas über das Subnetz hinaus „raus“ kommt, braucht es eine Allow-Regel. Nach meinem Verständnis ergibt das eine grobe Reihenfolge:

1. Erlaube einzelne Hosts usw.
2. Erlaube Hostgruppen oder einzelne Subnetze
3. Verbiete alle zu schützenden Subnetze (die dann auch 1. oder 2. enthalten können) - bei mir synonym mit allen VLANs
4. Erlaube Internet

Auch bei mir ist „Erlaube Internet“ de facto gleichbedeutend mit „Allow !VLAN-Subnetze“, weil ich noch nicht geschnallt habe, wie ich „Internet“ anders als !VLAN-Subnetze / positiv in der pfsense ausdrücken könnte.

EDIT & Nachtrag: meins ist im Prinzip ne Variante von @underclocker2k4 „Erlauben-Notation“, weil ich vor den globalen Verboten halt noch Einzel-Ausnahmen von dem Verboten brauche, die sonst bei 4. „erlaube Rest“ nicht mehr zum Einsatz kämen.
Beispiel: Server-VLAN global verboten. File-Server für Host XYZ im Server-VLAN soll aber erreichbar sein. Nun könnte ich natürlich die Verbote so setzen, dass nur der Fileserver übrig bleibt, aber da werde ich ja wahnsinnig…

 

[underclocker2k4]

Das ist falsch. Sowohl Juniper SRX (bzw. generell in Junos), als auch Fortinets haben eine, zumeist unsichtbare, oder nicht direkt sichtbare, deny any default Regel.

Also habe ich doch recht.
Wenn es unsichtbar/nicht direkt sichtbar ist, dann ist es also doch da. Sonst wäre es nicht unsichtbar, sondern einfach nicht da.

Auch bei mir ist „Erlaube Internet“ de facto gleichbedeutend mit „Allow !VLAN-Subnetze“, weil ich noch nicht geschnallt habe, wie ich „Internet“ anders als !VLAN-Subnetze / positiv in der pfsense ausdrücken könnte.

0.0.0.0/0 sind alle IP-Adresse auf der Welt.

1. Verbiete X (192.168.0.10/32)
2. Verbiete Y (192.168.10.95/32)
3. Verbiete Z (192.168.20.0/24)
4. Erlaube die Welt. (0.0.0.0/0)

Verbiete Host X, verbiete Host Y, verbiete Netz Z, erlaube sämtliche andere Kommunikation. (sowohl intern als auch extern)

 

[besterino]

Na gut, aber 0.0.0.0 ist doch dann synonym zu !VLANs - quasi bisserl Schutz mehr, wenn ich mal die Deny-Regel verliere (insb. aus Dummheit).

 

[underclocker2k4]

Wie gesagt, die Negation (!VLAN) wirkt ja. Informatik ist am Ende auch nur Mathematik. Hier im Beispiel die Mengenlehre. (man kann jetzt noch mit Teil der Menge und nicht Teil der Menge anfangen...)
Und eben weil das so "kompliziert" ist, nutzt man einfache und auf den ersten Blick, besonders für andere, klare Notationen.

 

[sch4kal]

Ich hab das jedenfalls anders dargestellt: Zugriff auf die VLANs ist aktiv geblockt und die Regel ist auch als solche („Block“) angelegt.

Sieht bei mir so aus:

Besser Reject (intern), damit die Endgeräte auch ein ICMP Unreachable bekommen und nicht unnötig auf Antwort warten. Aus dem WAN natürlich Block.

Allerdings ist zumindest bei der pfsense so, dass die nirgends irgendwas routet.

Doch, routen schon, nur die pf Firewall blockt per default auch alles, sofern es unten keine "Erlaube alles" Regel gibt.

Nach meinem Verständnis ergibt das eine grobe Reihenfolge:

1. Erlaube einzelne Hosts usw.
2. Erlaube Hostgruppen oder einzelne Subnetze
3. Verbiete alle zu schützenden Subnetze (die dann auch 1. oder 2. enthalten können) - bei mir synonym mit allen VLANs
4. Erlaube Internet

Das wäre eine gute Richtlinie. Wenn etwas "für alle" Richtung z.B. WAN gelten soll, kann man auch über Floatingrules nachdenken.

Auch bei mir ist „Erlaube Internet“ de facto gleichbedeutend mit „Allow !VLAN-Subnetze“, weil ich noch nicht geschnallt habe, wie ich „Internet“ anders als !VLAN-Subnetze / positiv in der pfsense ausdrücken könnte.

Das erreichst du, indem du das Gateway in der Regel festlegst bzw. bei pfSense nimmt er default immer die reguläre Routingtable. Wenn dort also vermutlich eine 0.0.0.0/0 Route Richtung deines Internetanschlusses existiert, dürfte das ausreichen, einfach nichts als Quelle anzugeben.

 

[BobbyD]

Besser das Video gucken.
Grundsätzlich hat UC2004 aber recht. Im professionellen Umfeld, wo ggf. verschieden Personen die selbe Firewall administrieren müssen, sind solche Invertierungen nicht gerne gesehen, hab ich mir sagen lassen. Zuhause geht das aber in Ordnung.
Die Sense ist übrigens Default Deny, das kann man auch nicht ändern.

Beitrag automatisch zusammengeführt: Dienstag um 15:16

Das erreichst du, indem du das Gateway in der Regel festlegst

Mit IPv6 funktioniert das meine ich nicht mehr, würde ich also eher nicht empfehlen, auch wenn ich es für IPv4 auch schon genutzt habe. Gewöhne es mir aber gerade ab.

Beitrag automatisch zusammengeführt: Dienstag um 15:30

So sieht das exemplarisch bei mir aus:

DNS und NTP werden zuvor über Gruppen-Regeln abgehandelt (hier nicht abgebildet).
reserved4 ist ein System-Alias in neueren pfSensen und GroupVSix eine Interface-Gruppe, in der ich alle vorhandenen IPv6-Interface (ULA/GUA) gruppiert habe.

 

[sch4kal]

Besser das Video gucken.

Der zeigt das auch nur mit einer Alias RFC1918 Regel. Kann man so auch machen, hat aber auch Nachteile. z.B. bei Renumbering von anderen Interfaces, oder beim Hinzufügen neuer VLAN Interfaces mit anderen RFC1918 Adressen. Da muss ich wieder mehr "Knöpfe" anfassen (und Hirnschmalz reinstecken, weil ich ja dann unter Umständen keine /8, /12 oder /16 Ranges mehr als Ganzes blocken kann), als (wie du ja auch im Screenshot) "$IF address" und "$IF subnet" anzugeben.

 

[BobbyD]

weil ich ja dann unter Umständen keine /8, /12 oder /16 Ranges mehr als Ganzes blocken kann

Doch, die Ausnahmen definierst Du ja jeweils als Regel davor (bei TS nicht vorhanden, wäre im Bild dann die zweite Regel).

Bei dynamischem IPv6 geht das leider nicht mehr (es sei denn, man nutzt nur ULA mit NPt). Daher muss ich die Gruppe (siehe Edit) "händisch" pflegen. Aufwand hält sich in Grenzen, da ich IPv6 nur sehr bedacht einsetze.

 

[tar]

Das sieht zumindest wunderbar hässlich aus 😄

 

[besterino]

Wasn das fürn Kommentar, vor allem wäre es erhellend, worauf sich "Das" eigentlich bezieht.

 

[tar]

Das ist meine abwertende Meinung zu dieser visuell furchtbar unübersichtlichen Firewall bzw. der Anwendung des "Invert Match". Man sieht eben überhaupt nicht, was da passiert. Was sich hinter "_reserved4_" und "GroupVSix networks" verbirgt, weiß allein das Hirn des Admins. Das Schlimmste dabei: es ist einfach nur Tippfaulheit, weil man für ein Gäste-WLAN halt keine 5 Block-Regeln für all die anderen internen VLANs und dann eine Pass-Regel fürs Internet anlegen möchte, erledigt der invertierte Alias, den kein Schwein auf Anhieb lesbar versteht, das alles in einer Zeile. Das mag wunderbar kurz und effizient sein - es bleibt ein schierer Albtraum bei der Fehlersuche

 

[AliManali]

Naja, all die Firewalls mit denen ich zu tun hatte, sind ein Albtraum für den armen Supporter, der sich nicht damit auskennt. Dachte ich mir auch erst, als ich von Endian/Zyxel und weiteren auf die OPNsense umgestiegen bin. Man gewöhnt sich an (fast) alles...

 

[BobbyD]

weiß allein das Hirn des Admins. Das Schlimmste dabei: es ist einfach nur Tippfaulheit

Das erste ist wie gesagt ein System-Alias, den hat jede aktuelle pfSense(+). Außerdem habe ich fast 40 Firewall-"Interfaces" (WANs, LANs, VLANs, VPN-Clients und -Server). Es in meinem Falle anders zu machen, wäre einfach nur dämlich.

Beitrag automatisch zusammengeführt: Mittwoch um 11:29

Ich habe mal die Berechtigung für ausgehendes IPv6 entfernt und dem LXC gesagt, er soll IPv4 bevorzugen. Wenn TeamSpeak3 das nicht noch stört, dann wäre das ok, denn ich "brauche" firewalltechnisch IPv6 nur eingehend. Und gerade gelesen, dass der Server ausgehend wohl nur Port 443 voraussetzt, also reichen die Webports für das und Debian-Updates.

Aber irgendwie schweifen wir ab.

 

[tar]

Dann bitte auch erwähnen, das sich LANcom jede Menge Features extra bezahlen lässt, wie z.B. pro VPN Client um die 100 Euro. Wenn man im Business Umfeld dann auch die Anwendung dafür hat, mag das gerechtfertigt sein, fürs HomeLab wird das keiner Ausgeben wollen.

Ich habe heute mal testweise VPN via WireGuard auf dem LANCOM-Router eingerichtet, weil ich zufälligerweise mal wieder den Plex-Docker angeworfen hatte und leidlich feststellte, dass die einen (neuerdings?) zur Kasse bitten wollen, wenn man seine eigenen Daten vom eigenen Server abspielen möchte, aber nicht im heimischen (W)LAN hockt bzw. das Ganze gar vom Smartphone versucht. Kurzerhand bot es sich halt an und - oh Wunder - es kostet nichts und funktioniert.

Also soll sich bspw. jemand vom Laptop von einem externen Netz (bspw. vom Hotel-WLAN aus) ins heimische Netz "einwählen" und dort den Plex-Docker (der auf dem Server läuft) mit einer "lokalen IP" aufrufen können. Der VPN-Tunnel soll die IP 10.0.250.10 bekommen. Der Router die zusätzliche IP 10.0.250.1 als VPN-Gateway. Das simuliert im Grunde ein VPN-Netzwerk 10.0.250.x - tatsächlich ist das aber kein wirkliches Netzwerk, weswegen wir das mit der "250" optisch deutlich von den restlichen lokalen Netzwerken/VLANs trennen. Der Server hat die lokale IP 10.0.5.10 und Plex ist im LAN über 10.0.5.10:32400 erreichbar.

Man kann das ganze in LANCOM nun wie folgt einstellen. Erstmal den VPN-Tunnel erzeugen:

• VPN -> WireGuard
  • "WireGuard aktiviert" aktivieren (wer hätte dies gedacht)
  • Verbindungs-Liste -> Hinzufügen
    • Verbindung: VPN-BERND (halt was sprechendes)
    • Verbindung aktiv: Ei ja
    • Immer aktiv: nein
    • Lokaler Port: 51.820
    • Remote Gateway: leer lassen
    • Remote Port: 51.820
    • Routing Tag: 0
    • Local Private Key: auf Schlüssel erzeugen klicken
    • Peer Private Key: auf Schlüssel erzeugen klicken
    • Preshared Key: auf Schlüssel erzeugen klicken
    • IPv6-Profil: DEFAULT oder INTERNET oder was man halt so nutzt
    • Persistent Keepalive: 25
    • Kommentar: die Kalorien der letzten Mahlzeit
    • via "Peer Konfig erzeugen" kann man sich direkt die Importdaten für den WireGuard-Client erzeugen lassen
      • Adress: 10.0.250.10/32 (die eigene VPN-IP)
      • DNS: 10.0.250.1 (der VPN-Gateway)
      • Allowed IPs: 10.0.5.10/32 (da wollen wir hin), 10.0.250.1/32 (der VPN-Gateway, optional ginge auch 10.0.250.0/24 - man hätte den Gateway gleich mit dabei und könnte andere VPNs im selben IP-Bereich "netzwerkartig" anpingen oder dergleichen, muss das Ganze dann aber auch durchrouten)
      • Endpoint: <deineÖffentlichZuErreichendeIP>:51820 (bspw. via DuckDNS einrichten und hier dann eben "mytollesubdomain.duckdns.org:51820" setzen)
      • Persistent Keepalive: 25

Wenn man das alles eingegeben hat, sollte oben der Text auftauchen (kann man in einer .conf-Datei ablegen und im WireGuard-Client auf dem Laptop dann einfach importieren/laden - oder am Smartphone den QR-Code scannen).

Damit hätten wir die Verbindung (und theoretisch auch den Client fertig), aber da fehlt noch bissl was. Wir brauchen einen VPN-Gateway. Dafür erzeugen wir eine weitere Adresse für den Router selbst

• IPv4 -> Allgemein -> Loopback-Adressen -> Hinzufügen
  • Name: VPN-GATEWAY
  • IP-Adresse: 10.0.250.1 (das ist die weitere Adresse, die der Router nun selbst hat)
  • Routing-Tag: 0

Diese Adresse vom Router müssen wir dem VPN-Tunnel nun noch mitteilen.

• Kommunikation -> Protokolle -> IP-Parameter -> Hinzufügen
  • Gegenstelle: VPN-BERND (identisch zur WireGuard-Verbindung, kann man auch auswählen)
  • IP-Adresse: 10.0.250.1
  • Netzmaske: 255.255.255.255
  • Rest: auf 0.0.0.0 belassen

Dann müssen wir noch die (Rück-)Route festlegen, damit der Router weiß, wo er die (Antwort-)Pakete für den VPN-Tunnel hinschicken soll. Ohne diesen Eintrag landen sie im Nirvana.

• IP-Router -> Routing -> IPv4-Routing-Tabelle -> Hinzufügen
  • IP-Adresse: 10.0.250.10 (die von VPN-BERND)
  • Netzmaske: 255.255.255.255 (das beschränkt die Route auf diese eine IP)
  • Routing-Tag: 0 (wie üblich, wir keepen es simple und trennen hier keine Netze auf)
  • Schaltzustand: aktiviert
  • Router: VPN-BERND (genau hier in diesen VPN-Tunnel sollen die Pakete für 10.0.250.10 ja hin)
  • RIP-Distanz: 0
  • IP-Maskierung: abgeschaltet (damit bleibt der Netzverkehr transparent)
  • Administrative Distanz: 0
  • Kommentar: "Schokobons sind eine vollwertige Mahlzeit"

Schließlich müssen wir den VPN-Tunnel noch in der Firewall berücksichtigen.

• Firewall/QoS -> IPv4-Regeln -> Hinzufügen
  • Regel 1: Erlaube VPN-BERND-IP zu ROUTER-VPN-IP: DNS (= 10.0.250.10 zu 10.0.250.1:53)
  • Regel 2: Erlaube VPN-BERND-IP zu SERVER-IP:PLEX (= 10.0.250.10 zu 10.0.5.10:32400)
  • optional Regel 3: Verbiete VPN-BERND-IP zu allem und logge das (grenzt das Logging von der BLOCK-ALL-Regel ab)

 

[BobbyD]

Das nenne ich mal eine hässliche Teil-Übersetzung und Beschreibung...

Kommentar: die Kalorien der letzten Mahlzeit

Mir hätte ja die Aussage gereicht: WireGuard komplett kostenlos nutzbar.