Vigor 165 - pfSense VM - Cisco Switch 350X-48P - DHCP über pfSense?

Mitglied: TecFr3ak

TecFr3ak (Level 1) - Jetzt verbinden

13.04.2021, aktualisiert 14.04.2021, 1088 Aufrufe, 49 Kommentare

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 ;-) face-wink

Was meint ihr dazu? Wie macht es am meisten Sinn?


Vielen Dank schon mal für eure Antworten :-) face-smile Und bitte seid nachsichtig: Ich bin nur interessierter Hobbyanwender und arbeite nicht in der IT ;-) face-wink
49 Antworten
Mitglied: Looser27
14.04.2021 um 07:42 Uhr
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
Bitte warten ..
Mitglied: em-pie
14.04.2021 um 08:10 Uhr
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
Bitte warten ..
Mitglied: aqui
LÖSUNG 14.04.2021, aktualisiert um 12:56 Uhr
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:
https://administrator.de/tutorial/netzwerk-management-server-mit-raspber ...

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....
Bitte warten ..
Mitglied: TecFr3ak
14.04.2021 um 13:11 Uhr
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?! :-) face-smile
Bitte warten ..
Mitglied: em-pie
14.04.2021 um 13:41 Uhr
Zitat von @TecFr3ak:

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.
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?! :-) face-smile

Bitte warten ..
Mitglied: aqui
14.04.2021, aktualisiert um 13:52 Uhr
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 ?! :-( face-sad
Den Rest hat Kollege @em-pie ja schon erklärt.
Bitte warten ..
Mitglied: TecFr3ak
15.04.2021, aktualisiert um 05:50 Uhr
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?!
Bitte warten ..
Mitglied: em-pie
15.04.2021 um 06:49 Uhr
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.
Bitte warten ..
Mitglied: TecFr3ak
15.04.2021, aktualisiert um 08:33 Uhr
Guten Morgen em-pie :-) face-smile

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 :-) face-smile Vielleicht gibt es da direkt was von Dell?
Bitte warten ..
Mitglied: aqui
15.04.2021, aktualisiert um 10:54 Uhr
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:
l3 - Klicke auf das Bild, um es zu vergrößern
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 !
Siehe dazu auch Layer 3 Tutorial von oben ! Bitte lesen und verstehen...
Hast du auch den DNS in der pfSense korrekt eingestellt ?? Siehe hier:
https://administrator.de/forum/pfsense-web-de-aktiver-scheunentor-regel- ...
Habe ich das soweit korrekt verstanden?
Das hast du korrekt verstanden
Gibt es diese Tools wo ihr immer Netzwerke visualisiert irgendwo frei verfügbar?
Was denn für Tools ?? Was meinst du da ?
Bitte warten ..
Mitglied: TecFr3ak
15.04.2021 um 12:42 Uhr
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.
Bitte warten ..
Mitglied: aqui
15.04.2021 um 15:17 Uhr
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:
https://administrator.de/forum/pfsense-web-de-aktiver-scheunentor-regel- ...
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
Bitte warten ..
Mitglied: TecFr3ak
16.04.2021, aktualisiert um 05:40 Uhr
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 :-) face-smile 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.
Bitte warten ..
Mitglied: aqui
16.04.2021, aktualisiert um 12:41 Uhr
Kommt drauf an wie der Resolver und Forwarder im DNS Setup der pfSense eingestellt sind !!
https://administrator.de/forum/pfsense-web-de-aktiver-scheunentor-regel- ...
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... ;-) face-wink
Bitte warten ..
Mitglied: TecFr3ak
16.04.2021 um 12:58 Uhr
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
Bitte warten ..
Mitglied: TecFr3ak
16.04.2021 um 13:07 Uhr
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?
Bitte warten ..
Mitglied: em-pie
16.04.2021 um 13:32 Uhr
Zitat von @TecFr3ak:

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.

Willst du es, wie oben von @aqui skizziert, über ein Transfernetz regeln, dann reicht der Typ ACCESS
Bitte warten ..
Mitglied: aqui
16.04.2021 um 16:20 Uhr
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... ;-) face-wink
Bitte warten ..
Mitglied: TecFr3ak
17.04.2021, aktualisiert um 12:28 Uhr
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 :-) face-smile

Der Rest sollte jetzt nur noch ein Problem von Blocks in der Firewall sein :-) face-smile DNS auf Port 53 z.B. welchen ich freigeben muss.
Bitte warten ..
Mitglied: aqui
17.04.2021 um 12:28 Uhr
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 :-( face-sad
Ziel: 10.10.0.0, Maske:255.255.0.0, Gateway: 10.10.2.1 (Switch VLAN2 IP)
DAS solltest du dringenst checken !!!
l3 - Klicke auf das Bild, um es zu vergrößern
Bilder ansehen und verstehen hilft !! ;-) face-wink
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 ! ;-) face-wink
Bitte warten ..
Mitglied: TecFr3ak
17.04.2021 um 12:29 Uhr
Sorry ich habe oben eben editiert :D Ich habe wohl die Probleme schon gelöst :-) face-smile

Jetzt muss ich wohl nur noch die Firewall Rules korrigieren :-) face-smile
Bitte warten ..
Mitglied: aqui
17.04.2021 um 12:30 Uhr
Dann mal los...!!
Bitte warten ..
Mitglied: TecFr3ak
17.04.2021, aktualisiert um 17:15 Uhr
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*
Bitte warten ..
Mitglied: aqui
17.04.2021, aktualisiert um 17:32 Uhr
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.
log - Klicke auf das Bild, um es zu vergrößern
Ich habe jetzt mal den Resolver abgeschaltet und den DNS Forwarder aktiviert.
Das ist FALSCH ! Guckst du hier:
https://administrator.de/forum/pfsense-web-de-aktiver-scheunentor-regel- ...
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. :-( face-sad
Bitte warten ..
Mitglied: TecFr3ak
17.04.2021, aktualisiert um 21:11 Uhr
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 ;-) face-wink

Die Firewall mit aktuelle Blocks oben hatte ich bereits eingestellt :-) face-smile

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 ;-) face-wink 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 :-( face-sad
Bitte warten ..
Mitglied: TecFr3ak
18.04.2021, aktualisiert um 12:07 Uhr
Neuer Tag - neues Glück ;-) face-wink

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.
Bitte warten ..
Mitglied: aqui
18.04.2021 um 13:44 Uhr
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.
Das beachten Anfänger oft nicht.
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. :-( face-sad
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 !!
baypass - Klicke auf das Bild, um es zu vergrößern
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
Dein Fehler (oder war es gewollt ?!) in der Regel ist das du das Protokollfenster auf TCP und UDP beschränkt hast. Damit hast du alle anderen Protokolle wie die Steuerprotokolle ICMP z.B. oder IPsec ESP explizit ausgeschlossen. Das ist gerade bezogen auf den Internet Traffic fraglich bzw. hier kommt es darauf an was DU selber für eine Policy fahren willst.
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 ?
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)
  • 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 !
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 !!
res - Klicke auf das Bild, um es zu vergrößern
Achte darauf !!!
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 !!
Bitte warten ..
Mitglied: TecFr3ak
18.04.2021, aktualisiert um 15:54 Uhr
Zitat von @aqui:

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.
Das beachten Anfänger oft nicht.
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. :-( face-sad

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 !

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
Dein Fehler (oder war es gewollt ?!) in der Regel ist das du das Protokollfenster auf TCP und UDP beschränkt hast. Damit hast du alle anderen Protokolle wie die Steuerprotokolle ICMP z.B. oder IPsec ESP explizit ausgeschlossen. Das ist gerade bezogen auf den Internet Traffic fraglich bzw. hier kommt es darauf an was DU selber für eine Policy fahren willst.

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 !
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 ;-) face-wink Also ein paar Basic´s sind mir schon durchaus bekannt ;-) face-wink

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 !
"Standard query response xxxxxxx Refused. Das ist ja wohl das Problem.
Du hast vermutlich im Resolver vergessen DNSSEC abzuschalten !!

Achte darauf !!!

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 :-) face-smile

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.
Bitte warten ..
Mitglied: aqui
18.04.2021, aktualisiert um 18:15 Uhr
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 ! 😉
Bitte warten ..
Mitglied: TecFr3ak
19.04.2021, aktualisiert 20.04.2021
Ich hätte eine weitere Frage was Routing betrifft :-) face-smile 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 :-( face-sad

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.
Bitte warten ..
Mitglied: aqui
20.04.2021, aktualisiert um 15:13 Uhr
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 !! ;-) face-wink
Bitte warten ..
Mitglied: TecFr3ak
20.04.2021, aktualisiert um 11:46 Uhr
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?!
Bitte warten ..
Mitglied: aqui
20.04.2021, aktualisiert um 15:22 Uhr
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 !
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 !
Bitte warten ..
Mitglied: TecFr3ak
22.04.2021 um 10:50 Uhr
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?
Bitte warten ..
Mitglied: TecFr3ak
22.04.2021 um 18:26 Uhr
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 :-D face-big-smile
Bitte warten ..
Mitglied: aqui
22.04.2021 um 22:25 Uhr
Das virtuelle PPPoE Interface und das physische Interface sind 2 unterschiedliche IP Netze. Die Modem Management IP wird über das physische Interface erreicht.
Bitte warten ..
Mitglied: TecFr3ak
24.04.2021, aktualisiert um 12:31 Uhr
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?
interface - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
24.04.2021 um 13:22 Uhr
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.
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... ;-) face-wink
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 !
Bitte warten ..
Mitglied: TecFr3ak
25.04.2021 um 11:39 Uhr
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?
Bitte warten ..
Mitglied: em-pie
25.04.2021 um 12:03 Uhr
Moin,

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.
Bitte warten ..
Mitglied: aqui
25.04.2021, aktualisiert um 13:05 Uhr
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 ! ;-) face-wink
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...
Bitte warten ..
Mitglied: TecFr3ak
27.04.2021, aktualisiert um 08:05 Uhr
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 :-( face-sad
Bitte warten ..
Mitglied: aqui
27.04.2021 um 11:52 Uhr
wo ich diese Regel nun setzen soll und wie er dann aus dem
rfc - Klicke auf das Bild, um es zu vergrößern
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
Bitte warten ..
Mitglied: TecFr3ak
27.04.2021, aktualisiert um 20:46 Uhr
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.
Bitte warten ..
Mitglied: aqui
27.04.2021 um 23:52 Uhr
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.
Bitte warten ..
Mitglied: TecFr3ak
28.04.2021 um 05:54 Uhr
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?!
Bitte warten ..
Mitglied: aqui
28.04.2021, aktualisiert um 09:31 Uhr
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.
Bitte warten ..
Mitglied: TecFr3ak
28.04.2021 um 12:19 Uhr
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.
Bitte warten ..
Heiß diskutierte Inhalte
Windows 10
Wie komme ich von WIN10pro auf Windows 10 Enterprise
LegofrauVor 22 StundenFrageWindows 1058 Kommentare

Guten Tag, Wie komme ich auf legale weiße von Windows 10 professionell auf Windows 10 Enterprise? Ich habe viele widersprüchliche Antworten gefunden. Also muss ...

Off Topic
Bewerbungsfragen FISI
IT-ProVor 1 TagFrageOff Topic16 Kommentare

Hi, Ja, der Titel mag etwas komisch klingen. Aber das wird sich in den folgenden Zeilen hoffentlich lösen. Ich habe mich hier gerade durch ...

Microsoft
Client verhält sich im Home Office wie Gerät vor 10 Jahren
Finchen961988Vor 23 StundenFrageMicrosoft12 Kommentare

Hallo liebes Forum, ich mal wieder und ich habe riesen ??? über den Kopf! Das Verhalten zu beschreiben wird nicht ganz einfach, da ich ...

Linux Netzwerk
NAS läßt sich unter Ubuntu-Server nicht anpingen, unter Windows jedoch schon?!
gelöst dr.zetoVor 3 StundenFrageLinux Netzwerk38 Kommentare

Hallo, ich habe das Problem, dass ich eine Synology-NAS unter einem Ubuntu-Server nicht pingen kann. Unter einem Windows-Client jedoch wird der Ping beantwortet. Hierzu ...

Off Topic
Verwaltungskosten von Passwörtern
IT-ProVor 1 TagFrageOff Topic6 Kommentare

Guten Morgen liebe Menschen. Ich benötigte für die Erstellung meiner IHK-Projektarbeit ein paar Informationen zu den Kosten von Passwörtern. Ich habe aus folgendem Beitrag ...

Windows Server
Remotedesktopgateway Zertifikat - Zugriff überall
lukas0209Vor 1 TagFrageWindows Server9 Kommentare

Guten Abend zusammen, ich habe eine Frage bzgl. des Windows Remotedesktopgateways. Wir nutzen einen Windows Server 2016 Essentials, dieser bringt von Haus aus die ...

CPU, RAM, Mainboards
Laptop schaltet sich von selber aus
winlinVor 22 StundenFrageCPU, RAM, Mainboards4 Kommentare

Hallo zusammen Ich habe ein Laptop der sich nach kurzer Zeit abschaltet. Wenn das passiert und i h den wieder hier hochfahre sehe ich ...

Internet
Starlink SpaceX
chrisittVor 1 TagFrageInternet4 Kommentare

Hallo, ich suche dringend Informationen über Starlink, da wir planen Starlink in einem Unternehmen einzusetzen. Kennt einer von euch eine gute Informationsquelle oder hat ...