148267
13.04.2021, aktualisiert am 14.04.2021
5722
57
0
Vigor 165 - pfSense VM - Cisco Switch 350X-48P - DHCP über pfSense?
Wie im Titel bereits erwähnt, will ich mein Netzwerk umbauen auf die im Betreff genannte Config.
Meine Fritzbox 7590 fliegt raus und ich habe mir einen DrayTek Vigor 165 besorgt, welcher im Bridge Modus an eine pfSense VM angeschlossen werden soll.
Am LAN Ausgang der pfSense soll dann mein Cisco 350X-48P Switch angeschlossen werden. Auf dem Server auf dem die pfSense VM laufen wird, laufen diverse andere VM´s. Windows 10, Debian´s und FreeBSD.
Im Moment ist es so, dass der Layer 3 Switch den DHCP übernimmt. Aber sollte ich das so belassen, oder wäre es besser wenn sich die pfSense um den DHCP kümmert?
Im Moment sind für alle meine Endgeräte als Static Hosts im Cisco 350X eingerichtet.
VLAN´s sind schon angelegt und Endgeräte in diverse VLAN´s verteilt, aber ich habe noch keine ACL´s aktiv, da ich damit noch nicht so bewandert bin und ich erstmal das Grundsetup passend haben will
Was meint ihr dazu? Wie macht es am meisten Sinn?
Vielen Dank schon mal für eure Antworten
Und bitte seid nachsichtig: Ich bin nur interessierter Hobbyanwender und arbeite nicht in der IT
Meine Fritzbox 7590 fliegt raus und ich habe mir einen DrayTek Vigor 165 besorgt, welcher im Bridge Modus an eine pfSense VM angeschlossen werden soll.
Am LAN Ausgang der pfSense soll dann mein Cisco 350X-48P Switch angeschlossen werden. Auf dem Server auf dem die pfSense VM laufen wird, laufen diverse andere VM´s. Windows 10, Debian´s und FreeBSD.
Im Moment ist es so, dass der Layer 3 Switch den DHCP übernimmt. Aber sollte ich das so belassen, oder wäre es besser wenn sich die pfSense um den DHCP kümmert?
Im Moment sind für alle meine Endgeräte als Static Hosts im Cisco 350X eingerichtet.
VLAN´s sind schon angelegt und Endgeräte in diverse VLAN´s verteilt, aber ich habe noch keine ACL´s aktiv, da ich damit noch nicht so bewandert bin und ich erstmal das Grundsetup passend haben will
Was meint ihr dazu? Wie macht es am meisten Sinn?
Vielen Dank schon mal für eure Antworten
Und bitte seid nachsichtig: Ich bin nur interessierter Hobbyanwender und arbeite nicht in der IT
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665705
Url: https://administrator.de/forum/vigor-165-pfsense-vm-cisco-switch-350x-48p-dhcp-ueber-pfsense-665705.html
Ausgedruckt am: 23.12.2024 um 16:12 Uhr
57 Kommentare
Neuester Kommentar
Moin,
wenn die Konfig erstmal reicht und läuft spricht da nichts gegen das so zu lassen.
Wichtig ist nur vor Änderungen ein Backup zu ziehen um bei Problemen zurück zu können.
Also viel Spaß beim Experimentieren.
Gruß Looser
wenn die Konfig erstmal reicht und läuft spricht da nichts gegen das so zu lassen.
Wichtig ist nur vor Änderungen ein Backup zu ziehen um bei Problemen zurück zu können.
Also viel Spaß beim Experimentieren.
Gruß Looser
Moin,
Wo der DHCP sitzt ist ja völlig egal.
Du kannst auch einen zentralen Windows-/ Linux-Server dafür nutzen und mehrere Scopes anlegen. An der Routenden Komponente wird dann das DHCP-Relay aktiviert.
Zu den ACLs:
Ist der Cisco (weiterhin) der Router für die VLANs, werden die ACLs auf IP-Ebene dort platziert. Vorteil: das Regelwerk ist etwas performanter und die Pakete müssen nicht erst über den Uplink zur pfSense
Nutzt du die pfSense als Routing-Komponente zwischen den VLANs, musst du hier die ACLs platzieren.
Vorteil, du kannst auch auf Layer4 (also Nach Ports) reglementieren. Aber es muss erst alles über den Uplink zum Switch...
Gruß
em-pie
Wo der DHCP sitzt ist ja völlig egal.
Du kannst auch einen zentralen Windows-/ Linux-Server dafür nutzen und mehrere Scopes anlegen. An der Routenden Komponente wird dann das DHCP-Relay aktiviert.
Zu den ACLs:
Ist der Cisco (weiterhin) der Router für die VLANs, werden die ACLs auf IP-Ebene dort platziert. Vorteil: das Regelwerk ist etwas performanter und die Pakete müssen nicht erst über den Uplink zur pfSense
Nutzt du die pfSense als Routing-Komponente zwischen den VLANs, musst du hier die ACLs platzieren.
Vorteil, du kannst auch auf Layer4 (also Nach Ports) reglementieren. Aber es muss erst alles über den Uplink zum Switch...
Gruß
em-pie
oder wäre es besser wenn sich die pfSense um den DHCP kümmert?
Das ist wie Kollege @em-pie bereits gesagt egal. Am besten wäre es einen zentralen DHCP Server auf einem deiner VMs laufen zu lassen, dann hast du einen zentralen Punkt für die DHCP Konfig ! Siehe dazu auch hier:Netzwerk Management Server mit Raspberry Pi
Leider teilst du auch nicht mit ob du eine Layer 3 Switching Konzept umsetzt (Routing der VLANs auf dem Switch, denn der 350er ist ein L3 Switch) oder ein reines Layer 2 Konzept (Routing auf der FW). Insofern ist das dann so oder so alles Raterei im freien Fall.
Da du derzeit den DHCP auf dem Switch betreibst gehen wir mal von einem Layer 3 VLAN Konzept aus, damit ist die Frage ob dei FW DHCP machen soll so oder so obsolet und unsinnig, denn das kann sie in einem gerouteten VLAN Konzept gar nicht, da sie keinerlei Scopes supportet. In sofern ist der ganze Thread also irgendwie obsolet....
Vielen Dank für eure Antworten.
Sorry das habe ich vergessen - der Switch läuft selbstverständlich im Layer 3 Mode!
Ich weiß leider nicht was ein "Scope" ist. Aber faktisch ist es offenbar so, wenn ich den Layer 3 Mode auf dem Switch anlasse, was wohl auch sinnig ist, dann kann ich ohnehin den DHCP nicht über die pfSense machen?
Dann wäre meine Eingangsfrage quasi aus rein technischen Aspekten schon erschlagen?!
Sorry das habe ich vergessen - der Switch läuft selbstverständlich im Layer 3 Mode!
Ich weiß leider nicht was ein "Scope" ist. Aber faktisch ist es offenbar so, wenn ich den Layer 3 Mode auf dem Switch anlasse, was wohl auch sinnig ist, dann kann ich ohnehin den DHCP nicht über die pfSense machen?
Dann wäre meine Eingangsfrage quasi aus rein technischen Aspekten schon erschlagen?!
Zitat von @148267:
Vielen Dank für eure Antworten.
Sorry das habe ich vergessen - der Switch läuft selbstverständlich im Layer 3 Mode!
Ich weiß leider nicht was ein "Scope" ist. Aber faktisch ist es offenbar so, wenn ich den Layer 3 Mode auf dem Switch anlasse, was wohl auch sinnig ist, dann kann ich ohnehin den DHCP nicht über die pfSense machen?
Ein Scope ist eine Art DHCP-Instanz. In einem Scope wird für ein Subnetz der DHCP-Bereich nebst aller Optionen definiert.Vielen Dank für eure Antworten.
Sorry das habe ich vergessen - der Switch läuft selbstverständlich im Layer 3 Mode!
Ich weiß leider nicht was ein "Scope" ist. Aber faktisch ist es offenbar so, wenn ich den Layer 3 Mode auf dem Switch anlasse, was wohl auch sinnig ist, dann kann ich ohnehin den DHCP nicht über die pfSense machen?
Die pfSense kann schon den DHCP Server für mehere VLANs spielen, wenngleich der Switch das Routing übernimmt.
Der Switch erhält für das Routing immer die .254 als IP-Adresse
An der pfSense legst du alle relevanten VLANs an, erstellt in jedem VLAN ein Interface und gibst der die IP-Adresse .253
Dann wird für jedes Interface ein DHCP-Scope angelegt und der Option "Gateway" die .254 eingetragen.
Fertig.
Schön ist zwar etwas anderes, aber unmöglich ist das nicht.
Dann macht die pfSense DHCP und der Switch das Routing und die paar Datenpakete können auch locker über einen 100Mbit-Verbindung zwischen pfSense und Switch ausgetauscht werden.
Dann wäre meine Eingangsfrage quasi aus rein technischen Aspekten schon erschlagen?!
dann kann ich ohnehin den DHCP nicht über die pfSense machen?
Laienhaft könnte man das so sagen.Was ein Scope ist erklärt doch der Link auf den obigen ISC DHCP Server Setup. Hast du vermutlich mal wieder nicht gelesen, oder ?!
Den Rest hat Kollege @em-pie ja schon erklärt.
Vielen Dank für eure Antworten.
Ich werde den DHCP jetzt auf dem Cisco belassen, das Routing für die VLANS belasse ich auch auf dem Cisco und ich werde dort die ACL´s setzen. Das sollte wohl dann die beste Performance abliefern und die pfSense ist "nur" die Eingangsfirewall aus dem WAN. Ist das so korrekt, oder habe ich mit diesem HW Setup "sinnvollere, performantere Optionen"?
Was mir noch nicht ganz klar ist; Ich habe im Moment das Vigor 165 als full bridged Modem an der pfSense hängen, welche die PPPOE Einwahl übernimmt. Das klappt auch soweit gut und am WAN Interface der pfSense steht meine IPV4 von der Telekom an.
Am LAN Ausgang der pfSense schließe ich direkt meinen Switch an. Der Port hängt bei mir im VLAN 10 wo auch viele Endgeräte aus meinem Netzwerk hängen. Dem LAN Port der pfSense habe ich 10.10.10.88 als static IP vergeben. Den Endgeräten vergebe ich im DHCP Setup jetzt die DNS IP 10.10.10.88, weil der DNS an der pfSense eingetragen ist. Das klappt auch gut und die Endgeräte aus dem VLAN 10 kommen ab dann ins Internet. Nur alle Geräte außerhalb dieses VLAN´s kommen trotz DNS 10.10.10.88 nicht ins Internet.
Ich war bisher der Meinung, dass ein VLAN die Netze erst faktisch trennt, wenn ACL´s gesetzt werden. Da ich diese noch nicht gesetzt habe, suche ich jetzt den Fehler?!
Ich gehe mal schwer von einer von mir nicht verstandenen grundlegenden Problematik aus ;-D Irgendwo muss wohl noch eine Route dafür gesetzt werden?!
Ich werde den DHCP jetzt auf dem Cisco belassen, das Routing für die VLANS belasse ich auch auf dem Cisco und ich werde dort die ACL´s setzen. Das sollte wohl dann die beste Performance abliefern und die pfSense ist "nur" die Eingangsfirewall aus dem WAN. Ist das so korrekt, oder habe ich mit diesem HW Setup "sinnvollere, performantere Optionen"?
Was mir noch nicht ganz klar ist; Ich habe im Moment das Vigor 165 als full bridged Modem an der pfSense hängen, welche die PPPOE Einwahl übernimmt. Das klappt auch soweit gut und am WAN Interface der pfSense steht meine IPV4 von der Telekom an.
Am LAN Ausgang der pfSense schließe ich direkt meinen Switch an. Der Port hängt bei mir im VLAN 10 wo auch viele Endgeräte aus meinem Netzwerk hängen. Dem LAN Port der pfSense habe ich 10.10.10.88 als static IP vergeben. Den Endgeräten vergebe ich im DHCP Setup jetzt die DNS IP 10.10.10.88, weil der DNS an der pfSense eingetragen ist. Das klappt auch gut und die Endgeräte aus dem VLAN 10 kommen ab dann ins Internet. Nur alle Geräte außerhalb dieses VLAN´s kommen trotz DNS 10.10.10.88 nicht ins Internet.
Ich war bisher der Meinung, dass ein VLAN die Netze erst faktisch trennt, wenn ACL´s gesetzt werden. Da ich diese noch nicht gesetzt habe, suche ich jetzt den Fehler?!
Ich gehe mal schwer von einer von mir nicht verstandenen grundlegenden Problematik aus ;-D Irgendwo muss wohl noch eine Route dafür gesetzt werden?!
Moin,
Hast du am Cisco die Default-Route gesetzt?
Die müsste lauten:
0.0.0.0/0 an 10.10.10.88/24
Und der Cisco benötigt auch eine IP im Netz 10.10.10.0/24
Ansonsten mal im Vorfeld von einem Client ein traceroute auf die 1.1.1.1 machen.
Achja, weil ich es von der Sophos kenne: prüfe mal, ob du für jedes VLAN-Netz noch NAT an der pfSense aktivieren musst.
Hast du am Cisco die Default-Route gesetzt?
Die müsste lauten:
0.0.0.0/0 an 10.10.10.88/24
Und der Cisco benötigt auch eine IP im Netz 10.10.10.0/24
Ansonsten mal im Vorfeld von einem Client ein traceroute auf die 1.1.1.1 machen.
Achja, weil ich es von der Sophos kenne: prüfe mal, ob du für jedes VLAN-Netz noch NAT an der pfSense aktivieren musst.
Guten Morgen em-pie
Ja die Default Route ist gesetzt mit 0.0.0.0/0 an 10.10.10.88/24.
Der Cisco hat auch eine IP im 10.10.10.0/24 Netz. Ich werde heute Abend mal eine tracert machen..
Ich habe jetzt nochmal nachgelesen, wie das konkret ist mit den VLAN´s untereinander trennen. Die sind faktisch getrennt, wenn der Switch im Layer 2 läuft also nicht routen kann. Wenn er im Layer 3 läuft und ich unter IP Configuration dem aus dem jeweiligen VLAN Netz eine IP gebe, ab dem Punkt sind sie nicht mehr getrennt ohne ACL´s zu setzen. Habe ich das soweit korrekt verstanden?
EDIT: Gibt es diese Tools wo ihr immer Netzwerke visualisiert irgendwo frei verfügbar? Dann würde ich mir sowas mal Downloaden und meine Netzinfrastruktur aufzeichnen. Das wäre für mein eigenes Verständnis wohl auch echt wertvoll Vielleicht gibt es da direkt was von Dell?
Ja die Default Route ist gesetzt mit 0.0.0.0/0 an 10.10.10.88/24.
Der Cisco hat auch eine IP im 10.10.10.0/24 Netz. Ich werde heute Abend mal eine tracert machen..
Ich habe jetzt nochmal nachgelesen, wie das konkret ist mit den VLAN´s untereinander trennen. Die sind faktisch getrennt, wenn der Switch im Layer 2 läuft also nicht routen kann. Wenn er im Layer 3 läuft und ich unter IP Configuration dem aus dem jeweiligen VLAN Netz eine IP gebe, ab dem Punkt sind sie nicht mehr getrennt ohne ACL´s zu setzen. Habe ich das soweit korrekt verstanden?
EDIT: Gibt es diese Tools wo ihr immer Netzwerke visualisiert irgendwo frei verfügbar? Dann würde ich mir sowas mal Downloaden und meine Netzinfrastruktur aufzeichnen. Das wäre für mein eigenes Verständnis wohl auch echt wertvoll
Vielleicht gibt es da direkt was von Dell?Der Port hängt bei mir im VLAN 10 wo auch viele Endgeräte aus meinem Netzwerk hängen.
Keine gute Idee, denn den Internet Zugang sollte man immer von produktiven Netzen trennen. So hast du allen Internet Traffic in einem Produktivnetz was per se nicht falsch ist, designtechnisch aber nicht so toll.Das Layer 3 Switching Tutorial weist mit seiner Topology Zeichnung explizit darauf hin:
Nur alle Geräte außerhalb dieses VLAN´s kommen trotz DNS 10.10.10.88 nicht ins Internet.
Du hast vermutlich 2 Fehler gemacht:- Default Route im Switch: 0.0.0.0/0 auf die 10.10.0.88 vergessen einzutragen !
- Den Clients in den anderen VLAN vergessen die Switch IP als Gateway zu geben !
Hast du auch den DNS in der pfSense korrekt eingestellt ?? Siehe hier:
PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
Habe ich das soweit korrekt verstanden?
Das hast du korrekt verstandenGibt es diese Tools wo ihr immer Netzwerke visualisiert irgendwo frei verfügbar?
Was denn für Tools ?? Was meinst du da ?
Ich hatte Anfangs den Internettraffic als ich noch an einer Fritzbox hing in einem eigenen VLAN wie es sein sollte. Da ich aber mit der neuen Config bisher zu keiner Lösung kam, habe ich als Test das Ding erst mal in das 10.10.10.0 er Netz geschmissen.
Die Default Route habe ich korrekt gesetzt. Soweit ich das verstehe, würden ansonsten ja die Teilnehmer im 10.10.10.0 er Netz ja auch nicht ins Internet kommen, weil die Anfrage ins leere laufen würde?!
Das mit dem Gateway der Clients in den anderen VLAN´s muss ich prüfen. Aber ich dachte, der Gateway wäre z.b. im 10.10.2.0 er Netz ja die IP die ich in der IP Configuration im Cisco Switch dem jeweiligen VLAN gegeben habe? Ich meinem Fall war das glaub ich die 10.10.2.254. Denn dann nimmt doch z.B. der Client 10.10.2.100 die Route zum 10.10.2.254 (VLAN 2 Switch IP) auf, dort kommt er nicht weiter und geht dann automatisch zur Default Route 10.10.10.88 welche ja an die pfSense über LAN dann über WAN zum Internet führt?
Im DNS habe ich lediglich Cloudflare IP´s eingetragen und meinem Switch die Adresse zum DNS gegeben, da dieser ja per DHCP den DNS weitergibt an meine Clients in den jeweiligen VLAN´s.
Ich meine so ein Tool mit dem du wie über meinem Beitrag das Netzwerk grafisch dargestellt hast. Dann wäre die Erklärung und mein Verständnis dafür wohl auch leichter, wenn ich so eine Grafik von meinem Setup mal erstellen würde.
Du hast vermutlich 2 Fehler gemacht:
Default Route im Switch: 0.0.0.0/0 auf die 10.10.0.88 vergessen einzutragen !
Den Clients in den anderen VLAN vergessen die Switch IP als Gateway zu geben !Die Default Route habe ich korrekt gesetzt. Soweit ich das verstehe, würden ansonsten ja die Teilnehmer im 10.10.10.0 er Netz ja auch nicht ins Internet kommen, weil die Anfrage ins leere laufen würde?!
Das mit dem Gateway der Clients in den anderen VLAN´s muss ich prüfen. Aber ich dachte, der Gateway wäre z.b. im 10.10.2.0 er Netz ja die IP die ich in der IP Configuration im Cisco Switch dem jeweiligen VLAN gegeben habe? Ich meinem Fall war das glaub ich die 10.10.2.254. Denn dann nimmt doch z.B. der Client 10.10.2.100 die Route zum 10.10.2.254 (VLAN 2 Switch IP) auf, dort kommt er nicht weiter und geht dann automatisch zur Default Route 10.10.10.88 welche ja an die pfSense über LAN dann über WAN zum Internet führt?
Im DNS habe ich lediglich Cloudflare IP´s eingetragen und meinem Switch die Adresse zum DNS gegeben, da dieser ja per DHCP den DNS weitergibt an meine Clients in den jeweiligen VLAN´s.
Ich meine so ein Tool mit dem du wie über meinem Beitrag das Netzwerk grafisch dargestellt hast. Dann wäre die Erklärung und mein Verständnis dafür wohl auch leichter, wenn ich so eine Grafik von meinem Setup mal erstellen würde.
die Teilnehmer im 10.10.10.0 er Netz ja auch nicht ins Internet kommen, weil die Anfrage ins leere laufen würde?!
Da sist richtig, denn der L3 Switch ist ja ein Router der das Next Hop Gateway kennen muss. Das macht dann seine Default Route auf den Internet Router.Logischerweise muss der Internet Router dann aber auch die Routen in die VLANs kennen damit die Rückroute klappt (Siehe Skizze oben). Ein Punkt der in L3 Konzepten auch immer mal wieder vergessen wird...
der Gateway wäre z.b. im 10.10.2.0 er Netz ja die IP die ich in der IP Configuration im Cisco Switch dem jeweiligen VLAN gegeben habe?
Das ist absolut richtig !dort kommt er nicht weiter und geht dann automatisch zur Default Route 10.10.10.88
Auch das ist richtig. Aber er kommt ja weiter weil er eben eine Default Route hat !!! 😉Im DNS habe ich lediglich Cloudflare IP´s eingetragen und meinem Switch die Adresse zum DNS gegeben
Das kann man machen ist aber mehr oder minder uninteressant bzw. nicht relevant im Netz weil es einzig und allein nur dazu dient das der Switch selber DNS Adressen auflösen kann. Also z.B. NTP Server Namen usw.Genauso könntest du dort aus die pfSense eintragen.
da dieser ja per DHCP den DNS weitergibt an meine Clients in den jeweiligen VLAN´s.
Wirklich ?! Ich, denke nein und gehe mal davon aus das du den DNS Server im Switch DHCP Setup dediziert angeben musst. Das ist dann der DNS den der Switch DHCP dann an die VLAN Clients ausgibt.Dies sollte dann IMMER die pfSense sein, denn die arbeitet als Proxy DNS mit einem Cache so das nicht alle DNS Anfragen langwierig ins Internet müssen und Wartezeiten unnötig verlängern.
Inter sollte immer die pfSense LAN IP als DNS angegeben werden und die pfSense leitet dann zentral weiter an deine Cloudflare Adressen.
Dazu solltest du zwingend darauf achten den pfSense DNS auch richtig einzustellen:
PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
Ohne dieses Setup fragt die pfSense sonst immer direkt die Root DNS Server.
Cloudflare DNS supportet m.W. auch DNSSEC so das du das auch angehakt lassen kannst in der pfSense.
Ich meine so ein Tool mit dem du wie über meinem Beitrag das Netzwerk grafisch dargestellt hast.
Ahh so... Das ist kinderleicht. Dazu nimmst du Visio oder das kostenlase Draw aus dem Libreoffice Tool und dazu die kostenlosen Cisco Topology Icons:https://www.cisco.com/c/en/us/about/brand-center/network-topology-icons. ...
Wenn du Linux oder Mac User bist auch Draw aus Libreoffice oder dia oder Omnigraffle
Sorry das mit dem DNS habe ich wohl etwas missverständlich geschrieben.
Als DNS im Cisco Switch ist natürlich die 10.10.10.88 angegeben, also meine LAN Seite der pfSense. Und in der pfSense ist der DNS von Cloudflare angegeben, nicht im Switch. Das sollte so passen ohne weitere Settings, oder?
Das ist natürlich korrekt. Im DHCP Setup habe ich den auf dem Switch eingetragenen DNS 10.10.10.88 natürlich bei allen VLAN´s angewählt und in den Static Hosts habe ich ebenfalls den DNS 10.10.10.88 bei den jeweiligen Clients eingestellt.
Vielen Dank bis hier hin, du hast bei mir sehr viel Licht ins Dunkle gebracht Jetzt dämmert es zumindest schon mal etwas ;-D
Ich werde jetzt am Wochenende mal ausgiebig testen und berichten. Dann wandert auch das Internet wieder in ein eigenes VLAN wie es sein soll. Jetzt habe ich ja mehr Hintergrundwissen um das Setup hoffentlich wie gewünscht ans Laufen zu bekommen.
Als DNS im Cisco Switch ist natürlich die 10.10.10.88 angegeben, also meine LAN Seite der pfSense. Und in der pfSense ist der DNS von Cloudflare angegeben, nicht im Switch. Das sollte so passen ohne weitere Settings, oder?
Wirklich ?! Ich, denke nein und gehe mal davon aus das du den DNS Server im Switch DHCP Setup dediziert angeben musst. Das ist dann der DNS den der Switch DHCP dann an die VLAN Clients ausgibt.Das ist natürlich korrekt. Im DHCP Setup habe ich den auf dem Switch eingetragenen DNS 10.10.10.88 natürlich bei allen VLAN´s angewählt und in den Static Hosts habe ich ebenfalls den DNS 10.10.10.88 bei den jeweiligen Clients eingestellt.
Vielen Dank bis hier hin, du hast bei mir sehr viel Licht ins Dunkle gebracht
Jetzt dämmert es zumindest schon mal etwas ;-DIch werde jetzt am Wochenende mal ausgiebig testen und berichten. Dann wandert auch das Internet wieder in ein eigenes VLAN wie es sein soll. Jetzt habe ich ja mehr Hintergrundwissen um das Setup hoffentlich wie gewünscht ans Laufen zu bekommen.
Kommt drauf an wie der Resolver und Forwarder im DNS Setup der pfSense eingestellt sind !!
PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
natürlich bei allen VLAN´s angewählt
Musst dann aber bei den ACLs im Switch aufpassen das Traffic zur 10.10.10.88 mit TCP/UDP 53 immer passieren darf bzw. muss aus den VLAN Segmenten.am Wochenende mal ausgiebig testen und berichten.
Wir sind gespannt...
Den Link bezüglich DNS werde ich mir noch genauer ansehen - danke dafür. Ich war der Meinung das ist etwas "simpler".
Ah siehste, das mit dem Traffic über die 10.10.10.88 wäre mir rein von der Logik her nicht gleich klar gewesen. Aber das hätte ich wohl spätestens in der Firewall bemerkt :D
Dann geb ich mal mein Bestes, mal sehen ob es reicht :P
Ah siehste, das mit dem Traffic über die 10.10.10.88 wäre mir rein von der Logik her nicht gleich klar gewesen. Aber das hätte ich wohl spätestens in der Firewall bemerkt :D
Dann geb ich mal mein Bestes, mal sehen ob es reicht :P
Ach etwas fiel mir gerade noch ein: Ich muss den LAN Port also die Ausgangsseite der pfSense in mein Heimnetz in dem Port am Cisco noch auf Trunk stellen und nicht auf Access, oder? Nur dann werden ja über ein Kabel alle VLAN´s geleitet, ja?
Zitat von @148267:
Ach etwas fiel mir gerade noch ein: Ich muss den LAN Port also die Ausgangsseite der pfSense in mein Heimnetz in dem Port am Cisco noch auf Trunk stellen und nicht auf Access, oder? Nur dann werden ja über ein Kabel alle VLAN´s geleitet, ja?
Korrekt. Zumindest, wenn du jedes VLAN an der pfSense verfügbar haben willst.Ach etwas fiel mir gerade noch ein: Ich muss den LAN Port also die Ausgangsseite der pfSense in mein Heimnetz in dem Port am Cisco noch auf Trunk stellen und nicht auf Access, oder? Nur dann werden ja über ein Kabel alle VLAN´s geleitet, ja?
Willst du es, wie oben von @aqui skizziert, über ein Transfernetz regeln, dann reicht der Typ ACCESS
Ich war der Meinung das ist etwas "simpler".
Das ist es auch. Normal musst du ja gar nichts machen. Allerdings fragt die pfSense dann hardgecodet immer die DNS Root Server IPs an und ignoriert den Uplink DNS.den LAN Port also die Ausgangsseite der pfSense in mein Heimnetz in dem Port am Cisco noch auf Trunk stellen und nicht auf Access, oder?
Nein !M.E. falsch, denn du hast dich ja entschieden ein Layer 3 Switching Konzept zu gehen, oder ?
Sprich du routest also alle VLANs auf dem L3 Switch und der routet dann alles was ins Internet geht an die FW. Dann ist die Firewall natürlich ein reiner Access Port, denn sie routet ja keine VLANs und "kennt" diese dann auch folglich nicht. Fazit: Kein Trunk
Allerdings....
Ein Gäste Segement routet man eigentlich nicht auf dem L3 Core Router. Es bekommt dort schlicht keine IP und wird dann über einen Trunk direkt an die Firewall weitergereicht und endet L3 seitig dort.
Dann brauchst du wieder einen Trunk.
Natürlich kann man das Gäste Segment auch mit einer ACL auf dem Switch blocken zu den anderen VLANs
Da kannst du die für dich schönere Variante aussuchen...
Ok also ich habe mit wie du sagst ja für das Layer 3 Switch Konzept entschieden. Layer 3 Routing im LAN macht also alles der Cisco und die pfSense hat nur Arbeit, wenn etwas über die Default Route muss, welche ich natürlich jetzt auch auf die neue pfSense IP 10.10.2.2 gestellt habe.
Den Port lasse ich daher logischerweise auf Access stehen. Das wäre dann quasi das "Transfernetz" wie du es nennst?!
Ich habe jetzt den LAN Abgang der pfSense in VLAN 2 gepackt und der Port steht auf Access. Dort befindet sich also jetzt ausschließlich die pfSense und unter IP Configuration des Cisco´s natürlich auch der Cisco mit IP 10.10.2.1.
VLAN Config habe ich in der pfSense selbst nicht angegeben.
Meinen ganzen anderen Netzen habe ich jetzt den DNS 10.10.2.2 zugewiesen. Der Gateway im jeweiligen Netz ist weiterhin die jeweilige für das Netz unter IP Configuration im Cisco angegebene IP. In meinem Fall für die Netze 10.10.1.1 / 10.10.2.1 / 10.10.3.1 / 10.10.4.1 / 10.10.10.1.
Jetzt habe ich die pfSense mit der Konfig ans Laufen gebracht, aber ich komme ausschließlich auf die pfSense, wenn der PC mit dem ich connecten will sich auch im VLAN 2 befindet. Dann geht natürlich das Internet sofort und das Webinterface der pfSense ist erreichbar. Sobald ich den Port mit dem angeschlossenen PC aber wieder wie üblich in VLAN 10 schmeisse, kommt der Ping schon nicht mehr durch.
Das ist mir momentan überhaupt nicht klar warum. Mir ist durchaus bewusst, dass es irgendwo am Routing hackt, aber wo kann da der Fehler liegen? Die anderen Netze sind von dem 2er VLAN und vom 10er VLAN alle erreichbar. Nur VLAN 2 erreiche ich nicht aus dem 10er Netz.
Es müsste doch bei einem Ping so sein: PC IP im VLAN 10 z.B. 10.10.10.100 stellt Anfrage an 10.10.2.2. Dieser geht zuerst ans Gateway 10.10.10.1. Der steht ja im gleichen Netz wie der 10.10.2.1 aus VLAN 2 also geht er dort hin. Von 10.10.2.1 müsste er ja dann direkt auf 10.10.2.2 kommen.
Daher ist meine Vermutung das ich in der pfSense noch eine Rückroute einrichten muss. Ist mein Gedankenganz darüber korrekt?
EDIT: Also sooo falsch kann mein Gedankengang nicht sein :D Ich habe jetzt in der pfSense unter Routing/Gateways ein Transfernetz eingerichtet mit der Gateway IP 10.10.2.1.
Dann habe ich eine statische Route eingetragen für das Netzwerk 10.10.10.0/24 welche das Gateway Transfernetz 10.10.2.1 hat. Somit sollte die Rückroute zum 10.10.10.0 er Netz wieder korrekt funktionieren und wenn ich meinen Client jetzt wieder in VLAN 10 schmeisse, dann komme ich auf das Webinterface der pfSense
Der Rest sollte jetzt nur noch ein Problem von Blocks in der Firewall sein DNS auf Port 53 z.B. welchen ich freigeben muss.
Den Port lasse ich daher logischerweise auf Access stehen. Das wäre dann quasi das "Transfernetz" wie du es nennst?!
Ich habe jetzt den LAN Abgang der pfSense in VLAN 2 gepackt und der Port steht auf Access. Dort befindet sich also jetzt ausschließlich die pfSense und unter IP Configuration des Cisco´s natürlich auch der Cisco mit IP 10.10.2.1.
VLAN Config habe ich in der pfSense selbst nicht angegeben.
Meinen ganzen anderen Netzen habe ich jetzt den DNS 10.10.2.2 zugewiesen. Der Gateway im jeweiligen Netz ist weiterhin die jeweilige für das Netz unter IP Configuration im Cisco angegebene IP. In meinem Fall für die Netze 10.10.1.1 / 10.10.2.1 / 10.10.3.1 / 10.10.4.1 / 10.10.10.1.
Jetzt habe ich die pfSense mit der Konfig ans Laufen gebracht, aber ich komme ausschließlich auf die pfSense, wenn der PC mit dem ich connecten will sich auch im VLAN 2 befindet. Dann geht natürlich das Internet sofort und das Webinterface der pfSense ist erreichbar. Sobald ich den Port mit dem angeschlossenen PC aber wieder wie üblich in VLAN 10 schmeisse, kommt der Ping schon nicht mehr durch.
Das ist mir momentan überhaupt nicht klar warum. Mir ist durchaus bewusst, dass es irgendwo am Routing hackt, aber wo kann da der Fehler liegen? Die anderen Netze sind von dem 2er VLAN und vom 10er VLAN alle erreichbar. Nur VLAN 2 erreiche ich nicht aus dem 10er Netz.
Es müsste doch bei einem Ping so sein: PC IP im VLAN 10 z.B. 10.10.10.100 stellt Anfrage an 10.10.2.2. Dieser geht zuerst ans Gateway 10.10.10.1. Der steht ja im gleichen Netz wie der 10.10.2.1 aus VLAN 2 also geht er dort hin. Von 10.10.2.1 müsste er ja dann direkt auf 10.10.2.2 kommen.
Daher ist meine Vermutung das ich in der pfSense noch eine Rückroute einrichten muss. Ist mein Gedankenganz darüber korrekt?
EDIT: Also sooo falsch kann mein Gedankengang nicht sein :D Ich habe jetzt in der pfSense unter Routing/Gateways ein Transfernetz eingerichtet mit der Gateway IP 10.10.2.1.
Dann habe ich eine statische Route eingetragen für das Netzwerk 10.10.10.0/24 welche das Gateway Transfernetz 10.10.2.1 hat. Somit sollte die Rückroute zum 10.10.10.0 er Netz wieder korrekt funktionieren und wenn ich meinen Client jetzt wieder in VLAN 10 schmeisse, dann komme ich auf das Webinterface der pfSense
Der Rest sollte jetzt nur noch ein Problem von Blocks in der Firewall sein
DNS auf Port 53 z.B. welchen ich freigeben muss.macht also alles der Cisco und die pfSense hat nur Arbeit, wenn etwas über die Default Route muss
Das ist korrekt !Den Port lasse ich daher logischerweise auf Access stehen.
Richtig !Dort befindet sich also jetzt ausschließlich die pfSense und Cisco. VLAN Config habe ich in der pfSense selbst nicht angegeben.
Alles richtig gemacht !aber ich komme ausschließlich auf die pfSense, wenn der PC mit dem ich connecten will sich auch im VLAN 2 befindet.
Typischer Anfängerfehler und wie immer die Default Route 0.0.0.0/0 Gateway: 10.10.2.2 auf dem Switch VERGESSEN !!Möglich auch das du auf der pfSense die statischen Routen in deine VLANs (Rückroute) vergessen hast
Ziel: 10.10.0.0, Maske:255.255.0.0, Gateway: 10.10.2.1 (Switch VLAN2 IP)
DAS solltest du dringenst checken !!!
dass es irgendwo am Routing hackt
Hacken tut man eigentlich nur im Garten !! 😉https://www.duden.de/suchen/dudenonline/haken
Das ist mir momentan überhaupt nicht klar warum.
Wie gesagt... Ein oder beide statischen Routen vergessen !!!Auf der pfSense sind das 2 Schritte:
- Gateway IP 10.10.2.1 (Switch IP) einrichten (ACHTUNG: Haken bei "Gateway Monitoring" deaktivieren setzen, denn das Gateway Monitoring sollte abgeschaltet sein !!
- Statische Route Ziel: 10.10.0.0, Maske:255.255.0.0, Gateway: 10.10.2.1 (Switch VLAN2 IP) eintragen
das ich in der pfSense noch eine Rückroute einrichten muss
Bingo !Einfach nur einmal Tutorials WIRKLICH lesen, dann sind solche "Nachfragethreads" hier überflüssig !
Sorry ich habe oben eben editiert :D Ich habe wohl die Probleme schon gelöst
Jetzt muss ich wohl nur noch die Firewall Rules korrigieren
Jetzt muss ich wohl nur noch die Firewall Rules korrigieren
Dann mal los...!!
Also irgendetwas mache ich bahnbrechend falsch :D
Per ping in der pfSense über das WAN Interface kann ich google.de problemlos pingen.
Über das LAN Interface nicht. Und dementsprechend auch nicht mit dem Endgerät 10.10.10.13 im VLAN 10. Auch nicht per IP um DNS erstmal komplett auszuschließen.
Das Log geht über vor deny´s. In der Standard Config sollten doch eigentlich die Standard allow all Regeln greifen, oder?
Selbst der Ping vom 10.10.10.13 geht erst wenn ich das ICMP Protocol für die IP 10.10.10.13 freigebe. Die Default allow Rule enthält aber eigentlich any bei Protocol.
Ich bin komplett ratlos?!
EDIT: Das Standardgateway stand auf Automatic und nicht fest auf WAN_PPPOE. Dies habe ich jetzt umgestellt. Ich habe (obwohl all allow Regeln vorhanden) eine Allow Rule erstellt mit IPv4 TCP/UDP Source 10.10.0.0/16 also alles aus meinen 10.10.x.0 er Netzen durchzulassen. Ab dann kann ich per IP ins Netz.
DNS war auch noch falsch. Ich habe jetzt mal den Resolver abgeschaltet und den DNS Forwarder aktiviert. Jetzt geht das Internet im 10er VLAN zumindest schon mal. *puuuh*
Per ping in der pfSense über das WAN Interface kann ich google.de problemlos pingen.
Über das LAN Interface nicht. Und dementsprechend auch nicht mit dem Endgerät 10.10.10.13 im VLAN 10. Auch nicht per IP um DNS erstmal komplett auszuschließen.
Das Log geht über vor deny´s. In der Standard Config sollten doch eigentlich die Standard allow all Regeln greifen, oder?
Selbst der Ping vom 10.10.10.13 geht erst wenn ich das ICMP Protocol für die IP 10.10.10.13 freigebe. Die Default allow Rule enthält aber eigentlich any bei Protocol.
Ich bin komplett ratlos?!
EDIT: Das Standardgateway stand auf Automatic und nicht fest auf WAN_PPPOE. Dies habe ich jetzt umgestellt. Ich habe (obwohl all allow Regeln vorhanden) eine Allow Rule erstellt mit IPv4 TCP/UDP Source 10.10.0.0/16 also alles aus meinen 10.10.x.0 er Netzen durchzulassen. Ab dann kann ich per IP ins Netz.
DNS war auch noch falsch. Ich habe jetzt mal den Resolver abgeschaltet und den DNS Forwarder aktiviert. Jetzt geht das Internet im 10er VLAN zumindest schon mal. *puuuh*
Wie immer...falsches Regelwerk. 😉
Das sind so die typischen Anfängerhürden bei einer Firewall die gerne im Eifer des Gefechts übersehen werden. Du bist da scheinbar keine Ausnahme.... Deshalb ist das Regelwerk und auch das Firewall Log immer erste Anlaufstelle, denn dort kannst du immer sehen was die Firewall blockt.
Hier ist es in den "Settings" sinnvoll die Reihenfolge auf "Reverse" zu setzen um die aktuellsten Einträge immer am Anfang zu sehen.
PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
Mit der falschen Einstellung fragt die FW nie den dir übermittelten DNS Server sondern immer die Root Server direkt. Erzeugt unnötigen Traffic und verzögert massiv die DNS Antworten.
Solltest du besser wieder korrigieren !
Vermutlich hast du auch hier wieder nicht richtig gelesen und vergessen den "Forward Query" zu aktivieren und/oder DNSsec zu deaktivieren.
Das sind so die typischen Anfängerhürden bei einer Firewall die gerne im Eifer des Gefechts übersehen werden. Du bist da scheinbar keine Ausnahme.... Deshalb ist das Regelwerk und auch das Firewall Log immer erste Anlaufstelle, denn dort kannst du immer sehen was die Firewall blockt.
Hier ist es in den "Settings" sinnvoll die Reihenfolge auf "Reverse" zu setzen um die aktuellsten Einträge immer am Anfang zu sehen.
Ich habe jetzt mal den Resolver abgeschaltet und den DNS Forwarder aktiviert.
Das ist FALSCH ! Guckst du hier:PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
Mit der falschen Einstellung fragt die FW nie den dir übermittelten DNS Server sondern immer die Root Server direkt. Erzeugt unnötigen Traffic und verzögert massiv die DNS Antworten.
Solltest du besser wieder korrigieren !
Vermutlich hast du auch hier wieder nicht richtig gelesen und vergessen den "Forward Query" zu aktivieren und/oder DNSsec zu deaktivieren.
Du musst mich schon auch verstehen: Ich lese alles was ich zu diesen Themen finde; schwierig wird es nur, wenn einem nur die Hälfte davon klar ist :D
Lesen heißt ja leider noch nicht verstehen und verstehen ist ja das einzige was mich langfristig weiterbringt
Die Firewall mit aktuelle Blocks oben hatte ich bereits eingestellt
Aber kannst du mir nun erklären, warum in meiner Konstellation die Standard Allow All Regeln nicht greifen? Das ist mir noch garnicht klar?! Die welche als Source Lan Net eingetragen haben meine ich nach einer Standardinstallation der pfSense. Das hat ja wohl irgendwas mit meinem Netzwerkaufbau hinter der pfSense zu tun denke ich.
EDIT: Also wenn ich das Setup genauso einstelle wie du in dem Link schreibst, dann klappt das erst wenn ich das auch ausschalte:
Warum muss ich das machen? Habe ich in meiner Konstellation auch schon eine "Router Kaskade" weil die pfSense auch routet genauso wieder Cisco Switch? Ich dachte das muss man nur abwählen, wenn am WAN Port ein Router klemmt und nicht wenn am WAN Port direkt die Internet IP über ein Modem per PPPOE anliegt?!
EDIT 2:
Ahh mit Lan Net ist wohl in meinem Fall nur das Subnet gemeint, das ich am LAN Ausgang der pfSense anliegen habe? In meinem Fall also ausschließlich das 10.10.2.2 und nicht meine nebenher liegenden Netze? Das würde es erklären, warum die Allow all Regel in dem Fall nicht greift Ich dachte Lan Net meint das "gesamte" LAN Netz also alles außer WAN. Das ist wohl falsch.
Oh man und ich suche Stunde um Stunde den Fehler :D
EDIT 3:
Der DNS geht nach Neustart der pfSense immer ein paar Minuten und geht dann plötzlich nicht mehr. Nach einer Internet Recherche habe ich gelesen, dass es offenbar einen Bug im DNS gibt in Version 2.5.0. Das ist natürlich doof, weil ich nicht sicher weiß, ob es besagter Bug ist oder ob ich noch weitere Fehler im Setup habe
Lesen heißt ja leider noch nicht verstehen und verstehen ist ja das einzige was mich langfristig weiterbringt
Die Firewall mit aktuelle Blocks oben hatte ich bereits eingestellt
Aber kannst du mir nun erklären, warum in meiner Konstellation die Standard Allow All Regeln nicht greifen? Das ist mir noch garnicht klar?! Die welche als Source Lan Net eingetragen haben meine ich nach einer Standardinstallation der pfSense. Das hat ja wohl irgendwas mit meinem Netzwerkaufbau hinter der pfSense zu tun denke ich.
EDIT: Also wenn ich das Setup genauso einstelle wie du in dem Link schreibst, dann klappt das erst wenn ich das auch ausschalte:
Hier sind dazu nochmals die wichtigsten ToDo Schritte:
RFC1918 IP Netz Blocking am WAN Port deaktivieren Sollte man in einer Router Kaskade immer machen.Warum muss ich das machen? Habe ich in meiner Konstellation auch schon eine "Router Kaskade" weil die pfSense auch routet genauso wieder Cisco Switch? Ich dachte das muss man nur abwählen, wenn am WAN Port ein Router klemmt und nicht wenn am WAN Port direkt die Internet IP über ein Modem per PPPOE anliegt?!
EDIT 2:
Ahh mit Lan Net ist wohl in meinem Fall nur das Subnet gemeint, das ich am LAN Ausgang der pfSense anliegen habe? In meinem Fall also ausschließlich das 10.10.2.2 und nicht meine nebenher liegenden Netze? Das würde es erklären, warum die Allow all Regel in dem Fall nicht greift
Ich dachte Lan Net meint das "gesamte" LAN Netz also alles außer WAN. Das ist wohl falsch.Oh man und ich suche Stunde um Stunde den Fehler :D
EDIT 3:
Der DNS geht nach Neustart der pfSense immer ein paar Minuten und geht dann plötzlich nicht mehr. Nach einer Internet Recherche habe ich gelesen, dass es offenbar einen Bug im DNS gibt in Version 2.5.0. Das ist natürlich doof, weil ich nicht sicher weiß, ob es besagter Bug ist oder ob ich noch weitere Fehler im Setup habe
Neuer Tag - neues Glück
Ich habe alles nochmal von vorne aufgesetzt. Solange ich nicht am Switch hänge geht alles normal. Hänge ich mich an den Switch, geht der DNS oft erst korrekt nachdem ich das WAN Interface neugestartet habe. Dann ist alles dauerhaft in Ordnung.
Dann fahre ich die VM herunter und erstelle ein Backup. Dann fahre ich die VM wieder hoch und der DNS klappt wieder nicht -.- Und es macht ausschließlich der DNS ein Problem. Internet per IP klappt problemlos direkt nach dem Neustart der VM.
Jetzt führt auch der Neustart der WAN Schnittstelle wieder nicht zum Erfolg. Es ist zum Haare raufen :D
EDIT: Jetzt habe ich den DNS mal mit Wireshark verfolgt. Nach einer DNS Anfrage kommt eine Rückantwort "Standard query response xxxxxxx Refused. Das ist ja wohl das Problem.
Stelle ich am Client den DNS direkt auf 1.1.1.1 geht das Internet bzw. die Namensauflösung natürlich sofort. Aber das ist ja nicht meine Wunschconfig. Dann bekommt man im Wireshark auch keine Refuses mehr auf UDP Port 53.
EDIT 2: Ein weiterer Restart vom WAN Interface und das Ding leitet die Anfragen wieder korrekt weiter. Sehr strange. Setup weiterhin komplett unverändert.
Dann dauert es wieder eine Zeit lang und schon hat man wieder Refuses drauf.
Ich habe alles nochmal von vorne aufgesetzt. Solange ich nicht am Switch hänge geht alles normal. Hänge ich mich an den Switch, geht der DNS oft erst korrekt nachdem ich das WAN Interface neugestartet habe. Dann ist alles dauerhaft in Ordnung.
Dann fahre ich die VM herunter und erstelle ein Backup. Dann fahre ich die VM wieder hoch und der DNS klappt wieder nicht -.- Und es macht ausschließlich der DNS ein Problem. Internet per IP klappt problemlos direkt nach dem Neustart der VM.
Jetzt führt auch der Neustart der WAN Schnittstelle wieder nicht zum Erfolg. Es ist zum Haare raufen :D
EDIT: Jetzt habe ich den DNS mal mit Wireshark verfolgt. Nach einer DNS Anfrage kommt eine Rückantwort "Standard query response xxxxxxx Refused. Das ist ja wohl das Problem.
Stelle ich am Client den DNS direkt auf 1.1.1.1 geht das Internet bzw. die Namensauflösung natürlich sofort. Aber das ist ja nicht meine Wunschconfig. Dann bekommt man im Wireshark auch keine Refuses mehr auf UDP Port 53.
EDIT 2: Ein weiterer Restart vom WAN Interface und das Ding leitet die Anfragen wieder korrekt weiter. Sehr strange. Setup weiterhin komplett unverändert.
Dann dauert es wieder eine Zeit lang und schon hat man wieder Refuses drauf.
warum in meiner Konstellation die Standard Allow All Regeln nicht greifen?
Vermutlich hast du die 2 Grundregeln NICHT beachtet:- Regeln gelten nur INBOUND also VOM Netzwerk Draht IN das Interface hinein
- Es gilt "First match wins", sprich nach dem ersten positiven Hit im Regelwerk wird der Rest der Regeln NICHT mehr abgearbeitet. Reihenfolge zählt also.
Da du dein Regelwerk aber leider nicht gepostet hast kann man es diesbezüglich auch nicht überprüfen und eine zielführende Hilfe wird damit sehr schwer.
Warum muss ich das machen?
Du must es NICHT so machen, weil du die Firewall NICHT in einer WAN Port Kaskade betreibst !!!Dieser Punkt gilt ausschliesslich nur für Nutzer die VOR der Firewall am WAN Port noch einen NAT Router betreiben !
Bei dir nicht der Fall, deshalb darfst du keinesfalls die RFC 1918 IP netze am WAN Port freigeben.
Leider hast du hier wieder mal nicht das Tutorial gelesen denn das redet bei der Kaskade ausschliesslich vom "WAN Port" und NICHT vom LAN Port. Für deinen Router/L3 Switch am LAN Port gilt dieser Part also NICHT !
Am LAN Port ist ja im Default eh eine LAN zu ANY Scheunentor Regel die alles erlaubt. Es sei denn du hast diese angepasst buzw. das MUSST du zwangsweise damit am LAN Port nicht nur das LAN Port IP netz sondern auch deine VLANs durchgelassen werden.
Das hast du aber mit der größeren 16 Bit Maske die alle 10.10er Netze passieren lässt schon wunderbar gemacht !
Einen wichtigen Punkt gibts da noch in den Advanced Settings unter Firewall&NAT solltest du noch den Haken setzen das lokales Routing NICHT noch extra durch die FW rennt !!
mit Lan Net ist wohl in meinem Fall nur das Subnet gemeint
Richtig !Alles mit der Absender IP 10.10.2.x
Das würde es erklären, warum die Allow all Regel in dem Fall nicht greift
Nein, das Wäre ja Quatsch, denn ALLOW ALL besagt ja wie der Name "ALL" schon sagt ALLES !!Du musst hier mal genauer hinsehen ob mit "ALL" eines deider 3 möglichen Dinge gemeint ist:
- Protokolle
- Absender IP
- Empfänger IP
Dazu sollte man erstmal in Ruhe in sich gehen und sich eine Security Policy auf einem Stück Papier aufstellen welches Netz oder Host WAS darf und das dann umsetzen.
Sehr empfehlenswert sind dann immer Aliase zu nutzen um das effizient und einfach managebar ins Regelwerk zu bringen !
dass es offenbar einen Bug im DNS gibt in Version 2.5.0.
Nein, das ist Unsinn. Außerdem ist die aktuellste Version mittlerweile die 2.5.1 !Stelle den DNS richtig ein (siehe_oben) dann funktioniert das auch fehlerfrei !
Solange ich nicht am Switch hänge geht alles normal
Du meinst du bist mit dem Client am LAN Port- DNS ist richtig gesetzt, Forwarder AUS und Resolver AN, DNSSEC ist deaktiviert und Query Firwarding aktiviert ??
- DNS Server am Clienbt ist die LAN Port IP der pfSense
- nslookup Checks mit z.B. nslookup www.heise.de laufen fehlerlos am Client ?
- Check mit ipconfig -all das der Client am L3 Switch die richtige DNS Server IP bekommen hat ! (pfSense LAN IP)
- Regelwerk sollte stimmen das DNS TCP/UDP 53 von 10.10.0.0 /16 nach ANY erlaubt sein soll ! (Erste Regel) Ist obsolet wenn die LAN Port Regel "Proto: IPv4 ANY, Source: 10.10.0.0/16, Destination: ANY, Port ANY" eingestellt ist, denn dann darf alles was aus irgendwelchen 10.10.0.0er Netzen kommt passieren.
- Checke die via PPPoE vom Provider übertragenen DNS IP Server ob diese stimmen. Unter Status --> DNS Resolver !! Und auf der pfSense selber unter Diagnostics -> DNS Lookup !
- Dann vom Client wieder nslookup Checks mit z.B. nslookup www.heise.de !
"Standard query response xxxxxxx Refused. Das ist ja wohl das Problem.
Du hast vermutlich im Resolver vergessen DNSSEC abzuschalten !!
Und... nutze ZUERST immer die Check Funktion unter "Diagnostics -> DNS Lookup" direkt auf der pfSense um IMMER VORHER zu verifizieren das die pfSense selber sauber auflösen kann !!
Check ihrer DNS Uplink Server unter "Status --> DNS Resolver" gehört dazu !!
Zitat von @aqui:
Da du dein Regelwerk aber leider nicht gepostet hast kann man es diesbezüglich auch nicht überprüfen und eine zielführende Hilfe wird damit sehr schwer.
warum in meiner Konstellation die Standard Allow All Regeln nicht greifen?
Vermutlich hast du die 2 Grundregeln NICHT beachtet:- Regeln gelten nur INBOUND also VOM Netzwerk Draht IN das Interface hinein
- Es gilt "First match wins", sprich nach dem ersten positiven Hit im Regelwerk wird der Rest der Regeln NICHT mehr abgearbeitet. Reihenfolge zählt also.
Da du dein Regelwerk aber leider nicht gepostet hast kann man es diesbezüglich auch nicht überprüfen und eine zielführende Hilfe wird damit sehr schwer.
Meine einzige Regel ist erlaube IPv4 ANY, Source: 10.10.0.0/16, Destination: ANY, Port ANY
Ich habe also die Standard - Scheunentor Regel abgeändert, da ein LAN Net bei Source hier ja nur 10.10.2.0 freigeben würde.
Warum muss ich das machen?
Du must es NICHT so machen, weil du die Firewall NICHT in einer WAN Port Kaskade betreibst !!!Dieser Punkt gilt ausschliesslich nur für Nutzer die VOR der Firewall am WAN Port noch einen NAT Router betreiben !
Bei dir nicht der Fall, deshalb darfst du keinesfalls die RFC 1918 IP netze am WAN Port freigeben.
Ja das hat mich eben verwirrt, weil du in einem Post von oben auf den Link verwiesen hast. Ich habe diese Blocks auf der WAN Seite aber jetzt wieder aktiviert. Diese Option bewirkt also, das private Adressbereiche von außen am WAN Port also vom Internet durch meine Firewall gelassen werden, ja? Das ist also ohne Router Kaskade sehr übel, den Haken da raus zu nehmen?! Mir war dabei von meinem Verständnis dafür daher schon nicht mehr wohl. Daher meine Nachfrage dazu.
Leider hast du hier wieder mal nicht das Tutorial gelesen denn das redet bei der Kaskade ausschliesslich vom "WAN Port" und NICHT vom LAN Port. Für deinen Router/L3 Switch am LAN Port gilt dieser Part also NICHT !
Am LAN Port ist ja im Default eh eine LAN zu ANY Scheunentor Regel die alles erlaubt. Es sei denn du hast diese angepasst buzw. das MUSST du zwangsweise damit am LAN Port nicht nur das LAN Port IP netz sondern auch deine VLANs durchgelassen werden.
Das hast du aber mit der größeren 16 Bit Maske die alle 10.10er Netze passieren lässt schon wunderbar gemacht !
Am LAN Port ist ja im Default eh eine LAN zu ANY Scheunentor Regel die alles erlaubt. Es sei denn du hast diese angepasst buzw. das MUSST du zwangsweise damit am LAN Port nicht nur das LAN Port IP netz sondern auch deine VLANs durchgelassen werden.
Das hast du aber mit der größeren 16 Bit Maske die alle 10.10er Netze passieren lässt schon wunderbar gemacht !
Genau das habe ich gleich zu Beginn gemacht wie oben nochmal beschrieben. Diese Standard Regel greift ja "nur" wenn dahinter nur ein Netzwerk am LAN hängt, was bei mir durch den Layer 3 Switch mit VLAN´s ja nicht so ist.
Einen wichtigen Punkt gibts da noch in den Advanced Settings unter Firewall&NAT solltest du noch den Haken setzen das lokales Routing NICHT noch extra durch die FW rennt !!
Den Haken habe ich soeben gesetzt!
mit Lan Net ist wohl in meinem Fall nur das Subnet gemeint
Richtig !Alles mit der Absender IP 10.10.2.x
Das würde es erklären, warum die Allow all Regel in dem Fall nicht greift
Nein, das Wäre ja Quatsch, denn ALLOW ALL besagt ja wie der Name "ALL" schon sagt ALLES !!Du musst hier mal genauer hinsehen ob mit "ALL" eines deider 3 möglichen Dinge gemeint ist:
- Protokolle
- Absender IP
- Empfänger IP
Ich habe die Regel ja mit Protocol ANY eingestellt und nicht auf TCP/UDP.
Dazu sollte man erstmal in Ruhe in sich gehen und sich eine Security Policy auf einem Stück Papier aufstellen welches Netz oder Host WAS darf und das dann umsetzen.
Sehr empfehlenswert sind dann immer Aliase zu nutzen um das effizient und einfach managebar ins Regelwerk zu bringen !
Sehr empfehlenswert sind dann immer Aliase zu nutzen um das effizient und einfach managebar ins Regelwerk zu bringen !
dass es offenbar einen Bug im DNS gibt in Version 2.5.0.
Nein, das ist Unsinn. Außerdem ist die aktuellste Version mittlerweile die 2.5.1 !Ich nutze auch bereits die Version 2.5.1. Aber warum ist das Quatsch? Es gibt eine Vielzahl an Berichte darüber im Netz, dass der Unbound scheinbar nach einer Zeit nicht mehr geht. Im Changelog zur 2.5.1 sind auch ein paar DNS Fixes zu lesen.
Stelle den DNS richtig ein (siehe_oben) dann funktioniert das auch fehlerfrei !
Solange ich nicht am Switch hänge geht alles normal
Du meinst du bist mit dem Client am LAN Port- DNS ist richtig gesetzt, Forwarder AUS und Resolver AN, DNSSEC ist deaktiviert und Query Firwarding aktiviert ??
- DNS Server am Clienbt ist die LAN Port IP der pfSense
- nslookup Checks mit z.B. nslookup www.heise.de laufen fehlerlos am Client ?
Exakt. Und ich habe natürlich immer zuerst einen DNS Lookup auf der pfSense gestartet und gekuckt, ob alles korrekt auflöst
Also ein paar Basic´s sind mir schon durchaus bekannt Wenn dem so ist dann umstecken auf den L3 Switch
- Check mit ipconfig -all das der Client am L3 Switch die richtige DNS Server IP bekommen hat ! (pfSense LAN IP)
Die DNS IP habe ich immer gecheckt und mein Client im VLAN 10 mit IP 10.10.10.13 hat dann auch immer den korrekten DNS mit der IP 10.10.2.2 eingetragen bekommen welche ja die pfSense ist.
* Regelwerk sollte stimmen das DNS TCP/UDP 53 von 10.10.0.0 /16 nach ANY erlaubt sein soll ! (Erste Regel) Ist obsolet wenn die LAN Port Regel "Proto: IPv4 ANY, Source: 10.10.0.0/16, Destination: ANY, Port ANY" eingestellt ist, denn dann darf alles was aus irgendwelchen 10.10.0.0er Netzen kommt passieren.
Ja genau, hier greift ja meine abgeänderte und einzige Scheunentor Regel.
* Checke die via PPPoE vom Provider übertragenen DNS IP Server ob diese stimmen. Unter Status --> DNS Resolver !! Und auf der pfSense selber unter Diagnostics -> DNS Lookup !
Also die Provider DNS habe ich bisher nicht irgendwie separat gecheckt. Ich habe nur immer einen DNS Lookup gemacht auf der pfSense und mir angesehen, ob alle DNS Server auflösen, was sie auch machten.
* Dann vom Client wieder nslookup Checks mit z.B. nslookup www.heise.de !
Immer strategisch vorgehen und bei Fehlern das hier auch sinnvoll posten !
Achte darauf !!!
Immer strategisch vorgehen und bei Fehlern das hier auch sinnvoll posten !
"Standard query response xxxxxxx Refused. Das ist ja wohl das Problem.
Du hast vermutlich im Resolver vergessen DNSSEC abzuschalten !!Nein. Die Optionen waren die ganze Zeit schon korrekt gesetzt. DNSSEC war aus und DNS Query Forwarding an wie du mir es schon vorher in deinen Posts geraten hast.
Ich habe allerdings jetzt, obwohl es meiner Meinung nach nicht nötig ist unter Services - DNS Resolver - Access Lists eine Allow Regel für das Netz 10.10.0.0/16 eingetragen und seither ist scheinbar Ruhe mit den "Ausfällen"?! Eigentlich sollte laut Standard Setup das ja automatisch erlaubt werden, wenn es aus einem privaten Netz kommt. Ich bin mir hier aber nicht sicher, ob diese Funktion evtl. nur korrekt arbeitet, wenn hinter der pfSense ausschließlich ein Netz arbeitet? Kann es sein, dass es daran lag? Quasi Analog zu dem Problem bei der Standard Firewall Regel mit dem LAN Net..
Und... nutze ZUERST immer die Check Funktion unter "Diagnostics -> DNS Lookup" direkt auf der pfSense um IMMER VORHER zu verifizieren das die pfSense selber sauber auflösen kann !!
Das habe ich natürlich die ganze Zeit so gemacht. Wenn dort nichts auflöst, brauche ich auf den Clients nicht weiter zu suchen :D
Check ihrer DNS Uplink Server unter "Status --> DNS Resolver" gehört dazu !!
Das habe ich bisher nicht gemacht. Das werde ich mir gleich angewöhnen. Dort sieht man quasi, mit welchen DNS er jetzt wirklich verbunden ist und arbeitet? Ist das korrekt? Dort sollten quasi dann meine selbst zugeteilten von General Setup auftauchen in meinem Fall also 1.1.1.1 und 1.0.0.1 und natürlich die zugewiesenen durch den Provider?
Abschließend für diesen Post möchte allen hier und natürlich auch insbesondere dir meinen großen Dank aussprechen, dass du soviel Zeit aufwendest und mir solch ausführliche Hilfestellung gibst. Ohne euch hätte ich wohl keine Chance das ans Laufen zu bekommen :D Vielen Dank an alle die bisher etwas mehr Licht ins Dunkle meiner Netzwerkkentnisse gebracht haben
Meine Netzwerkkenntnisse wachsen dadurch sehr und mir ist es wichtig zu verstehen und nicht nur irgendwelche HowTo´s abzuarbeiten. Nur das entwickelt einen langfristig in die richtige Richtung.
Scheunentor Regel abgeändert,
Alles richtig gemacht !in meinem Fall also 1.1.1.1 und 1.0.0.1 und natürlich die zugewiesenen durch den Provider?
Wenn du dich von US Diensten abhängig machen willst dann ja. Besser wären EU Dienste wenn man denn schon unbedingt externe DNS Server nutzen will.Die vom Provider dynmisch zugewiesenen überrennst du damit dann. Statische Einträge haben immer Priorität vor dynamischen welche dann nicht mehr genutzt werden.
Vielen Dank
Immer gerne ! 😉
Ich hätte eine weitere Frage was Routing betrifft In diesem fall betrifft es mein Vigor 165 Modem.
Dieses läuft ja im Full Bridge Mode an der pfSense. Ich habe aber zusätzlich am Port 2 ein Netzwerkkabel auf den Switch gehangen. Die Administration soll im VLAN 1 erfolgen also im 10.10.1.0/24 iger Netz. Der Switch hat die IP 10.10.1.1 und der Vigor die 10.10.1.2 bekommen. Gateway kann man im Vigor soweit ich das gesehen habe keines einstellen. Die Vigor IP ist fix da hier auch kein DHCP geht im WebIF.
Wenn ich meinen PC jetzt wieder direkt auf den Port 2 anschließe, komme ich mit der 10.10.1.2 an das WebIF.
Hänge ich das Kabel an den Switchport der auf VLAN 1 läuft, bekomme ich von meinem Client aus dem VLAN 10 keinen Connect auf das WebIF.
Ich kann die VLAN 1 Switch IP 10.10.1.1 vom Client aus pingen. Die Vigor IP 10.10.1.2 nicht mehr.
Am Switch selbst kann ich die Vigor IP 10.10.1.2 schon pingen! Wo liegt hierbei noch das Problem? Das Routing sollte ja über die 10.10.1.1 ganz normal klappen, wie in alle anderen Netze ja auch?!
Ist das Problem, weil der Vigor nicht weiß, dass er über das "Gateway" 10.10.1.1 in mein anderes Client Netz 10.10.10.0/24 kommt?
Im Vigor sehe ich nichts, wo ich dahingehend was eintragen könnte
EDIT: Kommando zurück - auch am Switch geht der Ping nicht durch, wenn ich nicht von VLAN 1 pinge. Das hatte ich letztends wohl nicht beachtet. Also muss es ja noch irgendwo im Switch ein Problem am Routing geben.
In diesem fall betrifft es mein Vigor 165 Modem.Dieses läuft ja im Full Bridge Mode an der pfSense. Ich habe aber zusätzlich am Port 2 ein Netzwerkkabel auf den Switch gehangen. Die Administration soll im VLAN 1 erfolgen also im 10.10.1.0/24 iger Netz. Der Switch hat die IP 10.10.1.1 und der Vigor die 10.10.1.2 bekommen. Gateway kann man im Vigor soweit ich das gesehen habe keines einstellen. Die Vigor IP ist fix da hier auch kein DHCP geht im WebIF.
Wenn ich meinen PC jetzt wieder direkt auf den Port 2 anschließe, komme ich mit der 10.10.1.2 an das WebIF.
Hänge ich das Kabel an den Switchport der auf VLAN 1 läuft, bekomme ich von meinem Client aus dem VLAN 10 keinen Connect auf das WebIF.
Ich kann die VLAN 1 Switch IP 10.10.1.1 vom Client aus pingen. Die Vigor IP 10.10.1.2 nicht mehr.
Am Switch selbst kann ich die Vigor IP 10.10.1.2 schon pingen! Wo liegt hierbei noch das Problem? Das Routing sollte ja über die 10.10.1.1 ganz normal klappen, wie in alle anderen Netze ja auch?!
Ist das Problem, weil der Vigor nicht weiß, dass er über das "Gateway" 10.10.1.1 in mein anderes Client Netz 10.10.10.0/24 kommt?
Im Vigor sehe ich nichts, wo ich dahingehend was eintragen könnte
EDIT: Kommando zurück - auch am Switch geht der Ping nicht durch, wenn ich nicht von VLAN 1 pinge. Das hatte ich letztends wohl nicht beachtet. Also muss es ja noch irgendwo im Switch ein Problem am Routing geben.
In diesem fall betrifft es mein Vigor 165 Modem.
Ein reines Modem arbeitet nur auf Layer 1 max. Layer 2 aber niemals auf dem Routing Layer 3 ! In sofern ist diese Frage ein Widerspruch in sich. Reine Modems können Prinzipen bedingt niemals routen.bekomme ich von meinem Client aus dem VLAN 10 keinen Connect auf das WebIF.
Das ist auch logisch, denk mal selber etwas nach...Modem hat 10.10.1.2 IP und hat KEIN Gateway Eintrag. Nun kommt ein IP Paket am Modem an mit einer VLAN 10 Absender IP 10.10.10.x. Das Modem muss ja nun antworten und sieht für die Rückroute ins 10er Netz in seinem IP Stack nach einem Gateway, denn es muss ja zwangsweise das .10er IP Paket an ein Gateway senden damit es in ein anderes IP Netzwerk geroutet werden kann. Simple Routing Grundlagen...
Wie sollte das deiner Meinung nach ohne ein Gateway Eintrag am Modem funktionieren ? Sieht so auch als ob es hier schon bei den einfachsten Routing Grundlagen bei dir hapert...?!!
Am besten also mal die Routing_Grundlagen hier im Forum genau lesen (besonders den "Packet Walk" !) und vor allem verstehen !!
Mir ist es ja klar, dass es ein Gateway braucht. Aber das Modem hat ja einen extra Administrations LAN Port und im Netz liest man immer wieder, dass es Leute mit einem Switch ans Laufen gebracht haben um aus allen Netzen dahin zu kommen.
Irgendeine Einstellung muss es diesbezüglich also geben?!
Hier z.B. auch nachzulesen.
https://ubiquiti-networks-forum.de/board/thread/353-vigor-165-nicht-erre ...
Man kann im Vigor 165 dieses RIP Protocol Control anschalten am LAN Port. So wie ich das verstehe, kann der Vigor damit vom übergeordneten Netz eine Routing Tabelle anfordern, die ihm eben dann hilft um aus seinem Netz zu kommen?!
Irgendeine Einstellung muss es diesbezüglich also geben?!
Hier z.B. auch nachzulesen.
https://ubiquiti-networks-forum.de/board/thread/353-vigor-165-nicht-erre ...
Man kann im Vigor 165 dieses RIP Protocol Control anschalten am LAN Port. So wie ich das verstehe, kann der Vigor damit vom übergeordneten Netz eine Routing Tabelle anfordern, die ihm eben dann hilft um aus seinem Netz zu kommen?!
Im Gegensatz zum Zyxel VMG Modem https://www.heise.de/select/ct/2020/15/2014807584631309753 das einen wirklichen und isolierten, reinen Management Port hat, hat das Draytek Modem dies nicht !
Der LAN 2 Port ist nicht getrennt vom LAN 1 Port und diesbezüglich ist es fatal diesen ins interne Netz zu stecken, denn damit korrumpiert man seine Security da dieser Port nicht geschützt ist.
Beim Draytek sollte man den 2ten Port also immer unbeschaltet lassen !! Man braucht ihn nicht bzw. nur rein zum Management was aber bei einem reinen Modem NICHT erforderlich ist. Was will man an einem Modem auch aktiv managen ??
Sollte es mal ein Firmware Update geben steckt man das Modem dann einfach temporär an einen Admin Rechner und macht das Update und danach wieder zurück. Fertisch.
Da der 2te Port nicht physisch getrennt ist bleibt die Beschaltung beim Draytek ein unkalkulierbares Risiko.
Will man sowas, ist das Zyxel Modem die technisch weitaus bessere Wahl !
Bitte also nicht Äpfel mit Birnen vergleichen !
Der LAN 2 Port ist nicht getrennt vom LAN 1 Port und diesbezüglich ist es fatal diesen ins interne Netz zu stecken, denn damit korrumpiert man seine Security da dieser Port nicht geschützt ist.
Beim Draytek sollte man den 2ten Port also immer unbeschaltet lassen !! Man braucht ihn nicht bzw. nur rein zum Management was aber bei einem reinen Modem NICHT erforderlich ist. Was will man an einem Modem auch aktiv managen ??
Sollte es mal ein Firmware Update geben steckt man das Modem dann einfach temporär an einen Admin Rechner und macht das Update und danach wieder zurück. Fertisch.
Da der 2te Port nicht physisch getrennt ist bleibt die Beschaltung beim Draytek ein unkalkulierbares Risiko.
Will man sowas, ist das Zyxel Modem die technisch weitaus bessere Wahl !
So wie ich das verstehe, kann der Vigor damit vom übergeordneten Netz eine Routing Tabelle anfordern
Nur wenn er nicht als reines Modem sondern als Router konfiguriert ist !! Ein Modem ist niemals aktiv am IP also Layer 3 Forwarding beteiligt. Es ist ein reiner L1 bzw. L2 Medienwandler.Bitte also nicht Äpfel mit Birnen vergleichen !
Naja nur im Modem sehe ich z.B. die Sync Geschwindigkeit meines VDSL Anschlusses. Oder kann ich die Daten irgendwie "abholen" und z.B. in der pfSense anzeigen lassen?
Ja, guckst du hier:
Hardware für PfSense (DualWan, DDNS, VPN)
Hardware für PfSense (DualWan, DDNS, VPN)
Ich muss also auf dem Interface auf dem jetzt PPPOE drüber läuft ein IP Netzwerk darüber errichten? Verstehe ich das richtig?
Und dann muss aber mein Client wieder im selben Netzwerk sein, wie die IP des Vigor damit ich darauf zugreifen kann, ja?
Mit einer IP aus dem Modemnetz steht da?! Das wäre ja dann quasi aus dem Adressbereich den mir die Telekom zuweist?
Ich verstehe in diesem Thread dort leider echt nur Bahnhof, sorry
Und dann muss aber mein Client wieder im selben Netzwerk sein, wie die IP des Vigor damit ich darauf zugreifen kann, ja?
Mit einer IP aus dem Modemnetz steht da?! Das wäre ja dann quasi aus dem Adressbereich den mir die Telekom zuweist?
Ich verstehe in diesem Thread dort leider echt nur Bahnhof, sorry
Das virtuelle PPPoE Interface und das physische Interface sind 2 unterschiedliche IP Netze. Die Modem Management IP wird über das physische Interface erreicht.
Also du meinst ich muss auf dem Interface in dem Fall das igb0 auf welchem PPPOE läuft, einfach ein 2. darübersetzen so wie im Screenshot?
Ich muss ja dann sicherlich auch noch irgendwo was am Routing einstellen?!
Und wo ist dann der Vorteil gegenüber der Lösung, den 2. Port dafür zu nutzen, außer das ich mir ein Kabel spare?
Ich muss ja dann sicherlich auch noch irgendwo was am Routing einstellen?!
Und wo ist dann der Vorteil gegenüber der Lösung, den 2. Port dafür zu nutzen, außer das ich mir ein Kabel spare?
Jein. Nicht "drübersetzen" sondern druntersetzen...
Das igb0 ist ja das physische Interface auf das dein PPPoE Interface gebunden ist. Du gibst also dem igb0 selber eine IP aus dem Managemenet IP Netz des Vigors eine feste IP und gut iss. Damit kannst du die Vigor IP dann geschützt über die Firewall erreichen.
Abgesehen davon kannst du kein Gateway im Vigor oder Default Route im reinen Modem Betrieb eingeben.
Port 1 und 2 sind beim Vigor intern immer im gleichen IP Netz da sie dort nur per Layer 2 Bridging verbunden sind. Es findet also keine wirklich physische Trennung des Management Ports statt wie z.B. auf dem Zyxel Modem.
Bedeutet dann auch das du das gesamte Internet ungeschützt auch automatisch immer auf dem 2ten Port hast.
Ob man sich dann sowas einfach mal mit einer Patchstrippe ins interne Netzwerk hängt musst du selbst entscheiden. Wenn du mit so einer gravierenden Sicherheitslücke leben kannst...nur zu !
Das igb0 ist ja das physische Interface auf das dein PPPoE Interface gebunden ist. Du gibst also dem igb0 selber eine IP aus dem Managemenet IP Netz des Vigors eine feste IP und gut iss. Damit kannst du die Vigor IP dann geschützt über die Firewall erreichen.
Ich muss ja dann sicherlich auch noch irgendwo was am Routing einstellen?!
Nein ! Denke doch mal selber etwas nach. Du machst doch NAT am WAN Port. Sprich die FW setz alles um auf ihre Absender IP am WAN. Der Vigor "sieht" also IP technisch immer nur die Absender IP des igb0 was ja in seinem eigenen IP Netz ist. Roting ist also nicht nötig.Abgesehen davon kannst du kein Gateway im Vigor oder Default Route im reinen Modem Betrieb eingeben.
Und wo ist dann der Vorteil gegenüber der Lösung, den 2. Port dafür zu nutzen
Das beantwortet schon der gesunde Menschenverstand... Port 1 und 2 sind beim Vigor intern immer im gleichen IP Netz da sie dort nur per Layer 2 Bridging verbunden sind. Es findet also keine wirklich physische Trennung des Management Ports statt wie z.B. auf dem Zyxel Modem.
Bedeutet dann auch das du das gesamte Internet ungeschützt auch automatisch immer auf dem 2ten Port hast.
Ob man sich dann sowas einfach mal mit einer Patchstrippe ins interne Netzwerk hängt musst du selbst entscheiden. Wenn du mit so einer gravierenden Sicherheitslücke leben kannst...nur zu !
Also ich habe jetzt dem neu gebildetem Interface OPT1 von oben die IP 192.168.1.99 gegeben. Der Vigor hat die Static IP 192.168.1.1.
Ich kann jetzt in der pfSense über das OPT1 Interface die IP 192.168.1.1 natürlich anpingen. Über LAN aber nicht.
Ist ja auch klar. Im LAN bin ich mit IP 10.10.10.13 im VLAN 10. Der Gateway vom VLAN 10 mit der IP 10.10.10.1 sagt, diese IP kenne ich nicht.
Geh zur Static Route 0.0.0.0/0 welche auf meine pfSense IP 10.10.2.2 deutet. Dort aber müsste er jetzt in das andere Interface wechseln, da er ja aus dem LAN Interface kommt und der diese Anfrage wohl jetzt über das WAN Interface ins Internet sendet, anstatt auf meinem OPT1 Interface zu gucken.
Wo muss ich dem das noch sagen, dass er diese IP auf dem OPT1 Interface findet damit ich aus meinem LAN Netz immer auf den Vigor komme?
Ich kann jetzt in der pfSense über das OPT1 Interface die IP 192.168.1.1 natürlich anpingen. Über LAN aber nicht.
Ist ja auch klar. Im LAN bin ich mit IP 10.10.10.13 im VLAN 10. Der Gateway vom VLAN 10 mit der IP 10.10.10.1 sagt, diese IP kenne ich nicht.
Geh zur Static Route 0.0.0.0/0 welche auf meine pfSense IP 10.10.2.2 deutet. Dort aber müsste er jetzt in das andere Interface wechseln, da er ja aus dem LAN Interface kommt und der diese Anfrage wohl jetzt über das WAN Interface ins Internet sendet, anstatt auf meinem OPT1 Interface zu gucken.
Wo muss ich dem das noch sagen, dass er diese IP auf dem OPT1 Interface findet damit ich aus meinem LAN Netz immer auf den Vigor komme?
Moin,
habe die letzten 10-15 Posts nicht ganz verfolgt, aber zu deiner letzten Frage
ich tippe, dass in der pfSense noch eine Firewall-Regel fehlt, die es erlaubt, vom 10.10.10.0/24 auf die 192.168.1.99 zu gehen.
Prüfen kannst du das, in dem du
a) vom Client aus ein tracert 192.168.1.99 machst und
b) an der pfSense mal schaust, ob der Zugriff "irgendwo" protokolliert wird.
habe die letzten 10-15 Posts nicht ganz verfolgt, aber zu deiner letzten Frage
Wo muss ich dem das noch sagen, dass er diese IP auf dem OPT1 Interface findet damit ich aus meinem LAN Netz immer auf den Vigor komme?
ich tippe, dass in der pfSense noch eine Firewall-Regel fehlt, die es erlaubt, vom 10.10.10.0/24 auf die 192.168.1.99 zu gehen.
Prüfen kannst du das, in dem du
a) vom Client aus ein tracert 192.168.1.99 machst und
b) an der pfSense mal schaust, ob der Zugriff "irgendwo" protokolliert wird.
Ist ja auch klar.
Nein, das ist Unsinn, denn du verkennst dabei das am idg0 (WAN Port) ja NAT gemacht wird. Adress Translation also auf die dortige 192.168.1.99 IP. Der Vigor "sieht" also gar nichts von einer 10er IP Adresse und denkt durchs NAT der Absender ist im gleichen IP Netz. Fazit: Etwas Nachdenken über den Packet Flow kann immer helfen ! ich tippe, dass in der pfSense noch eine Firewall-Regel fehlt
Kollege @em-pie hat hier Recht. Genauso ist es...Am WAN Port werden im Default immer die RFC 1918 IP Netze geblockt zu denen natürlich auch das 192.168.1er Netz gehört. Ein Blick in das Firewall Log hätte das auch gezeigt.
Um jetzt nicht gleich die Schrotschuss Lösung zu nehmen und global alle RFC 1918 IP Netze zu erlauben (Haken unten am WAN Interface) reicht es dort eine "Erlauben" Regel für die Hostadresse 192.168.1.1 einzurichten. Gewusst wie...
Also sorry, aber mir ist noch immer nicht klar, wo ich diese Regel nun setzen soll und wie er dann aus dem LAN Interface ins "unterlagerte" OPT1 bzw. WAN Interface kommen soll. OPT1 hat die IP 192.168.1.99 bekommen. Der Vigor 192.168.1.1. Somit sind sie im gleichen Netz.
Im Firewall Log der pfSense finde ich keine Einträge wenn ich einen Connect versuche. Dort habe ich natürlich nachgesehen.
Wenn ich auf der pfSense meinen Vigor mit der IP 192.168.1.1 pinge über das OPT1 Interface, dann bekomme ich eine Antwort.
Pinge ich den Vigor auf der pfSense über das LAN Interface, bekomme ich keine Antwort. Ich habe die Regel schon auf dem LAN und auf dem OPT1 Interface versucht, weil mir leider wie ihr immer so schön sagt, der Packet Flow noch nicht ganz klar ist
Im Firewall Log der pfSense finde ich keine Einträge wenn ich einen Connect versuche. Dort habe ich natürlich nachgesehen.
Wenn ich auf der pfSense meinen Vigor mit der IP 192.168.1.1 pinge über das OPT1 Interface, dann bekomme ich eine Antwort.
Pinge ich den Vigor auf der pfSense über das LAN Interface, bekomme ich keine Antwort. Ich habe die Regel schon auf dem LAN und auf dem OPT1 Interface versucht, weil mir leider wie ihr immer so schön sagt, der Packet Flow noch nicht ganz klar ist
wo ich diese Regel nun setzen soll und wie er dann aus dem
Ich habe die Regel schon auf dem LAN und auf dem OPT1 Interface versucht,
Das LAN ist falsch. Regeln gelten immer nur inbound. Am LAN ist ja eh alles erlaubt
Ich raff es einfach nicht :D
Ich habe ein Interface igb0 mit PPPOE für die Interneteinwahl.
Ein 2. Interface mit IPV4 habe ich auf dem physischen igb0 erstellt und dort die IP 192.168.1.99 vergeben. Das Vigor Modem hat die IP 192.168.1.1.
Wie soll jetzt jemals eine Antwort kommen von dem HTTPS Webinterface des Vigors, wenn ich nur die IP 192.168.1.99 ansprechen kann? Mit der 192.168.1.1 wird ja aus dem LAN raus nix gefunden. Das Modem weiß ja nach einer Anfrage keinen Weg zurück zum LAN?!
Im Log tauchen keinerlei Blocks diesbezüglich auf. Weiterhin ist der PING auf dem neu erstellten Interface auf die 192.168.1.1 direkt über die pfSense nur möglich, wenn ich das VIGOR Interface auswähle.
Ich habe ein Interface igb0 mit PPPOE für die Interneteinwahl.
Ein 2. Interface mit IPV4 habe ich auf dem physischen igb0 erstellt und dort die IP 192.168.1.99 vergeben. Das Vigor Modem hat die IP 192.168.1.1.
Wie soll jetzt jemals eine Antwort kommen von dem HTTPS Webinterface des Vigors, wenn ich nur die IP 192.168.1.99 ansprechen kann? Mit der 192.168.1.1 wird ja aus dem LAN raus nix gefunden. Das Modem weiß ja nach einer Anfrage keinen Weg zurück zum LAN?!
Im Log tauchen keinerlei Blocks diesbezüglich auf. Weiterhin ist der PING auf dem neu erstellten Interface auf die 192.168.1.1 direkt über die pfSense nur möglich, wenn ich das VIGOR Interface auswähle.
192.168.1.99 ansprechen kann? Mit der 192.168.1.1 wird ja aus dem LAN raus nix gefunden.
Das geht auch nicht !Wenn du am LAN schon das 192.168.1.0er Netz hast darfst du am WAN Port ja nicht auch das das .1.0er Netz haben. Lernt man in der Grundschule das IP Netze einzigartig sein müssen.
Wie sollte die FW als Router dann auch routen können ?? Sie würde ja die .1.99 immer im lokalen LAN vermuten und niemals via WAN Port gehen. Deshalb sieht man auch nix im Log.
Die Mgmt IP des Vigor bzw. WAN IP darf NICHT im 192.168.1er Netz liegen was gleich dem LAN Netz ist !
Wähle ein anderes ungenutztes RFC 1918 IP Netz dafür, dann klappt das auch sofort.
Mein LAN Netz ist ja nicht 192.168.1.0! Mein LAN Netz sind ja mehrere Netze aus dem 10.10.0.0 / 16er Netz.
Mein MAIN LAN Netz ist das 10.10.10.0.
Die 192.168.1.1 ist ja der Vigor.
Die 193.168.1.99 ist die IP welche im dem Interface igb0 zusätzlich zum PPPOE Interface gegeben habe.
Und ich habe dennoch keine Einträge im Firewall Log und der Website Aufruf HTTPS://192.168.1.1 führt nirgends hin.
Rufe ich die 192.168.1.99 über Chrome auf, lande ich jetzt im Webinterface der pfSense?!
Mein MAIN LAN Netz ist das 10.10.10.0.
Die 192.168.1.1 ist ja der Vigor.
Die 193.168.1.99 ist die IP welche im dem Interface igb0 zusätzlich zum PPPOE Interface gegeben habe.
Und ich habe dennoch keine Einträge im Firewall Log und der Website Aufruf HTTPS://192.168.1.1 führt nirgends hin.
Rufe ich die 192.168.1.99 über Chrome auf, lande ich jetzt im Webinterface der pfSense?!
Das ist ja technisch unmöglich wenn die 192.168.1.99 die Management IP des Vigors ist ! Wenn es die der pfSense ist ist das ja logisch das da dann deren GUI erscheint.
Die Management IP der pfSense ist die 10.10.2.2 !
Die 192.168.1.99 hab ich den extra zusätzlich erstellten Interface auf IPV4 Basis für den igb0 gegeben, wie ihr mir ja geraten habt. Zusätzlich zum eigentlichen PPPOE Interface.
Und der Vigor hat weiterhin die 192.168.1.1.
Die 192.168.1.99 hab ich den extra zusätzlich erstellten Interface auf IPV4 Basis für den igb0 gegeben, wie ihr mir ja geraten habt. Zusätzlich zum eigentlichen PPPOE Interface.
Und der Vigor hat weiterhin die 192.168.1.1.
@ aqui: Wäre das Zyxel VMG3006 die einzige mögliche und damit beste Wahl? Mich stört das doch weiterhin, dass ich nicht einfach mal schnell auf das Modem sehen kann und ich sehe mich daher nach brauchbaren Alternativen um die einen echten getrennten Management Port besitzen.
Gäbe es noch weitere Zyxel oder andere Modems die dafür in Frage kämen?
Vielen Dank schon mal für deine Antwort
EDIT: Es hängt dann an einem Telekom VDSL2 Anschluss mit 50MBit..
Gäbe es noch weitere Zyxel oder andere Modems die dafür in Frage kämen?
Vielen Dank schon mal für deine Antwort
EDIT: Es hängt dann an einem Telekom VDSL2 Anschluss mit 50MBit..
Wäre das Zyxel VMG3006 die einzige mögliche und damit beste Wahl?
Es gibt noch andere die diese Option eines physisch vollkommen getrennten Management Interface Ports auch haben.Das ist eben der Vorteil des Zyxel das hier der Port wirklich physisch vollkommen getrennt ist und keine gefährliche Backdoor darstellt wie der kombinierte zweite Port des Vigor sollte man den an der Firewall vorbei parallel noch ins lokale Netz stecken.
Will man also zwingend immer auch diese permante, lokale Überwachung des Modems wäre es die bessere Wahl.
Aber man kann auch das Management eines Vigors ebenso problemlos normal über den WAN Port erreichen an das es angeschlossen ist. Siehe HIER !
Es ist lediglich das pfSense WAN Port Setup etwas anzupassen !
Also ich habe mich jetzt nochmal an diesem Setup versucht. Ich habe dem Vigor die IP 192.168.99.2 gegeben.
Dann habe ich auf dem PPPOE Interface bzw. auf dem physischen Interface igb0 auf dem PPPOE läuft ein weiteres Interface drauf gesetzt und diesem die IP Adresse 192.168.99.1 gegeben. Das Netz 192.168.99.0/24 ist sonst nirgends in Verwendung.
Ich kann jetzt auf der Firewall den Vigor auf 192.168.99.2 pingen. Außerhalb der Firewall also auf einem Client z.B. kann ich aber nur das Interface selbst mit 192.168.99.1 pingen und den Vigor mit 192.168.99.2 nicht.
Was muss ich hier noch routen damit das dann klappt? Das leuchtet mir leider noch nicht ein.
Achja auf der Firewall habe ich dem Vigor IP Interface noch eine ANY ANY Regel gebaut, damit da nichts blockt.
EDIT: Noch was: Ich hab mein Transfernetz komplett aufgelöst und ich habe jetzt alle VLAN´s als jeweilige Interfaces direkt auf der Sense liegen. Das Routing passiert also nur noch ausschließlich dort.
Dann habe ich auf dem PPPOE Interface bzw. auf dem physischen Interface igb0 auf dem PPPOE läuft ein weiteres Interface drauf gesetzt und diesem die IP Adresse 192.168.99.1 gegeben. Das Netz 192.168.99.0/24 ist sonst nirgends in Verwendung.
Ich kann jetzt auf der Firewall den Vigor auf 192.168.99.2 pingen. Außerhalb der Firewall also auf einem Client z.B. kann ich aber nur das Interface selbst mit 192.168.99.1 pingen und den Vigor mit 192.168.99.2 nicht.
Was muss ich hier noch routen damit das dann klappt? Das leuchtet mir leider noch nicht ein.
Achja auf der Firewall habe ich dem Vigor IP Interface noch eine ANY ANY Regel gebaut, damit da nichts blockt.
EDIT: Noch was: Ich hab mein Transfernetz komplett aufgelöst und ich habe jetzt alle VLAN´s als jeweilige Interfaces direkt auf der Sense liegen. Das Routing passiert also nur noch ausschließlich dort.
Aus welchem Subnetz wird denn schlussendlich auf den Vigor zugegriffen?
Wenn keine NAT Regeln für diese Kommunikation angelegt sind, muss zwingend eine Route auf das zu greifende Subnetz auf dem Vigor angelegt werden.
Hier gibt es allerdings bei der neuen Firmware ein Problem. Dieser Menüpunkt ist nicht mehr verfügbar. Ggf. Ließe sich dies nur über die console einrichten.
Ich schlage daher vor eine NAT Regel auf der Sense anzulegen. Wenn es hier Probleme gibt, kann ich einen Screenshot beisteuern.
Nebenbei, es müssen nachher zwei logische Interface auf der Schnittstelle der Sense angelegt sein solange der Vigor im Bridge Mode betrieben werden soll.
Ich lese mir gleich den ganze Beitrag hier nochmal durch.
Wenn keine NAT Regeln für diese Kommunikation angelegt sind, muss zwingend eine Route auf das zu greifende Subnetz auf dem Vigor angelegt werden.
Hier gibt es allerdings bei der neuen Firmware ein Problem. Dieser Menüpunkt ist nicht mehr verfügbar. Ggf. Ließe sich dies nur über die console einrichten.
Ich schlage daher vor eine NAT Regel auf der Sense anzulegen. Wenn es hier Probleme gibt, kann ich einen Screenshot beisteuern.
Nebenbei, es müssen nachher zwei logische Interface auf der Schnittstelle der Sense angelegt sein solange der Vigor im Bridge Mode betrieben werden soll.
Ich lese mir gleich den ganze Beitrag hier nochmal durch.
Moin,
Also, nachdem ich jetzt alle Beträge hier gelesen habe mal ein paar Punkte die ich kurz aufgreifen möchte.
Im ersten step wolltest du das Route über den L3 Switch laufen lassen. Hier war soweit alles richtig, bis auf das die Sense anscheint keine Routen auf die Netze hinter dem L3 Switch kannte. Diese hätte ergänzt werden müssen und das ganze hätte funktioniert. Korrigiert mich, falls dies doch schon oben irgend wo erwähnt wurde.
Der zweite Punkt ist der für das Management des Vigors.
Früher ließen sich tatsächlich die Route auf das Netz hinter der Sense am Vigor selbst eintragen. Möglicherweise ist das in den letzen Monaten wieder reingepatch worden. Denn diese Funktion gab es in der grafischen Oberfläche in der letzten Version hier bei mir nicht mehr.
Alternativ wie schon erwähnt einfach eine NAT rule an der Sense anlegen. Als Source Subnetz entweder jedes Netz, welches Zugriff auf den Vigor braucht, einzeln oder per Supernetting mit einer größeren Maske. Anbei ein Beispiel für so eine NAT Rule:
1. Interface des Management/Transfer Netzes zu dem Vigor
Mit dieser simplen NAT Rule kannst du dann auf das Interface vom Vigor zugreifen.
Sollte noch irgend was nicht funktionieren und ich es bisher übersehen habe, fass das Thema dann bitte hier nochmal kurz zusammen.
Gruß
Spirit
Also, nachdem ich jetzt alle Beträge hier gelesen habe mal ein paar Punkte die ich kurz aufgreifen möchte.
Im ersten step wolltest du das Route über den L3 Switch laufen lassen. Hier war soweit alles richtig, bis auf das die Sense anscheint keine Routen auf die Netze hinter dem L3 Switch kannte. Diese hätte ergänzt werden müssen und das ganze hätte funktioniert. Korrigiert mich, falls dies doch schon oben irgend wo erwähnt wurde.
Der zweite Punkt ist der für das Management des Vigors.
Früher ließen sich tatsächlich die Route auf das Netz hinter der Sense am Vigor selbst eintragen. Möglicherweise ist das in den letzen Monaten wieder reingepatch worden. Denn diese Funktion gab es in der grafischen Oberfläche in der letzten Version hier bei mir nicht mehr.
Alternativ wie schon erwähnt einfach eine NAT rule an der Sense anlegen. Als Source Subnetz entweder jedes Netz, welches Zugriff auf den Vigor braucht, einzeln oder per Supernetting mit einer größeren Maske. Anbei ein Beispiel für so eine NAT Rule:
1. Interface des Management/Transfer Netzes zu dem Vigor
Mit dieser simplen NAT Rule kannst du dann auf das Interface vom Vigor zugreifen.
Sollte noch irgend was nicht funktionieren und ich es bisher übersehen habe, fass das Thema dann bitte hier nochmal kurz zusammen.
Gruß
Spirit
Danke @ Spirit-of-Eli für deine Antwort
Zu den Punkten oben: Das Layer 3 Switching hat schon funktioniert und ich habe dies auch längere Zeit so betrieben. Ich habe mich aber dann doch gegen das Konzept entschieden und alles wieder umgebaut, da ich z.B. lokale Hostname Resolution in Verbindung mit dem L3 Cisco Switch und der Sense nicht ans Laufen bekommen haben. Daher habe ich das Transfernetz aufgelöst, es aber nie bereut. Jetzt habe ich mit der Sense einen Zentralen und vor allem den Einzigen Punkt in dem ich Zugriffe regeln kann z.B. auch innerhalb der VLAN´s. Das Webinterface des Cisco Switch ist ohnehin so lahm, dass es keinen Spaß macht damit zu arbeiten
Die beiden Interfaces auf dem WAN Port hatte ich schon angelegt und auf der Sense konnte ich den Vigor auch schon pingen. Es lag also tatsächlich nur noch an der fehlenden / falschen Outbound NAT Regel in meinem Fall.
Ich habe es dann deines Beitrags jetzt aber hinbekommen und ich kann auf das Vigor Interface zugreifen Vielen Dank für deine Tips - diese haben mir sehr weiter geholfen. Ich weiß, dass es eigentlich kein technisch anspruchsvolles Problem ist / war, aber ich habe noch immer meine Verständnisprobleme bei dem Outbound NAT. Mir ist da der Paketflow bzw. das Umsetzen der Adressen noch immer nicht ganz klar. Und dann wird es schwierig, die korrekten Regeln zu setzen
Zu den Punkten oben: Das Layer 3 Switching hat schon funktioniert und ich habe dies auch längere Zeit so betrieben. Ich habe mich aber dann doch gegen das Konzept entschieden und alles wieder umgebaut, da ich z.B. lokale Hostname Resolution in Verbindung mit dem L3 Cisco Switch und der Sense nicht ans Laufen bekommen haben. Daher habe ich das Transfernetz aufgelöst, es aber nie bereut. Jetzt habe ich mit der Sense einen Zentralen und vor allem den Einzigen Punkt in dem ich Zugriffe regeln kann z.B. auch innerhalb der VLAN´s. Das Webinterface des Cisco Switch ist ohnehin so lahm, dass es keinen Spaß macht damit zu arbeiten
Die beiden Interfaces auf dem WAN Port hatte ich schon angelegt und auf der Sense konnte ich den Vigor auch schon pingen. Es lag also tatsächlich nur noch an der fehlenden / falschen Outbound NAT Regel in meinem Fall.
Ich habe es dann deines Beitrags jetzt aber hinbekommen und ich kann auf das Vigor Interface zugreifen
Vielen Dank für deine Tips - diese haben mir sehr weiter geholfen. Ich weiß, dass es eigentlich kein technisch anspruchsvolles Problem ist / war, aber ich habe noch immer meine Verständnisprobleme bei dem Outbound NAT. Mir ist da der Paketflow bzw. das Umsetzen der Adressen noch immer nicht ganz klar. Und dann wird es schwierig, die korrekten Regeln zu setzen
Wenn dir das englische nicht ganz fremd ist, hilft das PfSense-Book weiter:
https://docs.netgate.com/pfsense/en/latest/nat/outbound.html
Dieses kannst du auch ohne Probleme herunter laden. Dort ist so ziemlich alles beschrieben.
Ansonsten kannst du die Beiträge hier ja als "zur Lösung beigetragen" markieren.
https://docs.netgate.com/pfsense/en/latest/nat/outbound.html
Dieses kannst du auch ohne Probleme herunter laden. Dort ist so ziemlich alles beschrieben.
Ansonsten kannst du die Beiträge hier ja als "zur Lösung beigetragen" markieren.
Das Webinterface des Cisco Switch ist ohnehin so lahm, dass es keinen Spaß macht damit zu arbeiten
"Richtige" Netzwerker nutzen deshalb auch das CLI des Cisco !! PuTTY mit SSH oder Telnet ist hier wie immer dein bester Freund ! Klasse das es nun klappt mit dem Vigor.
