Zwei getrennte Netzwerke, drei Lösungsmöglichkeiten?
-
Danke JeGr für deine Antwort.
Ja, Version 1 ist Unwissen. Ich beschäftige mich erst jetzt mit VLANs. Daher wollte ich alle mir eingefallenen "Lösungen", ob nun falsch oder richtig, aufzählen. :-) Dann verwerfen wir Version 1 mal schnell. :-)
Nur zum besseren Verständniss für mich.
Bei Version 2 tagge ich Port 1 zum Switch und muss in pfSense auch die jeweiligen VLANs anlegen. Wenn ich nun im Switch die Ports 2-8 und 9-24 untagged konfiguriere, muss ich bei den WLAN-Access-Points keine VLAN IDs angeben. Wenn ich die Ports ebenfalls tagged verwenden würde, muss ich die VLAN IDs angeben. Bei Version 3 selbes Verhalten, allerdings "physisch" getrennt mit voll nutzbarer Bandbreite.
Die Netzwerke sollen komplett voneinander isoliert sein. Eine Kommunikation zwischen den Netzen ist nicht angedacht. Sie teilen sich nur die Internetleitung.
Daher würde ich, in der Hoffnung VLANs nun richtig verstanden zu haben, folgende Konfiguration wählen.
pfSense mit zwei NICs
NIC 1 = WAN
NIC 2 = in pfSense tagged VLAN 10 und 20
Switch Port 1 tagged VLAN 10 und 20
Switch Ports 2-8 VLAN 10 zugehörig, aber untagged
Switch Ports 9-24 VLAN 20 zugehörig, aber untagged
WLAN-Access-Point für Netzwerk 1 an Switch Port 2
WLAN-Access-Point für Netzwerk 2 an Switch Port 9
Die Access Points brauchen keine VLAN IDs, weil die Ports 2 und 9 untagged sind
Dann kann ich in pfSense die VLANs mit verschiedenen Netzbereichen konfigurieren, also VLAN 10 = 192.168.10.0/24 und VLAN 20 = 192.168.20.0/24So, hoffe ich hab's richtig verstanden.
Vielen Dank nochmal.
Viele Grüße,
KHR -
Ahoi ;)
Ich schreibe das mal ein wenig um:
pfSense mit 2 NICs:
- NIC1 -> Interface assigned as WAN
- NIC2 -> Interface NOT assigned
- pfSense / Interfaces / (assign) / Reiter VLAN:
- VLAN 10 auf NIC2 anlegen
- VLAN 20 auf NIC2 anlegen
- pfSense / Interfaces / (assign)
- VLAN10 on NIC2 -> Interface assigned as LAN10
- VLAN20 on NIC2 -> Interface assigned as LAN20
Switch:
- Port 1: Trunk mit tagged VLAN 10 und tagged VLAN 20
- Ports 2-8: untagged VLAN 10
- Ports 9-24: untagged VLAN 20
- WLAN APs an Ports 2 und 9 für entsprechende VLAN Zugehörigkeit
Netze würde ich genauso konfigurieren, dass du am IP Range irgendwo ablesen kannst, welches VLAN, so wie in deinem Beispiel.
Also: richtig verstanden, nur Nomenklatur ein wenig angepasst und geschrieben, wie du es sehr wahrscheinlich in den Produkten (pfsense / Switch) vorfinden wirst :)
Gruß
-
Moin,
sind die mit WLan zu versorgenden Bereiche räumlich getrennt oder überlappend? Wenn überlappend schmeiß ich mal Accesspoints mit Multi SSID in den Raum ;).
Der hier kann maximal 4 SSIDs abstrahlen: https://geizhals.de/ubiquiti-unifi-ap-ac-lite-uap-ac-lite-a1325765.html?hloc=at&hloc=de alternativ https://geizhals.de/ubiquiti-unifi-ap-ac-pro-uap-ac-pro-a1325749.html?hloc=at&hloc=de die Du dann per VLan ins richtige Netzsegment einbindest.
Nachteil: Die benötigen, zumindest für die Konfiguration, eine kostenlose Controllersoftware, Vorteil: Du kannst alle APs gleichzeitig konfigurieren 8)Nur so ein Gedanke, ich will nichts andere mehr, auch wenn ich jetzt eigentlich keine Controller Lösung mehr brauche da der AC Pro alles abdeckt was bisher mit teilweise 3 billigen APs versorgt wurde…
-teddy
-
Stimmt, schöner Einfall :D Hatte ich jetzt gar nicht im Kopf ;) Könnte man sich dann auch ggf. einen AP sparen oder eine bessere Abdeckung bekommen :D
-
Nochmal danke für die Antworten (und danke fürs anders schreiben). Dann bin ich ja glücklich, dass ich das mit den VLANs nun verstanden habe.
Ja, einer meiner WLAN-Router kann tatsächlich Multi-SSID. Dort kann ich auch VLAN-Zugehörigkeit konfigurieren. Ist ein Cisco RV110W. Ist eigentlich ne gute Idee. Dann spare ich mir einen AP und kann diesen dann als Bridge verwenden. Muss also nichts neu kaufen, außer dem Dual Port Intel NIC. :-)
Dann wieder, zum Verständnis, folgende Konfiguration:
pfSense mit 2 NICs:
- NIC1 -> Interface assigned as WAN
- NIC2 -> Interface NOT assigned
- pfSense / Interfaces / (assign) / Reiter VLAN:
- VLAN 10 auf NIC2 anlegen
- VLAN 20 auf NIC2 anlegen
- pfSense / Interfaces / (assign)
- VLAN10 on NIC2 -> Interface assigned as LAN10
- VLAN20 on NIC2 -> Interface assigned as LAN20
Switch:
- Port 1: Trunk mit tagged VLAN 10 und tagged VLAN 20
- Port 2: Trunk mit tagged VLAN 10 und tagged VLAN 20
- Ports 3-8: untagged VLAN 10
- Ports 9-24: untagged VLAN 20
**WLAN AP
- LAN 1 vom Router an Switch Port 2
- Im Router LAN 1 Trunk und tagged VLAN 10 und VLAN 20
- WLAN SSID Netzwerk 1 VLAN 10
- WLAN SSID Netzwerk 2 VLAN 20**
So richtig?
Viele Grüße,
KHR -
Je nach AP Konfiguration braucht der AP selbst natürlich auch noch eine IP entweder in VLAN10 oder 20 zum managen, aber im Prinzip sollte es so sein, ja :)
-
Vielen Dank für die Hilfe.
-
Hallo liebe Community,
sorry ich muss meinen Thread nochmal rauskramen. :-)
Das mit der VLAN-Verteilung hat soweit funktioniert. Allerdings werde ich aus den Firewall-Regeln nicht so ganz schlau.
Konfiguriert ist das System in pfSense wie folgt:
In pfSense unter Interfaces/VLANs- Interface em0, VLAN Tag 10
- Interface em0, VLAN Tag 20
In pfSense unter Interfaces/Interfaces Assignments
- Interface WAN, Networkport em1
- Interface VLAN10, Networkport VLAN10 on em0
- Interface VLAN20, Networkport VLAN20 on em0
- Interface LAN not assigned
Im 24Port Switch:
- LAN 1 Trunk und Tagged VLAN 10 und 20
- LAN 3 VLAN10
- LAN 4 VLAN20
LAN 1 vom Switch ist verbunden mit pfSense em0. LAN 3 mit Rechner 1 und LAN 4 mit Rechner 2.
(Diese Konfigruation dient mir als Test, um alles auszuprobieren, bevor ich das eigentliche pfSense System in Betrieb nehme).
Firewall-Regeln in pfSense:
Interface WAN:
1. Protocol: *
Source: RFC 1918 Networks
Port: *
Destination: *
Port: *
Gateway: *
Queue: *
Schedule:
Description: Block Private Networks2. Protocol: *
Source: Reserved, not assigned by IRNA
Port: *
Destination: *
Port: *
Gateway: *
Queue: *
Schedule:
Description: Block Bogon NetworksInterface VLAN10:
1. Action: Pass
Protocol: IPv4 *
Source: VLAN10 net
Port: *
Destination: VLAN10 net
Port: *
Gateway: *
Queue: none
Schedule:
Description: VLAN10 talks to VLAN102. Action: Pass
Protocol: IPv4 TCP
Source: VLAN10
Port: *
Destination: WAN net
Port: 80 (HTTP)
Gateway: *
Queue: none
Schedule:
Description: VLAN10 talks to Internet HTTP3. Action: Pass
Protocol: IPv4 TCP
Source: VLAN10
Port: *
Destination: WAN net
Port: 443 (HTTPS)
Gateway: *
Queue: none
Schedule:
Description: VLAN10 talks to Internet HTTPSInterface VLAN20 ist equivalent zu Interface VLAN10 konfiguriert.
Allerdings bekomme ich so keine Internetverbindung. Eine Internetverbindung bekomme ich nur, wenn ich bei der zweiten und dritten Rule bei Source und Destination "Any" wähle. Was aber ja wieder dazu führt, dass ich von VLAN10 auf VLAN20 und von VLAN20 auf VLAN10 zugreifen kann.
Ich hoffe ihr könnt mir sagen, wo mein Denkfehler ist. :-)
Außerdem ist mir aufgefallen, dass pfSense auf dem WAN Port ständig Traffic hat. Auch wenn außer pfSense und der 24Port Switch nichts verbunden ist. Also die beiden Rechner nicht eingeschaltet sind.
Vielen Dank nochmal und viele Grüße,
KHR -
Hi,
Description: VLAN10 talks to VLAN10
Wofür muss das Netz mit sich selbst reden?? :o
Description: VLAN10 talks to Internet HTTP
Description: VLAN10 talks to Internet HTTPSWarum nur die beiden? Brauchst du nur HTTP/HTTPS? Das wäre aber etwas wenig?
Ansonsten - es sei denn deine pfSense macht intern alles - würden mir da Regeln zu DNS, NTP, DHCP etc. fehlen, die würde dann glücklicherweise die Regel 1 mit abdecken, auch wenn sie sonst keinen Sinn macht. Korrekt wäre da eher, aus LAN net auf LAN address (also die sense) die Sachen freizugeben, die man haben möchte wie eben DHCP, DNS, NTP etc. und ggf. noch die Web Ports (wenn Management in VLAN10 erlaubt sein soll und das nicht eh schon von der Anti-Lockout Regel erledigt wird).Zudem hast du auf dem VLAN10 nirgends verboten, dass du mit VLAN20 reden darfst. Also klappt das natürlich auch (in Maßen) weiterhin. Wenn du die VLANs isolieren willst wäre sowas hier nötig:
- allow VLAN10_net to VLAN10_address mit Ports auf TCP/UDP Diensten die notwendig sind (siehe oben). Alternativ auch any protocol und any port wenn dir das egal ist. Dann sollte VLAN10 auch sauber DHCP, DNS, NTP und Co für Infrastruktur machen können
- BLOCK VLAN10_net to VLAN20_net
- allow VLAN10_net to any (internet) -> da kannst du proto any und port any machen wenn du alles abgehend erlauben willst oder ggf. einschränken auf http/s etc. mit einem Alias.
VLAN20 dann natürlich 1:1 anpassen.
-
Hallo JeGr,
und mal wieder vielen Dank für deine Antwort.
Description: VLAN10 talks to VLAN10
Wofür muss das Netz mit sich selbst reden?? :o
Wenn ich diese Regel nicht setze, kann ich beispielsweise nicht auf einen Fileserver zugreifen, der sich in diesem VLAN befindet. Zumindest bei meiner Teststellung.
Wenn ich die Interfaces VLAN10 und VLAN20 in den Regeln unangetastet lasse, also keine Regeln vergebe, kann ich in den jeweilinge VLANs nichts. Kein Rechner kann mit einem anderen komunizieren. Auch nicht auf Fileserver, das Web Interface von pfSense, usw. Daher die VLAN10 talks to VLAN10 Rule. Dann funktioniert das. Anders irgendwie nicht.
Ich glaube, ich habe noch oder wieder einige Denkfehler in meinem System. :-)
Was ich möchte ist, dass VLAN10 und VLAN20 sich eine Internetverbindung teilen, also mit dem WAN Port kommunizieren. Untereinander sollen VLAN10 und VLAN20 nicht kommunizieren können. Von außen soll keines der beiden VLANs erreichbar sein.
Kannst du, oder ihr, mit Tipps geben? Vielleicht auch gerne Literatur zu pfSense? Damit ich mich besser einlesen kann? Ich werd irgendwie aus dem Online Manual und den vielen Youtube Videos nicht schlau.
[EDIT]
Was meinst du mit "allow VLAN10_net to VLAN10_address"? Meinst du die IP-Adresse von PC1? Eigentlich sollen, außer der Fileserver, alle die IP-Adresse per DHCP erhalten.
[\EDIT]
[EDIT2]
Hab ich selbst rausgefunden. VLAN10_address ist die IP Adresse mit der das Interface VLAN10 konfiguriert ist. Also beispielsweise 192.168.10.1 wenn ich das im Wiki von pfSense richtig verstanden habe.Ich frag mich nun, was du mit allow VLAN10_net to any (internet) meinst. Was genau mit internet? Das WAN Interface? Oder wirklich zu "Any"?
[\EDIT2]Vielen Dank nochmal und viele Grüße,
KHR -
So, hab's nochmal überarbeitet.
Konfiguration ist jetzt folgende:
WAN Interface: Block Private Network, Block Bogon NetworkVLAN10 Interface:
1. Allow IPv4 * VLAN10 net Port * –> VLAN10 address Port *, Gateway *
2. Block IPv4 * VLAN10 net Port * --> VLAN20 net Port *, Gateway *
3. Allow IPv4 TCP VLAN10 net Port * --> * Port *, Gateway * (also: allow all auf IPv4 TCP)VLAN20 Interface:
wie VLAN10 Interface 1:1Habe Bilder beigefügt, wie die Konfiguration ist.
Prinzipiell läuft's so. Die VLANs können nicht untereinander kommunizieren. Internet habe ich an beiden VLANs.
Fragen hierzu: Könnte man bei Punkt 3. auch Allow Any VLAN10 Port * --> * Port *, Gateway * machen? Ist das ein Sicherheitsrisiko? Ich denke nicht, da ja von Seite des WAN Ports alles geblockt wird, was in die Firewall reinkommt. Oder sehe ich das falsch?
Ist o.g. Konfiguration sicher von Seite des Internets? Ich denke wiederum schon, weil ja von Seite des WAN Ports alles geblockt wird. Oder sehe ich das falsch?Außerdem interessiert mich noch der Traffic auf dem WAN Interface. Aufgefallen ist mir das, weil die ACT/LINK LED ständig blinkt. Hab auch auf den Traffic Graphs Traffic gesehen. Auch hier habe ich mal ein BIld der Traffic Graphs beigefügt (graph.png). Muss oder sollte ich mir wegen des ständigen Traffics auf dem WAN Interface Gedanken machen?
Ich hoffe, ihr bringt mal wieder Licht ins Dunkel. :-)
Vielen Dank und viele Grüße,
KHR
-
So mal kurz zu den Regeln:
Generell: es wird am Ende immer implizit ein "block any" auf jedem Interface geschehen. Somit wäre bspw. momentan auf dem WAN die beiden Regeln "nicht notwendig", diese werden aber über die Haken beim Interface automatisch gesetzt. Tut niemand weh UND verhindert, dass später - sollte man auf WAN tatsächlich was reinlassen wollen - irgendwas reinkommt, was komisch wäre.
WAN: sieht OK aus
VLAN10 + VLAN20: genau das hatte ich gemeint :) allerdings:Fragen hierzu: Könnte man bei Punkt 3. auch Allow Any VLAN10 Port * –> * Port *, Gateway * machen? Ist das ein Sicherheitsrisiko? Ich denke nicht, da ja von Seite des WAN Ports alles geblockt wird, was in die Firewall reinkommt. Oder sehe ich das falsch?
Genau das. Ich hatte auch mit ANY (Proto) gemeint. Du möchtest ja auch mal was im Internet anpingen o.ä. von einem PC, ergo muss auch UDP, ICMP etc. offen sein, sonst läuft da nix :) Nur TCP ist etwas "mutig" :)
Ist o.g. Konfiguration sicher von Seite des Internets? Ich denke wiederum schon, weil ja von Seite des WAN Ports alles geblockt wird. Oder sehe ich das falsch?
Siehe Kommentar zu WAN und Generell. Es kommt von außen eh nichts rein. Jede Gefahr wird somit also von innen verursacht, nicht von außen.
Muss oder sollte ich mir wegen des ständigen Traffics auf dem WAN Interface Gedanken machen?
Da keine Skala für WAN definiert ist, nehme ich an, dass es Bit/Sekunde oder Byte/Sekunde sind. Dann ist das zu vernachlässigen und in Ordnung. Das Internet ist kein stiller Ort. Nicht mehr. Es reden ständig irgendwelche Systeme übereinander und durcheinander. Das ist quasi dein Grundrauschen auf der Leitung. Du kannst es spaßeshalber mal mitschneiden, ist oftmals kein schöner Anblick ;)
Grüße
-
Hallo und mal wieder vielen vielen Dank für die Unterstützung! :-)
Dann hab ich's ja scheinbar noch noch verstanden. :-) Da ich über pfSense mehr erfahren möchte, werde ich mir warscheinlich das pfSense Buch kaufen (pfSense the definitive guide). Ist das zu empfehlen?
Das mit dem "Grundrauschen" ist einleuchtend, allerdings macht das mein Router von der Stange nicht. Zumindest blinkt dort nicht ständig die LED für WAN. Das hat mich einfach stutzig gemacht. Aber wenn du sagst, das wäre Grundrauchen, muss ich mir ja keine Gedanken machen.
Der Traffic, der auf dem anderen Interface generiert wird ist vermutlich die Verbindung zum Webinterface von pfSense, welches sich vermutlich ständig aktualisiert.
Viele Grüße,
KHR -
@KHR:
Hallo und mal wieder vielen vielen Dank für die Unterstützung! :-)
Dann hab ich's ja scheinbar noch noch verstanden. :-) Da ich über pfSense mehr erfahren möchte, werde ich mir warscheinlich das pfSense Buch kaufen (pfSense the definitive guide). Ist das zu empfehlen?
Moin,
dem Buch kann ich bis auf das Alter nix schlechtes nachsagen.
Es handelt nicht nur die pfsense an sich ab, sonder erklärt auch einige Grundlagen.
ABER schau dir mal die Goldmitgliedschaft an. Die ist zwar etwas teurer, enthält aber das Buch in einer aktuelleren Version (Mai 2017 glaub' ich). Und Du unterstützt das Projekt.
Oder vielleicht über eine SG 1000 nachdenken. Hier gebt es Hardware und ein Jahr Gold mit Buch (ePub,PDF,…)HornetX11 mobil
-
Moin,
Du hast gesehen das das Buch von 2009 ist?
-teddy
-
Ja, dass das Buch "etwas" älter ist, habe ich gesehen. :-)
Das mit der Gold Mitgliedschaft ist eigentlich eine gute Idee. Oder evtl. wirklich die SG 1000.
Ich frage mich, ob die SG 1000 für mich "ausreichend" ist. Ich denke die VLANs sind für die SG 1000 kein Problem. Ich möchte aber evtl. später mal das Virenscanner PlugIn nutzen. Ist da die SG 1000 noch ausreichend, oder ist das Leistungsmäßig nicht so toll? Hat die SG 1000 Gigabit LAN?
Zur Zeit nutze ich ein ASRock Q1900M (Intel Celeron Quad Core) mit 2GB RAM (DDR3) und zwei Intel PRO 1000 CT NICs. Klar, das System ist absolut oversized, hatte ich aber da. :-)
Würde die SG 1000 für VLANs und das AV PlugIn reichen?
Die SG 1000 wäre, auch was den Stromverbrauch betrifft (mein aktuelles pfSense System braucht ca 25W im idle) besser.
-
Moin,
@KHR:
Würde die SG 1000 für VLANs und das AV PlugIn reichen?
Ganz Bestimmt NICHT.
512MB RAM ist für den AV echt zu wenig.Die Idee eine SG1000 zu nehmen war auch eine andere:
Für 50$ mehr als die reine Goldmitglieschaft erhält man einen Hardware Mehrwert.
Diese kann man dann z.B veräußern oder als "Secure Dongel" mit auf Reisen nehmen oder einen Heimarbeitzplatz anbinden, oder …Mit freundlichen Grüßen
HotnetX11 mobil -
Moin,
das mit dem AV Modul würde ich knicken, ClamAV ist in meinen Augen nur eine Notlösung mit mäßiger Erkennungsleistung, kann Dir aber ratzfatz die ganze Kiste mit 100% CPU Last weghängen. Folgen: Deine Internetverbindung kommt zu erliegen, der Haussegen aus dem Lot und das Nudelholz lernt fliegen. Das willst Du nicht wirklich ;)
-teddy
-
Was Teddy sagt mit dem Zusatz:
Hat die SG 1000 Gigabit LAN?
Nope. Die SG-1000 gibt zwar beide Anschlüsse als Gigabit in Hardware aus, schafft auf den Interfaces durch die interne Bus-Anbindung (ähnlich dem RasPi) kein Gigabit auf den Ports. Damit könntest du ggf. nicht mal eine große Kabel-Leitung vollständig ausnutzen, da die Ports beim Routing schon bei 200-400Mbps Schluß. Die eigene Website spricht da von:
Layer 3 forwarding performance using FreeBSD without a packet filter exceeds 400Mbps. Using pfSense with the default ruleset offers performance exceeding 200Mbps.
als etwas vage formulierte grobe Hausnummern. Sprich ~200Mbps sind drin, können auch mehr sein wenn nicht viel drauf läuft, aber das ist so die grobe Richtung. VPN brauchst du dann gar nicht diskutieren im dreistelligen Bereich ;)
-
Hallo,
ich muss nochmal diesen Thread rauskramen. Habe neulich was getestet und bin etwas verwirrt, was VLANs angeht.
In Bezug auf Reply Nummer 1 von JeGr
@JeGr:…
Variante 1 ist ein Denkfehler/Unwissen von VLAN Handling. Sie funktioniert nicht.
...Ich habe neulich mal einen alten Consumer Router an meinen 24Port Switch gesteckt, dort wo eigentlch die pfSense dransteckt mit VLAN Tagging usw.
JeGr schrieb, dass meine Unwissenheitsversion 1 nicht funktionieren sollte. Das Witzige ist, dass allerdings auch so alles funktionierte. Der Consumer Router hat keinerlei VLAN Tagging gemacht oder dergleichen. Der war im Werkszustand. Im Switch war alles so, wie vorher hier immer beschrieben. Zwei VLANs zugeordnet zu den jeweiligen Ports.
Auch hier war folgende Funktion:
Alle Geräte in ihren jeweiligen VLANs konnten miteinander kommunizieren. VLAN 10 aber nicht mit VLAN 20 und VLAN 20 nicht mit VLAN 10. Beide VLANs waren im selben IP Bereich (192.168.1.0/24).War das jetzt nur ein Zufall, dass das so funktioniert hat (wie in meinem Eröffnungsport als Version 1 beschrieben), oder funktioniert es eigentlich doch so, aber man macht's halt nicht so, sondern mit verschiedenen IP Adressbereichen?
Viele Grüße,
KHR