Internet auf Interfaces (+ VLAN) sauber durchschleifen
Hallo in de Runde,
ich war bisher fleißiger Mitleser, jetzt wollte ich mich aber nach stundelangem Haareraufen doch mal heraustrauen.
Hoffe ich kann mit meinem bisher Gelernten auch anderen Noobs helfen, wo ich kann.
Bin gerade dabei das Upgrade von Fritzbox 7490 auf OPNsense zu vollziehen.
Die Grundlage dafür läuft auch eigentlich und ich hatte mit VLANS angefangen...
Das mit einem HPE Aruba AP12 und 1830 Switch. Das war ein riesen Fehler, die Verwaltung der Geräte ist ne absolute Zumutung, die schicke ich zurück und besorg mir nen Unifi 6er AP + managed Switch
Was ich dort umsetzen wollte waren VLANS. Ich habe allerdings das Problem gehabt, dass ich kein Internet in den VLANS kriege. DHCP habe ich für alle einzeln aktiviert und die standard VLAN -> Any Regel in der Firewall hinterlegt.
Für die untrusted VLANS noch mit !private networks weiter eingeschränkt und dns in einer Regel davor durchgelassen.
Ich konnte auch munter Clients dran hängen und das hat grob funktioniert.
Habe de AP aber ums verrecken nicht angesprochen bekommen. Und irgendwann hatte ich keine Lust mehr, VLANS gelöscht, Switch wieder raus genommen und in den Karton geschmissen.
Und ab dann hatte ich mit keinem Client mehr Zugriff aufs Netzwerk.
Erst das wieder aktivieren der VLANs brachte mir den Zugriff wieder zurück.
Jetzt steckt halt ein Client (der von dem ich schreibe) direkt im Guest Port an der OPNsense und kommt dann über VLAN Guest rein...
An LAN von der OPNsense hängt eine Fritzbox, die zukünftig als VoIP Cliet arbeiten soll.
Diese funktioniert, aber wenn ich da nen Client anstecke, dann kriege ich keine IP für diesen. Das ging vor dem ganzen VLAN Versuch aber... VoIP läuft ohne Probleme
In der Grafik sieht man noch eine zweite Fritzbox, das ist mein altes Produktivsystem und hängt als "unabhängiger" Router am vierten Port der OPNsense und soll ganz stumpf auf WAN durchgeleitet werden. Irgendwie funktioniert das auch, aber Internet habe ich dort auch nicht zuverlässig. Ein fest verdrahteter Client am Gast LAN der Fritz hat Internet, aber Clients auf dem Wifi der Fritz nicht.
Im ersten Bild der Plan fürs finale Setup
Im zweiten der aktuelle Testaufbau, auf den ich mich jetzt erst mal fokussieren möchte: Internet sauber an beide Fritzboxen und deren Clients brigen
Ist ganz schön zerfahren mittlerweile und ich komme nicht weiter.
Ich vermute ich habe irgendwo das falsche Verständnis davon, wie ich Interfaces, vor allem VLANs, sauber ins Internet bringe...
Könnt ihr mir dabei helfen das noch einmal sauber durchzugehen?
Danke
ich war bisher fleißiger Mitleser, jetzt wollte ich mich aber nach stundelangem Haareraufen doch mal heraustrauen.
Hoffe ich kann mit meinem bisher Gelernten auch anderen Noobs helfen, wo ich kann.
Bin gerade dabei das Upgrade von Fritzbox 7490 auf OPNsense zu vollziehen.
Die Grundlage dafür läuft auch eigentlich und ich hatte mit VLANS angefangen...
Das mit einem HPE Aruba AP12 und 1830 Switch. Das war ein riesen Fehler, die Verwaltung der Geräte ist ne absolute Zumutung, die schicke ich zurück und besorg mir nen Unifi 6er AP + managed Switch
Was ich dort umsetzen wollte waren VLANS. Ich habe allerdings das Problem gehabt, dass ich kein Internet in den VLANS kriege. DHCP habe ich für alle einzeln aktiviert und die standard VLAN -> Any Regel in der Firewall hinterlegt.
Für die untrusted VLANS noch mit !private networks weiter eingeschränkt und dns in einer Regel davor durchgelassen.
Ich konnte auch munter Clients dran hängen und das hat grob funktioniert.
Habe de AP aber ums verrecken nicht angesprochen bekommen. Und irgendwann hatte ich keine Lust mehr, VLANS gelöscht, Switch wieder raus genommen und in den Karton geschmissen.
Und ab dann hatte ich mit keinem Client mehr Zugriff aufs Netzwerk.
Erst das wieder aktivieren der VLANs brachte mir den Zugriff wieder zurück.
Jetzt steckt halt ein Client (der von dem ich schreibe) direkt im Guest Port an der OPNsense und kommt dann über VLAN Guest rein...
An LAN von der OPNsense hängt eine Fritzbox, die zukünftig als VoIP Cliet arbeiten soll.
Diese funktioniert, aber wenn ich da nen Client anstecke, dann kriege ich keine IP für diesen. Das ging vor dem ganzen VLAN Versuch aber... VoIP läuft ohne Probleme
In der Grafik sieht man noch eine zweite Fritzbox, das ist mein altes Produktivsystem und hängt als "unabhängiger" Router am vierten Port der OPNsense und soll ganz stumpf auf WAN durchgeleitet werden. Irgendwie funktioniert das auch, aber Internet habe ich dort auch nicht zuverlässig. Ein fest verdrahteter Client am Gast LAN der Fritz hat Internet, aber Clients auf dem Wifi der Fritz nicht.
Im ersten Bild der Plan fürs finale Setup
Im zweiten der aktuelle Testaufbau, auf den ich mich jetzt erst mal fokussieren möchte: Internet sauber an beide Fritzboxen und deren Clients brigen
Ist ganz schön zerfahren mittlerweile und ich komme nicht weiter.
Ich vermute ich habe irgendwo das falsche Verständnis davon, wie ich Interfaces, vor allem VLANs, sauber ins Internet bringe...
Könnt ihr mir dabei helfen das noch einmal sauber durchzugehen?
Danke
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671059
Url: https://administrator.de/forum/internet-auf-interfaces-vlan-sauber-durchschleifen-671059.html
Ausgedruckt am: 27.02.2025 um 16:02 Uhr
84 Kommentare
Neuester Kommentar
Gut das du dich getraut hast um dich vor weiterem Haarausfall zu bewahren! 🤣
Nur nochmal nachgefragt...
Hast du in Neandertaler Manier jedes VLAN einzeln auf separate Firewall Ports gesteckt??
Wenn ja, warum machst du das nicht sinnvollerweise über einen VLAN Trunk wie es in diesem VLAN Tutorial im Detail beschrieben ist? (Spezifisch für OPNsense hier)
Idealerweise, wenn man wie in deinem Fall mehrere Ports an der FW hat, bindet man den Switch mit einem LACP LAG aus Performance- (Lastverteilung) und Redundanzgründen an.
So sähe ein modernes Layer 2 Konzept mit VLAN Routing über eine Firewall aus! Das was du da oben machst ist gruselige Frickelei. Tutorials lesen und verstehen kann helfen... 😉
Tip:
Spare dir in den Topologie Darstellungen die Endgeräte. Die sind für eine Lösung völlig irrelevant, da es bei dir einzig nur um die Netzwerk Infrastruktur geht. Letztlich macht das die Topologiezeichnung nur unnötig unübersichtlich und eher zu einem wirren "Wimmelbild" wo keiner mehr weiss was gemeint ist. Insbesondere wenn man noch handschriftliche Änderungen einfügt.
Nur nochmal nachgefragt...
Hast du in Neandertaler Manier jedes VLAN einzeln auf separate Firewall Ports gesteckt??
Wenn ja, warum machst du das nicht sinnvollerweise über einen VLAN Trunk wie es in diesem VLAN Tutorial im Detail beschrieben ist? (Spezifisch für OPNsense hier)
Idealerweise, wenn man wie in deinem Fall mehrere Ports an der FW hat, bindet man den Switch mit einem LACP LAG aus Performance- (Lastverteilung) und Redundanzgründen an.
So sähe ein modernes Layer 2 Konzept mit VLAN Routing über eine Firewall aus! Das was du da oben machst ist gruselige Frickelei. Tutorials lesen und verstehen kann helfen... 😉
Tip:
Spare dir in den Topologie Darstellungen die Endgeräte. Die sind für eine Lösung völlig irrelevant, da es bei dir einzig nur um die Netzwerk Infrastruktur geht. Letztlich macht das die Topologiezeichnung nur unnötig unübersichtlich und eher zu einem wirren "Wimmelbild" wo keiner mehr weiss was gemeint ist. Insbesondere wenn man noch handschriftliche Änderungen einfügt.
Moin,
Geh doch einfach mal strukturiert vor und mache VLAN für VLAN…
Eigentlich ein Billiges Setup.
Zur Thematik Trunk/ LAG hat @aqui ja schon was geschrieben
Edit:
Geh doch einfach mal strukturiert vor und mache VLAN für VLAN…
- Kommt die pfSense sauber ins WWW?
- Wenn das klappt, geht es weiter: Kommst du mit dem VLAN 10 bis zur pfSense?
- Nein-> Problem zergliedern und analysieren
- Ja -> kommst du aus dem VLAN 10 ins WWW?
- Nein -> passt das NAT für das VLAN? Stimmen die Firewall-Rules?
- Ja -> weiter mit dem nächsten VLAN
Eigentlich ein Billiges Setup.
Zur Thematik Trunk/ LAG hat @aqui ja schon was geschrieben
Edit:
Ping
, nslookup
und tracert
sind, zusammen mit WireShark deine FreundeHabe ich so angelegt wie in den Anleitungen.
Welche "Anleitungen" denn? In einem VLAN Umfeld nimmt man ja üblicherweise immer einen tagged Uplink dafür.Ich habe sogar ohne extra VLANS schon Probleme befürchte ich...
Uuhhh, das klingt nicht gut. Das macht doch überhaupt keinen Sinn, oder?
In der Tat! Das zeigt das du ganz grundsätzlich irgendwo irgendetwas "verfummelt" hast.Normal ist jegliche Fummelei am Regelwerk völlig unnötig, denn die OPNsense arbeitet wie auch die pfSense "out of the box" direkt nacht der Installation fehlerfrei ohne das man irgendwo etwas am Regelwerk oder sonstwo einstellen oder verschlimmbessern muss!
Die wichtigste Frage ist also WIE deine OPNsense derzeit betrieben wird am WAN Port? In einer Router Kaskade mit einem bestehenden Router davor oder direkt mit einem NUR Modem via PPPoE??
Vermutlich (geraten) betreibst du sie im ersten Step in einer Kaskade an einem bestehenden Router (Fritzbox)?!
Das ist auch eine sehr sinnvolle Vorgehensweise beim Setup, weil du damit dann alles wasserdicht und sauber konfigurieren kannst und später beim Wechsel auf ein nur Modem lediglich nur den WAN Port umkonfigurieren musst.
Es ist also empfehlenswert das du, wie Kollege @em-pie schon gesagt hast, erstmal strukturiert vorgehst und die Firewall auf ihre Werkseinstellungen zurücksetzt und nochmal sauber von vorne beginnst.
Ob du jetzt mit der Kaskade startest oder gleich direkt mit dem Modem spielt keine Rolle.
Wichtig ist das du dieses Default Setup erstmal zum Spielen bringts ohne irgendwelche (überflüssigen) Einstellungen am Regelwerk oder NAT machst.
Über die Diagnostic Tools machst du dann entsprechende, grundlegende Ping und DNS Checks. Besonders indem du bei den Pings als Source IP die LAN Adresse definierst, denn so kannst du wasserdicht testen das auch aus diesem Segment alles klappt wie es soll.
Klappt das alles machst du langsam und struktieriert weiter, denn nur so kannst du erkennen welchen Konfig Fehler du begangen hast. Es ist wenig zielführend wenn man etwas unsicher ist gleich 20 Einstellungen auf einmal zu setzen und dann mühsam den Fehler zu suchen. Alles banale Binsenweisheiten.
Lange Rede... Strukturiert vorgehen und nochmal sauber von Anfang an starten...
Hilfreich ist dafür ggf. das FW Grundlagentutorial. Zwar etwas älter aber die grundlegenden Setup Schritte sind weiter aktuell.
3 VLANs erzeugt und den entsprechenden Interfaces zugeordnet
Ab da kann man schon aufhören zu lesen. So einen Unsinn separate Strippen zu ziehen hat man, wie bereits gesagt, bei den Neandertalern gemacht. Moderne und sinnvolle VLAN Designs nutzen dafür einen VLAN Trunk. Idealerweise in einem LACP LAG.Wenn du es gut und richtig machen willst vergisst du den Unsinn aus dem o.a. Tutorial.
VLAN ist jetzt schon wieder rausgeflogen, weil der Switch rausgeflogen ist.
Das muss ja nicht so bleiben. Es gibt ja außer UBQT noch andere Hersteller mit guten VLAN UIs. Siehe o.a. VLAN Tutorial. Aber ich hatte den VLAN für die Verbindung zum Switch mit 1 getaggt
Vermutlich aus Unwissenheit ein böser Fehler, denn das ist das Default-, Native oder PVID VLAN und in der Regel immer UNtagged!! Auf der OPNsense entspricht das im VLAN Setup dem physischen Parent Interface, dessen Pakete auch immer UNtagged gesendet werden.
Es ist also folglich erwartbar wenn du so einen Kardinalsfehler machst und das PVID VLAN einseitig taggst.
Bitte dazu nochmal in aller Ruhe die VLAN Schnellschulung lesen und verstehen und im VLAN Tutorial den weiterführenden Link zum Thema PVID VLAN!!
Einer der Fehler warum dein VLAN Setup scheitern musste...
Hat auch richtig geswitched, aber halt ohne Internet.
Das ist leider auch so eine typische Freitags Aussage... Was genau ist denn "das Internet". In einem Administrator Forum würde man erwarten das wenigstens ein paar grundlegende Ping Checks gemacht wurden um den Fehler ansatzweise eingrenzen zu können. Das sollte auch ein Anfänger beherrschen.- Im Diagnostics Mode ein nslookup auf einen Hostnamen um die korrekte DNS Auflösung der FW zu checken
- Diagnostics Mode Ping auf einen nackte Internet IP wie z.B. 8.8.8.8 um generell die "Internet" IP Connectivity zu testen
- Das gleiche macht man mit einer auf das LAN Interface gesetzten Absender IP was dann verifiziert das auch über das lokale LAN Interface der Internet Zugang funktioniert
- Die beiden letzten Tests wiederholt man mit einem Hostnamen wie z.B. www.administrator.de
- Korrekte IP Adressierung mit ipconfig -all
- Ping des Firewall LAN Interfaces
- Ping einer Internet IP 8.8.8.8
- Ping eines Hostnamens
Es funktioniert ja im Serien Trim alles.
Wer oder was ist "Serien Trim"?? 🤔und auch mal 1.1.1.1 oder 8.8.8.8 als DNS Server benutzt.
Googles Schnüffel DNS benutzen heute nichtmal mehr Dummies aus gutem Grund. Warum nicht den DNS deines Provider oder wenn man unbedingt meint externe nutzen zu müssen dann Vertrauenswürdige.ich kanns auch nochmal ganz frisch machen wenn nötig.
Deine Entscheidung... Zu deinen "Sorgen":
Einmal die beiden Fritzboxen zum Laufen kriegen
Wozu 2 Fritten?? Reicht nicht eine als VoIP Anlage? Zäume aber nicht das Pferd von hinten auf!! Die Fritte ist als VoIP Anlage erstmal nur ein unwichtiges Endgerät.Fange sinnvollerweise mit deiner eigentlichen Netzwerk Infrastruktur zuerst an! Eine funktionierende Infrastruktur ist das sichere Fundament ALLER Funktionen. Folglich kommt das zuerst!
und dann nen Switch + AP in VLANs am LAN Port.
OK, das alles erklärt dir, wie schon gesagt, das VLAN Tutorial haarklein im Detail inklusive diverer Switch Setups. Viel mehr "Silbertablett" zum fertigen Abtippen geht da nicht.Sorge 1a:
Es werden ein paar Sachen geblockt wie Discord und der Bildversand/empfang bei Whatsapp
Das lässt eher auf ein DNS Problem schliessen. Möglich das dein Adguard dazwischen ist und diese Apps filtert oder du einen (überflüssigen) externen DNS Dienstleister nutzt der Filtert oder was auch immer.Lasse erstmal nur die Firewall als Caching DNS laufen mit dem per PPPoE dynamisch vom Provider gelernten DNS Server. Hier checkst du mit nslookup auf einem Test PC die DNS Funktion. Das "Diagnostic" Menü lässt grüßen...
Sorge 1b:
Die alte Fritzbox soll quasi nur das Modem mitbenutzen bzw die vorhandene Einwahl.
Das ist schon seit langem nicht mehr supportet von AVM!Das Einzige was noch klappt ist ein PPPoE Passthrough das sie quasi PPPoE Traffic ans xDSL Modem durchreicht. Das wird aber auch zu 99% scheitern weil Provider in der Regel keine 2 PPPoE Sessions parallel erlauben. Das kannst du also sehr wahrscheinlich vergessen.
Wozu auch eine 2te Fritte??
Eine als reinen VoIP Client den du im IP Client Mode konfigurierst für die interne Nutzung im lokalen LAN reicht doch. Wozu also eine 2te Fritte?
Dafür läuft es im Router Modus mit Uplink auf LAN 1, angeschlossen an den vierten Port der OPNsense.
Du sagst ja ein Test PC an diesem "vierten Port" rennt fehlerfrei inkl. Internet Zugang??Wenn der Test PC Internet Zugang hat dann wird auch eine dort angeschlossenen Fritte den haben.
Hilfreich ware mal das Dashboard der Fritte dann zu checken! Dort steht doch welche IP sie von der OPNsense gezogen hat, Gateway und DNS!
Wichtig ist natürlich das das lokale LAN dieser Fritte nicht mit anderen IP Netzen der Firewall identisch ist!! Du musst sicherstellen das ALLE deine IP Netze einzigartig sind. Das gilt insbesondere für die Fritten Adressierung inkl. ihrer Gastnetze! Die dürfen niemals doppelt vorkommen!
Nur wozu soll das generell gut sein daran eine weitere Fritte zu betreiben? 🤔
Das ist als Guest LAN eingerichtet
WAS genau soll das sein?? Die Firewall selber kennt kein "Guest LAN"!Sorge 2:
Ich denke das Tagging war nicht das Problem
Leider doch, denn wenn man das PVID VLAN einseitig fälschlicherweise tagged ist das Scheitern vorprogrammiert! Und...bitte nicht immer dies "kein Internet" sondern eine etwas profundere Analyse des Warum!! 🙄
Grundsätzlich konnte ich ja einen Client an einem untagged 1 Port anstecken
Auch an einem tagged Port, denn der überträgt ja immer das Native VLAN (PVID) untagged. Über dieses PVID VLAN hast du also auch an einem Tagged Port immer Verbindung. Was hier aber gefehlt hat war das Internet, was der AP zwingend zur Ersteinrichtung verlangt
Wieso, bitte sehr, benötigt ein simpler WLAN AP "zwingend" Internet?? Kein AP braucht sowas und hat immer ein eigenes, lokales WebGUI an Bord über den sowas auch OHNE Internet konfiguriert wird! Nur Dummies beschaffen sich APs oder Infrastrukturgeräte mit Schnüffelfunktion in eine (Chinesen) Cloud! Hat jemand die Muße mich an die Hand zu nehmen?
Das tun wir hier ja schon! Sorge zuallererst einmal dafür das deine eigentliche Netzwerk Infrastruktur sauber und fehlerfrei rennt. Sprich "Sorge 1a und b" fixen. Mit dem o.a. VLAN Tutorial und seinen vielfältigen Beispielen sollte das ja auch für einen Anfänger kein Problem sein! Ansonsten immer zielgerichtet hier fragen.
Was mir als erstes auffällt (sofern die alte Fritte wirklich im RouterModus läuft):
WAN und LAN haben dasselbe IP-Netz.
Stell mal die LAN-Seite auf z.B. 192.168.200.0/24 um
Die Fritte weiß ja sonst gar nicht, wohin mit den Paketen.
Was allerdings gegen den RouterModus spricht: dein Client bekommt eine IP von der Sense. Das passiert nur, wenn die Fritte als IP-Client arbeitet. Dann ist sie nur eines von vielen „Endgeräten“ im LAN.
Wenn du eine IP bekommst, während das Kabel zwischen Fritte und Sense aufgestöpselt ist, ist es per se erstmal gut. Wenn nicht, bist du im Client-Modus…
Zu den NAT-Settings selbst kann ich zur Sense nichts sagen. Hatte die bisweilen noch nicht in den Fingern…
WAN und LAN haben dasselbe IP-Netz.
Stell mal die LAN-Seite auf z.B. 192.168.200.0/24 um
Die Fritte weiß ja sonst gar nicht, wohin mit den Paketen.
Was allerdings gegen den RouterModus spricht: dein Client bekommt eine IP von der Sense. Das passiert nur, wenn die Fritte als IP-Client arbeitet. Dann ist sie nur eines von vielen „Endgeräten“ im LAN.
Wenn du eine IP bekommst, während das Kabel zwischen Fritte und Sense aufgestöpselt ist, ist es per se erstmal gut. Wenn nicht, bist du im Client-Modus…
Zu den NAT-Settings selbst kann ich zur Sense nichts sagen. Hatte die bisweilen noch nicht in den Fingern…
Am Anfang aber wohl erst mal gar nicht, weil ich da dann nur ein einziges VLAN nehmen werde bis alles läuft.
Ja, das ist der richtige Weg!- Du belässt erstmal den Default LAN Port um einen sicheren Zugang auf das Konfig GUI der Firewall zu haben falls ein Konfig Fehler passiert.
- Dann kasperst du 2 Ports aus die du in einen LACP LAG laut o.a. Tutorial bringst.
- Den LAG aktivierst du im Interface Assignement
- LAG Interface IP und DHCP setzen bzw. aktivieren. Damit arbeitet dann das virtuelle LAG Interface als Native UNtagged Port also als PVID VLAN und ist dann das Parent Interface für die weiteren VLANs die du anlegst.
- LACP LAG auf dem Switch konfigurieren und das LAG Interface des Switches einem separaten VLAN zuweisen. Das ist wichtig um hier nicht einen Loop zu schaffen mit dem VLAN 1 weil dort vermutlich dein LAN Interface arbeitet. LAN und das neue LAG Interface sind auf der Firewall 2 getrennte IP Netze und müssen folglich auf dem VLAN Switch ebenfalls strikt getrennt sein, sprich in unterschiedlichen VLANs liegen.
Wenn du unsicher bist kannst du dir die LAG Geschichte auch erstmal sparen und im ersten Schritt behutsam vorgehen und zu Anfang nur mit einem singulären Trunk Port arbeiten um in Ruhe das Handling damit zu lernen.
Dann gehst du wie oben oder Tutorial vor und lässt den LAG erstmal weg und nimmst nur einen einzelnen Port. Schritte sind die gleichen
- Port an der FW auskaspern, im Assignement aktivieren
- IP und DHCP auf dem Port aktivieren
- Port ist UNtagged und in ein Trunk Mode Port des Switches stecken auch hier auf das separate VLAN achten!
- Dann weitere VLANs auf dieses Interface mappen in der FW und tagged auf dem Switch einrichten
aber der Aruba Kram ist eine Frechheit.
Na ja das weiss man aber vorher das die besser Drucker und Laptops können. Von Netzen haben die keine Ahnung. Das ist alles ein zugekaufter Zoo von Fremdfirmen was die haben, nichts Eigenes. Da gilt immer Finger weg.Witzigerweise war mein erstes VLAN die #10 statt der 1, aber tagged.
Nein, ganz sicher nicht, denn diese Aussage ist bei einem VLAN Switch immer unsinnig, sorry!Das erste VLAN ist immer das Default VLAN 1 auf einem Switch was immer vorhanden ist und man auch nicht löschen kann. Es ist das Native oder PVID VLAN in dem per Default alle Ports UNtagged hängen. Das Native- oder PVID VLAN wird niemals getagged. Das war schon ein Kardinalsfehler von dir.
Alle weiteren, zusätzlichen VLANs werden dann entweder UNtagged betrieben auf einem Access Port für Endgeräte oder eben Tagged auf einem Trunk Port. (Siehe VLAN Schnellschulung!)
Mit kein Internet meine ich hier prinzipiell Zugang auf die OPNsense und die Fritzbox dazwischen
Wieder so ein verwirrender Unsinn, sorry! - Die OPNsense blockt per se gar nichts ins Internet im Default Setup
- Du hast am WAN/Internet Port keine Fritzbox dazwischen sondern ein reines Modem
- Eine Fritzbox in einem internen LAN Segment verhält sich wie ein Endgerät (PC, Drucker etc.) auch der Traffic wird von der OPNsense im Default NICHT geblockt.
Habe ich doch beschrieben, eine (FritzAlt) ganz dumm im Hintergrund als Fallback Lösung
Das funktioniert so nicht wie du das umgesetzt hast und ist der völlig falsche Ansatz. Du musst dann eine Multi WAN Lösung umsetzen die alternierend mal den einen mal den anderen WAN/Internet Port nutzen kann je nach Zustand der Leitung.https://docs.opnsense.org/manual/how-tos/multiwan.html
https://www.thomas-krenn.com/de/wiki/OPNsense_Multi_WAN
Wie bereits gesagt. Als Anfänger nicht gleich die Saturn V zünden sondern mit einer kleinen Sylvesterrakete anfangen und es im ersten Schritt erstmal bei einem WAN Port belassen!! Bringe erstmal deine lokale VLAN Infrastruktur zum Fliegen und wage dich dann an andere Dinge aber nicht gleich alles auf einmal!! 🧐
Meine für den Anfang sichere Struktur sollte so aussehen:
Vielleicht lieferst du dazu nochmal eine saubere Topologiezeichnung ohne Wimmelbild damit wir alle wissen was dein genaues Ziel ist.Wenn DNS überall leer dann nimmt er den vom Provider?
Ja!Es gibt neben dem PPPoE Passthrough auch den Betrieb als Router, der auf LAN 1 von einem Modem Internet bekommt. Dann sind auch noch sämtliche Schutzfunktionen an + Gäste Lan, Gäste Wifi, VPN. Sogar VoIP geht.
Ja, kennt jeder Laie und Administratoren sowieso. Das ist der sog. "Modem Bypass" Mode der Fritte. Was dort gemacht wird ist schlicht und einfach das Modem deaktiviert und umgangen und der Internet Port im "DHCP Client Mode" direkt auf den LAN 1 Port gelegt. Kennt jeder....Wie man einen WLAN Router in einen einfachen Accesspoint verwandelt erklärt dieses Tutorial. Sollte man aber besser nicht machen sondern immer dedizierte Accesspoints betreiben wie z.B. diese oder andere.
Hatte gedacht, dass die OPNsense sich um DHCP kümmert und die Clients von der Fritzbox den Server (Opnsense) mitgeteilt bekommen.
Nicht denken sondern nachdenken... DHCP funktioniert nur in einem Layer 2 Netz da es bekanntlich auf Broadcasts basiert. Router leiten aber prinzipbedingt keine Broadcasts in andere IP Segmente. Der tiefere Sinn übrigens warum man Router und Firewalls zur Segmentierung einsetzt. Ein Router arbeitet auf L3 (IP) und ist keine L2 Bridge. Sonst hiesse er auch "Bridge".Also NEIN, deine Fritte kann kein DHCP weiterleiten! Schlimmer noch, der DHCP Server und der der Firewall laufen beide parallel Amok im Netz. Ein NoGo.
Bei DHCP gilt immer das "Highlander Prinzip": Es kann nur einen geben!!. Du musst also einen DHCP Server abschalten, entweder Fritte oder Firewall, denn 2 dürfen niemals parallel laufen.
Noch viel lernen du noch musst... würde Meister Yoda da sagen...
Trotzdem war natürlich der Fehler da, das ganze im Uplink Port am Switch zu Taggen.
Vermutlich hast du es noch immer nicht genau verstanden...?!An einem Uplink / Trunk Port ist es schon richtig diese VLANs zu taggen. Wie sollte die VLAN Information sonst übertragen werden? Das was aber nie getagged werden darf ist das PVID VLAN (Parent Interface der Firewall, Native VLAN) an diesem Uplink / Trunk Port.
Oder meintest du damit dein erstes "Neandertal" VLAN Konzept indem du alle VLAN Strippen einzeln ziehst??
In dem Falle wäre das dann in der Tat falsch, denn das dürfen dann natürlich immer nur UNtagged Ports sein. Aber wer lebt heutzutage noch im Neandertal mit Feuer und Keule?? 🤣
Den Bypass gibt es nicht mehr bei den neueren Fritten.
Das ist Unsinn, denn das ist die LAN 1 Umleitung des WAN Ports. Auch auf modernsten Fritten ist das logischerweise noch verfügbar. Mit dem Bypass hättest du ja die Möglichkeit das Modem der Fritz zu benutzen
Nein! Das Modem wird in dem Mode komplett abgeschaltet wie oben schon gesagt!Aber egal, das alles tut jetzt, wie du schon richtig sagst, hier für eine zielführende Lösung für dich erstmal nichts zur Sache.
Also, DHCP für das FW Interface deaktivieren und auf der Fritzbox aktivieren, korrekt?
Nein! Du solltest gar nicht mehr mit DHCP auf der Fritte arbeiten. Das sollte zentral immer nur die Firewall machen um sich nicht mit dem Setup zu verzetteln.Der DHCP Server auf der Fritte darf nur da laufen wenn du eine Fritte per LAN 1, Modem Bypass an einen Firewall Port klemmst.
Endgeräte am LAN Port der Fritte würden sonst keine IP bekommen. Hier gilt dann die berechtigte Mahnung des Kollegen @em-pie von oben das WAN IP Netz (Firewall Port) und LAN IP Netz der Fritte nicht gleich sein dürfen und auch nirgendwo sonst noch an der Firewall auftreten dürfen!
Also als Beispiel für so ein Setup:
- IP Netz des Firewall Ports an dem die Fritte mit WAN (LAN 1) angeschlossen wird = 192.168.200.0 /24
- LAN IP Netz der Fritte = 192.168.178.0 /24
- Beide Netze dürfen nicht noch woanders an der Firewall auftauchen!
https://de.wikipedia.org/wiki/Private_IP-Adresse#Private_Adressbereiche
So kann es niemals eine Dopplung oder Überschneidung geben und man kann schon beim Management und Troubleshooting sicher unterscheiden wer was ist! Eben intelligent adressieren...
Am Trunk Port 1 der FW fehlt oben wieder das Native VLAN sprich das IP Netz des Parent Interfaces! 
Es sei denn du willst das nicht konfigurieren. Das wäre aber blöd weil du dich so um eine UNtagged Zugangsoption bringst wie oben schon mehrfach besprochen!
Es wäre also intelligent das Trunk Parent Interface auch mit einer IP Adresse zu versehen!! Idealerweise mit einer VLAN 1 IP was dann aber erzwingt das dann das Default LAN Interface als "Notzugang" in ein separates VLAN z.B. 99 gelegt werden muss damit das getrennt ist.
Macht Sinn und dafür kannst du als WAN (LAN 1) Koppelport der Fritte dann das LAN Interface nehmen (neu 99) was dann so oder so eine Scheunentorregel hat.
Ein Bild sagt mehr als 1000 Worte... So sähe z.B. ein gangbares Design aus:
Der "Notfall Konfig" LAN Port kann später entfallen wenn der Trunk sauber funktioniert, denn dann kann der Trunk/Uplink natürlich zur FW Konfiguration genutzt werden. Den freiwerdenden Port kannst du dann als Memberport für einen LACP LAG Firewall<->VLAN-Switch verwenden.
Es sei denn du willst das nicht konfigurieren. Das wäre aber blöd weil du dich so um eine UNtagged Zugangsoption bringst wie oben schon mehrfach besprochen!
Es wäre also intelligent das Trunk Parent Interface auch mit einer IP Adresse zu versehen!! Idealerweise mit einer VLAN 1 IP was dann aber erzwingt das dann das Default LAN Interface als "Notzugang" in ein separates VLAN z.B. 99 gelegt werden muss damit das getrennt ist.
Verstehst du den Gedanken?
Ja, verstanden!Macht Sinn und dafür kannst du als WAN (LAN 1) Koppelport der Fritte dann das LAN Interface nehmen (neu 99) was dann so oder so eine Scheunentorregel hat.
Und das versteh ich nicht glaube ich...
Hast du aber schon dennoch richtig verstanden. Wenn die Fritte als stinknormaler NAT Router an der FW arbeiten soll dann hast du natürlich Recht, dann muss die Fritte auch DHCP Server für ihr LAN spielen.Ein Bild sagt mehr als 1000 Worte... So sähe z.B. ein gangbares Design aus:
Der "Notfall Konfig" LAN Port kann später entfallen wenn der Trunk sauber funktioniert, denn dann kann der Trunk/Uplink natürlich zur FW Konfiguration genutzt werden. Den freiwerdenden Port kannst du dann als Memberport für einen LACP LAG Firewall<->VLAN-Switch verwenden.
ich muss, sobald ich einen Switch betreibe, ALLES über VLANS machen
Nein müssen musst du gar nichts. Du kannst natürlich bei 3 Netzen auch 3 Strippen einzeln ziehen und dir pro Netz einen eigenen Switch anschliessen. DU bist doch der Admin und bestimmst wie dein Netz aussehen soll?! Wo ist der Unterschied zwischen 1 und 99?
Gegenfrage: Wo ist der Unterschied zw. 1 und 4095?? (Die ganze VLAN ID Range)?Eine rein kosmetische Frage die du nach deinem eigenen, persönlichen Geschmack beantworten kannst.
Aber die IP vom Interface muss dann zur manuell gesetzten IP der Fritte passen, korrekt?
Nein, das ist leider NICHT korrekt denn, wie jedermann weiss, ist bei einem Modem Bypass auf der Fritte deren LAN 1 Port (WAN/Internet Port) und dortige IP Adresse nicht statisch konfigurierbar! Der Port arbeitet fest im "DHCP Client Mode", zieht sich also eine IP von der Firewall. Man muss also sicherstellen das dort ein DHCP Server rennt auf der Firewall. Die Fritte wird ja mit ihrem WAN, sprich LAN-1 Port an die Firewall angeschlossen!Wenn man den 99er entfallen lässt, dann schickt man die "roten Clients" auf die 1?
Ja und nein.Du hast ja 2 Optionen:
- Einmal löschst du das 99er VLAN und damit den LAN Port komplett bzw. nutzt ihn wenn du willst als LACP LAG Memberport
- Ob man dann mit dem LAP/Uplink Parent IP Netz (VLAN 1) arbeitet oder das VLAN 99 zusätzlich noch tagged mit über den Trunk/Uplink sendet ist rein persönliche Geschmackssache.
Hat die Klasse B nen Grund?
Oha, du lebst vermutlich doch in der Netzwerk Steinzeit?! Netzwerk "Klassen" gibt es seit über 30 Jahren NICHT mehr. Wir befinden uns seitdem im Zeitaler der CIDR Netze!!
https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Lesen und verstehen...!
Mal abgesehen davon hast du wohl auch Probleme im Umgang mit Netzwerkmasken denn ein 12 Bit Prefix entspricht nicht der damaligen Class B (16 Bit) aus der Netzwerk Steinzeit. Meister Yoda lässt grüßen...
https://de.wikipedia.org/wiki/Netzmaske
Finde Klasse A viel besser zum merken/eintippen
Dann nutzt du eben die...Die hast die freie Auswahl und es ist alles eine Frage des persönlichen (Adress) Geschmacks solange nur die IP Netze einzigartig bleiben! Und...bitte lasse den altertümlichen "Klassen" Unsinn (Siehe oben)
Plan für die IPs:
Kann man so machen.Einen fatalen Fehler musst du noch korrigieren!! Das mögliche LAG Interface ist virtuell ein Interface und folglich dann mit einer einzigen Interface IP adressiert!!
Die Memberports werden NICHT einzeln adressiert. (Bitte Tutorial dazu genau lesen und verstehen!)
Die Bezeichnung "WAN Port" benutzt du leider wirr und irreführend.
Gemeinhin ist damit immer der eigentliche WAN/Internet Port der Firewall gemeint. Also der Port mit der die Firewall direkt am Internet hängt. Bei dir also der Modemport in Richtung Internet.
Hier solltest du sinnvolle und eindeutige Bezeichnungen im Thread benutzen um die Community hier nicht grundlos in Irrwege zu schicken!
Und dann hänge ich alle trusted Clients an unttaged Ports ins VLAN 1?
Kann man so machen...Was trusted ist und was nicht bestimmst doch immer DU selber mit dem Regelwerk an der Firewall!! Genau deshalb hat man sie ja.
Ich wollte ungern noch ein extra Management VLAN eröffnen
Das musst und solltest du auch nicht.Wenn der Trunk/Uplink auf den Switch sauber rennt hast du ja prinzipiell über ALLE VLANs Konfigurationszugriff auf die Firewall.
Der LAN Port ist lediglich ein "Notfall Port" für das Setup sofern du auf dem Trunk/Uplink oder später mal LAG Interface einen Konfig fehler gegehst und dich selber vom FW Management aussperrst. Über das LAN Interface hast du dann immer noch Zugang um diese Fehler zu korrigieren.
Später wenn alles rennt kannst du das LAN Interface bzw. dessen Port dann entfernen. Sollte die FW mal kollabieren bekommst du sie immer über das Backup in Minuten wieder zum Fliegen.
Also funktionieren tut das alles noch nicht mit der Fritzbox...
Funktioniert denn das Grundsetup der Firewall an sich?? Ping Checks, DNS etc.?Ich hab jetzt mal das Interface auf 177.2 geändert
Das 177.2er Netz ist kein privates RFC 1918 IP Netz und sollte niemals verwendet werden da es NICHT dir sondern der brasilianischen Telekom gehört!! inetnum: 177.0.0.0/14
aut-num: AS8167
country: BR
owner-c: SEIVT2
nserver: ns03-cta.brasiltelecom.net.br
person: Brasil Telecom S. A. - CNRS
country: BR
Tip:
Screenshots deines vermutlich falschen FW Setups könnten allen helfen deinen vermeintlichen Fehler zu finden.
Was brächte mir das separate 99er, was das1er nicht kann?
Nichts, da hast du Recht. Deshalb kannst du das vollständig entfernen wenn der Trunk rennt.Aber benutzen kann ich es trotzdem
Sagen wir mal so: Ein guter Netzwerk Admin macht sowas aus guten Gründen niemals. Ganz besonders weil es vollkommen unnötig ist.Du weiß was ich meine, oder?
Nein, nicht wirklich weil nicht klar ist WIE du die Fritte(n) an die Firewall adaptierst.Ich frag nur, warum das überhaupt als VLAN laufen soll.
Ein klein wenig in Ruhe Nachdenken kann hier helfen! Es läuft ja nirgendwo als VLAN wie du aus der Skizze selber ersehen kannst. Logisch, denn sowohl der LAN Port der Firewall als auch der dazu korrespondierende Anschlussport des Switches laufen als Access Port UNtagged und haben damit keinerlei VLAN Information. Stinknormaler UNtagged Traffic also mit Pakete ohne jegliche VLAN Information...
Der Einzige der ansatzweise etwas von VLANs weiss ist einzig und allein der Switch, denn dessen "Accessport" Konfig hat eine statische Zuweisung auf die PVID 99 die besagt: "Forwarde alles was hier ohne einen VLAN Tag reinkommt, also ohne jegliche VLAN Information ist, in das VLAN 99.
Mit anderen Worten:
Da läuft nix als VLAN oder wenn dann nur ein klein bisschen auf dem Switch, denn dem musst du ja logischerweise an seinem Port statisch sagen WO er mit Netzwerk Paketen ohne VLAN Information hin soll. Woher sollte er das denn auch sonst wissen wenn nicht vom Admin und seiner Konfig?! KI innerhalb des Switches, die das von deiner (Admin) Stirn ablesen könnte, gibt es ja (noch) nicht.
Solche einfachen Binsenweisheiten und Vorgänge sagen einem doch auch der gesunde IT Verstand!
Fehler in deiner FW Konfig:
- Ein WAN Port mit einem PPPoE Nur-Modem hat keine statische IP Adresse! Die WAN/Internet IP Adresse liegt einzig und allein nur auf dem virtuellen PPPoE Interface was durch die Konfig geschaffen wird. Eine statische RFC 1918 IP ist zudem sicherheitstechnisch fatal dort. Ein NoGo.
- Der Port "Alte-Fritz" hat eine falsche IP Adressierung. Es wäre fatal hier das Default Allerwelts Fritzbox Netz zu verwenden, denn das bedingt immer eine Überschneidung und Adresschaos mit Fritzboxen. Das Kind ist ja unten schon in den Brunnen gefallen mit deiner 178er Adressierung im Fritten Screenshot. Genau aus dem Grunde wurde dir oben mehrfach empfohlen auf der Firewall ausschliesslich nur 172.er Netz oder weil DU es schöner findest 10.er Netze zu verwenden um solche Doppelvergabe sicher zu vermeiden. Warum hälst du dich nicht an deine eigenen Planung und klebst wie Kaugummi an den 192er Netzen?! Sowas lernt man in der IP Adress Grundschule...
- Ein Riesenfehler ist die DHCP Adressrange bei einem /24er Prefix in dem Bereich .1 bis .254 zu legen. Ein fataler Anfängerfehler der durch fehlendes Nachdenken passiert!!
Damit überstreicht der Bereich auch die statisch vergebenen Adressen und es kommt unweigerlich zum Adresschaos im Netz durch Doppelbelegung von Hostadressen. Gute Adminstratoren lassen die "Netzenden" immer frei im Pool um so Sicherheit für Router Adressen und andere statisch vergebene Adressen zu schaffen!! Setze also die DHCP Range immer mit einem intelligenten "Sicherheitsabstand" z.B. von .10 bis .240.
- Deine LAN Rule ist mit Verlaub gesagt Blödsinn. Bei Regeln gilt immer: First match wins!. Sprich beim ersten positiven Hit im Regelwerk wird der gesamte Rest NICHT mehr abgearbeitet! Wenn du also in der ersten Regel schon alles erlaubst triggert das den positven Hit und deine folgende Fritten Adress Regel wird niemals mehr abgearbeitet, ist allso völlig wirkungslos und überflüssig. Zeigt das du leider das FW Grundlagen Tutorial NICHT gelesen oder verstanden hast.
Fazit: Lasse den Unsinn mit der Fummelei an den Regeln und belasse die alle im Default wie sie sind. Am Default Regelwerk muss man nichts ändern. Die FW rennt damit fehlerfrei!! Setze zum initialen Testen der FW lediglich zuallererst die Regeln der neuen Interfaces auf: PASS, Prot:IPv4/IPv6, Source: <Port_net>, Destination: ANY so das erstmal ALLER Traffic aus dem Netzsegment geforwardet wird. Damit checkst du erstmal dein Gesamtkonstrukt und erst NACHHER machst du dann die Schotten dich die du dichthaben willst. Mit dieser intelligenten Vorgehensweise stellst du sicher das das gesamte Routing und IP Handling sauber funktioniert und spätere Fehler lediglich am Regelwerk liegen können wie z.B. dein Reihenfolge Fehler von oben!
Fritz Fehler:
- Keinen externen DNS Server eintragen. Das ist völliger Unsinn, denn die Fritte bekommt den DNS Server dynamisch über DHCP an ihrem LAN 1 Port übermittelt. Beim Anschluss an die FW ist das die FW selber die als DNS Proxy arbeitet. Belasse das auf dem LAN-1 Default
- Weise deshalb auch nie die Fritte als DNS Server zu sondern immer die FW da diese ja DNS Server im Pfad ist!
- Die Fritte darf niemals im Heimnetz die .178er IP Netzadresse verwenden wenn das gleiche Netz oben schon auf der Firewall verwendet wurde!!! Das wurde dir oben mehrfach gesagt und ist ein fundamentaler IP Designfehler.
Setze deinen eigenen Vorschlag um und nutze nur 10er IP Netze (oder 172er) auf der Firewall dann kann so ein Unsinn nicht mehr passieren!!
- 10 Tage Gültigkeit für die DHCP Leases ist zuviel und macht kein normaler Admin. Üblich sind 1 Tag bzw. ein Maximum von 3 Tagen sollte nie überschritten werden!
3 schlimme Kardinalsfehler die dir die ganzen Connectivity Probleme verursachen. Etwas mehr Sorgfalt und Überlegen beim Setup wäre angebracht! Meister Yoda würde mit den Augen rollen... 🙄
Du meinst bei den NAT Einstellungen
Nein, denn an den NAT Einstellungen muss man rein gar nix fummeln! Die Adressierung des physischen WAN Ports ist gemeint. (99er Netz) Eh warte, ich habe nie ab 1 vergeben, ja bis 254, aber nie ab 1.
So so... Deine Konfig ist da aber ganz anderer Meinung!! 🧐Ja ich hätte sie mal deaktivieren/löschen können...
Verwirrt hier alle Beteiligten nur wenn du solche Fehler immer mitpostest. Die 178 ist die Standard IP von der Fritte
Ist allen Admins hinreichend bekannt und deshalb darf dieses IP Netz niemals irgendwo in der Firewall Adressierung auftauchen! (10er, 172er Thema...)
Stimmt, das ist die Available Range, sorry. Allerdings ist deine dann konfigurierte Range auch wieder falsch konfiguriert. 
Dort sollte dann sowas stehen wie "192.168.100.11 - 192.168.100.250". Du hast den oberen Wert vergessen und damit greift dann die Range insgesamt nicht.
Dort sollte dann sowas stehen wie "192.168.100.11 - 192.168.100.250". Du hast den oberen Wert vergessen und damit greift dann die Range insgesamt nicht.
Trotzdem ist doch irgendwas falsch auf der Fritzbox...
Ja, das manuelle Setting des LAN-1 Koppelnetzes. Belasse das auf dem Default und lasse den DHCP Client am LAN-1 Port das für dich erledigen. Dann klappt das auch. Den hast du abgeschnitten
Wie peinlich... 🙈Habe aber noch ein DNS Problem, Adressen werden nicht aufgelöst
Was sagt ein nslookup vom Endgerät und auch vom Diagnostics Menü?wenn ich tracert starte
Hoffentlich dann auch mit einem -n um die DNS Auflösung anzuschalten?!dass es hier zwecks DNS noch über die FW laufen müsste?!
DNS hat mit den Routing Hops nichts zu tun, vergiss das.Aber vermutlich tut es das gar nicht, weil tracert nicht über port 53 geht?
Das hast du hoffentlich nicht Ernst gemeint und verstehen wir mal als einen Scherz!https://de.wikipedia.org/wiki/Traceroute
Lesen und verstehen...!
aber auch auf der FW Adresse funktioniert es nicht.
Du meinst damit das Diagnostics GUI richtig?Wenn dem so ist hast du ein grundsätzliches DNS Problem mit der Firewall!! Das musst du zuallererst fixen bevor du überhaupt weitermachst ansonsten hast du weiterhin DNS Probleme, egal wo.
Hier wird aber zwingend ein DNS verlangt, ich kann ihn nicht leer lassen:
Unüblich, denn wenn man es leer lässt vergibt die Fritte ihre eigene IP als DNS Server.Zitat:""Wenn sie einen anderen DNS Server in ihrem Heimnetz verwenden möchten" Normalerweise will man keinen anderen sondern üblicherweise die Fritte die ja in der Regel als (Cache) DNS Server arbeitet und so lässt man das Feld dann leer damit die Fritte sich selber angibt.
Wenn sie es dennoch zwingend fordert gibst du halt die LAN IP der Fritte an.
dass Clients aus den verschiedenen Netzen (aktuell die IP der alten Fritte) die FW als DNS-Resolver nutzen dürfen?
Guter Punkt! Das ist aber in der OPNsense schon im Default aktiv. eh ich dachte -d schaltet sie AUS
Richtig das ist der Schalter in der Linux Variante. Bei Winblows ist es der oben genannte, sorry.Kannst du mir sagen...
Wer ist damit gemeint? Kollege @em-pie?!Interface LAN gelöscht
Warum hast du denn stattdessen ein neues (wieder überflüssiges) "Config" dafür angelegt? Das ist doch ziemlich sinnbefreit wenn du so oder so über den Trunk und dessen Parent- sowie allen (Konfig) VLANs einen Konfig Zugriff auf die FW hast. Soweit hast du ja schon alles richtig gemacht mit LAG usw. Warum hast du nicht einfach das LAN belassen bis der Trunk bzw. LAG zum Switch rennt, dort den Konfig Zugriff getestet und dann erst das LAN Interface komplett gelöscht? Das wäre doch ein sinnvolles strategisches Vorgehen?! Wieviel zahllose Konfig Interfaces willst du denn noch einrichten?! Sinnfreie Aktion, aber egal....Fehler:
- Physischer WAN Port weiter mit einer überflüssigen RFC1918 IP versehen
- Hilfreich für alle um zielführend zu antworten zu können wäre zu wissen auf welchem physischen Parent Port die VLANs liegen. Gut, im Endausbau auf dem LAG aber dennoch hilft es dein Setup besser zu verstehen
- Das der LACP LAG nur einen einzigen Memberport hat ist natürlich technisch unsinnig aber vermutlich nur ein temporärer Fehler. Die grundlegende Logik eines LAGs besagt ja immer mehr als nur einen singulären Port zu haben. Ansonsten bräuchte man ja keinen LAG.
- Warum das "V_Config" VLAN auf igc2 gemappt ist statt auch auf den LAG verstehst wohl auch nur du selber?!
- Ein VLAN mit dem Tag 1 zu kreieren ist Unsinn und solltest du löschen. Da das VLAN 1 immer das Default VLAN auf allen Switches ist und damit auch das PVID VLAN (Untagged) macht es Sinn dieses VLAN bzw. IP Netz immer auf das native lagg0(LAGG1) Interface zu legen. Traffic von diesem Interface sendet die Firewall, wie oben schon mehrfach gesagt, immer UNtagged was dann am gegenüberliegenden Switch Trunk dann automatisch ins VLAN-1 geforwardet wird. Ein 1er VLAN muss und sollte man in der Regel deshalb nicht nochmals separat anlegen.
DHCP ist für alle Interfaces an
Hoffentlich NICHT für den WAN Port?! Next steps dann, wenn der Switch da ist oder kann ich noch was vorbereiten?
Nope, ist soweit erstmal alles korrekt. Bis auf die überflüssigen Konfig Interfaces und überflüssigen IPs die nicht genutzt werden (WAN).dass ich grundsätzlich die "Verschachtelung" verstehe
Wenn wir nur wüssten was du unter "Verschachtelung" verstehst? 🙄dass ich auf einen Blick anhand der IP erkenne wo ich bin oder direkt weiß wer mit wem.
Das ist sehr vernünftig und der richtige Weg. 👍 Sowas nennt der Admin einen IP Adress Plan. Ggf. machst du dir auch schon vorab mal Gedanken über ein Regelwerk was du zum Schluss wenn alles rennt umsetzen willst?!Hier noch eine Verständnisfrage:
Leider schwer zu beantworten da du keine Subnetzmaske mitgegeben hast die du planst in den Segmenten zu verwenden. So ist eine zielführende Antwort eher Raterei. Nur so viel: Wenn du von einer klassischen 24 Bit Adressierung ausgehst macht es aus Management Sicht Sinn bei VLANs die VLAN ID ins 3te Byte der Adresse zu "kodieren". Bei den nicht VLAN Interfaces ist das Geschmackssache was du verwendest.
Das .178.0er Netz der Fritte ist davon unberührt, weil die Fritte immer per Adress Translation (NAT) an ihrem WAN Port auf die FW geht und ihre lokalen LAN Netze somit "versteckt". (Siehe dazu auch NAT Grundlagen)
Der Modem Port, sprich PPPoE, ist aus dieser Adressierungs Thematik vollkommen rausgelöst. Logisch, denn der bekommt dynamisch vom Provider eine IP per PPPoE auf die du keinerlei Einfluss hast. Ausnahme ist die statische IP auf dem physischen WAN Port die natürlich aus den o.a. Gründen dann unsinnig ist. Es sei denn du willst unbedingt das Modem Management offen ins Internet exponieren?! (Siehe dazu hier und auch hier)
Die Adressierung gilt also lediglich nur für die lokalen Netzwerk Segmente.
Und ja, erst auf einem Endgerät auf einem Port, dann das Interface auf dem Port
Du sprichst in Rätseln. Diesen kryptischen Satz verstehst wohl nur du selber?! 🤔Ich mach es jetzt so:
👍dass ich dann Switch seitig 1 Untagges auf dem Trunk Port auch wirklich zuweise?
Das ist so oder so immer Default da das PVID VLAN auf allen Switchports immer 1 ist wenn man es nicht dediziert ändert.und 2XX für VLAN.
Ist nur blöd bei einer VLAN ID > 54 🤣damit ich auf das Modem UI komme
Ja, das ist auch richtig wie an den beiden Links oben ja beschrieben wurde. Damit exponiert man aber ungeschützt das Modem UI ins Internet. Ob das eine gute Idee ist musst du selber beurteilen...Ich meinte,dass ich erst die neue IP am Endgerät einstelle bevor ich die Interface IP ändere
Na ja, du sägst dir ja nicht den eigenen Ast ab auf dem du sitzt, das wäre nicht besonders intelligent. Folglich macht man IP Adress- und DHCP Änderungen für ein Interface immer von einem anderen IP Netz (Interface) aus, dann kann sowas auch niemals passieren.Genau deshalb solltest du auch das LAN Interface als "Notzugang" behalten über das du die gesamte Konfig Anpassung des Trunks und LAGs machst bis der fehlerfrei funktioniert. Dann brauchst du dieses Interface nicht mehr und löscht es vollständig indem du dich vorher auf einen anderen Ast setzt und über den VLAN Trunk auf die FW verbindest bevor du die Säge für den LAN Ast rausholst! Einfache Logik die ja oben schon mehrfach diskutiert wurde...
Du schreibst davon VLAN1 Tag auf das lagg0 zu legen
Es war auch nicht das Taggen gemeint sondern eben das NICHT taggen. Sproch also das du das VLAN 1 als PVID VLAN nutzt! Irgendwo muss ja auch der UNtagged Traffic hin. VLAN 1 also NICHT taggen sondern das immer als PVID VLAN für die ungetaggten Frames nutzen. Hat auch den Vorteil das bei Switches das Management Interfave immer untagged im VLAN 1 als Default liegt. So behältst du immer Zugriff auf die Infrastruktur. Gilt auch für die Firewall von dessen Parent Interface der Traffic immer untagged kommt. Weisst wie ich meine?!Ansonsten nochmal die VLAN Schnellschulung lesen und verstehen.
Das ist ja grausam wie die einen auf die Cloud Lösungen zwingen wollen
Klar, alle wollen an deine persönlichen Daten. Die sind bekanntlich 1000mal mehr wert als der Switch selber. Ist aber eine bekannte Binsenweisheit und jeder verantwortungsvolle Admin deaktiviert die Cloud Funktion als Erstes.Was zum Teufel sind die LAG Ports da unten?!
Der Switch supportet maximal 8 LACP LAGs im System. Das ist bei Billigheimern ein üblicher Wert. Diese werden per Default schon im System fest eingerichtet. Welche Memberports des Switches du den LAGs zuordnest ist dann deine Wahl. Normales verhalten also.und auch 1 als Trunk...
Wie oben schon mehrfach gesagt wurde ist das VLAN 1 immer das Default PVID VLAN auf allen Ports!!! Dazu gehören auch Uplinks und natürlich auch LAGs! Besagt das alles was UNtagged an diesem Port ankommt ins VLAN 1 geforwardet wird. Einfache Logik! Oder muss ich jetzt etwa die LAG Ports konfigurieren statt der normalen ports?!
LAGs sind immer eine Funktion beider Seiten! Bitte lies dir dringend nochmal das LAG Tutorial hier durch was alle Details haarklein und einfach zu verstehen beschreibt!Link Aggregation (LAG) im Netzwerk
Nur So viel:
Wenn du auf der Firewall 2 Ports zu einem LAG zusammengefasst hast musst du das logischerweise auch auf der Switchseite machen. Dazu wählst du einen der vordefinierten LAGs z.B. "LAG1" und weisst dem in deinem Setup die beiden Memberports auf dem Switch zu die diesen LAG bilden und klickst auf Tagged. Fertisch...
Dann kannst du die beiden LAG Ports von der Firewall mit denen des Switches verbinden und fertig ist der LAG(CK).
Das ist doch grausaum schlecht gemacht....
DU selber hast dich doch für den Hersteller entschlossen, oder? Aber mal im Ernst: So ein Hexenwerk ist das doch nun auch wieder nicht.
Meister Yoda sagt: Du musst hier immer eine manchmal etwas verwirrende Nomenklatur bei den Herstellern beachten. Cisco hat den Begriff "Trunk" für einen tagged Uplink geprägt aber sehr viele Hersteller, besonders die im Low Budget Bereich, bezeichnen einen LAG, also eine Link Aggregation mehrerer Ports, als "Trunk". (Cisco nennt das Etherchannel) Auf dem Zyxel ist also (vermutlich) mit "Trunk" die Link Aggregation LAG gemeint...
Nicht das du da durcheinander kommst.
So sollte es ein, richtig?
Jepp, das sieht gut aus! 👍Workaround, mit dem ich Dummy Devices bauen kann um darauf nicht benutze Interfaces zu parken?
Meinst du Switch oder Firewall? 🤔In der Regel nicht. Auf der FW nimmst du unbenutzte Interfaces einbfach aus dem Assignement raus und auf dem Switch setzt du sie in den Shutdown Mode, schaltest sie also ab. Oder was meinst du??
Wenn du ein Interface der FW killst dann ist logischerweise auch das Regelwerk dazu weg. Würde ja sonst auch keinen Sinn machen. Das ist bei allen so.
Wo kommt das PVID VLAN her, wie ist das für mich greifbar?
Bitte lesen: Warum gibt es PVID bei VLANs? !!!Du musst einem Switch doch immer statisch in der Konfig sagen wo er mit UNgetaggtem Traffic an dem Port hinsoll! Der o.a. Thread sollte das klären und greifbar machen.
Es läuft unsichtbar im Hintergrund für Untagged Frames mit und die gehen direkt auf das physische Interface eines VLANs?
Nein, so ist es natürlich nicht sondern viel einfacher.Du musst dem Switch ja sagen was er mit ungetaggtem Traffic machen muss der keinen VLAN Information mitliefert. Das muss Port bezogen auf jedem einzelnen Port gemacht werden! Wobei LAG Ports immer als virtuell ein Port gesehen werden. Deshalb tauchen die bei dir unter den Ports z.B. als "LAG1" Port auf.
Du kannst (und musst) an jedem dieser Ports also einzeln Port für Port sagen in welches deiner VLANs an diesem Port ankommender UNtagged Traffic gesendet werden soll.
Das ist für alle Endgeräte wie PCs, Drucker IoT usw. essentiell wichtig, denn man will die ja nicht alle in einem großen Netz haben sondern logischerweise segmentieren wenn man mit VLANs arbeitet.
Nochmal:
Das PVID VLAN oder auch Native VLAN Setting bestimmt für jeden einzelnen Port in welches VLAN er UNgetaggten Traffic, also Traffic OHNE jegliche VLAN Information forwardet.
So einfach und banal ist das...
Alter Schwede...das ist aber VLAN, 1te Klasse Grundschule und solltest du nach der Lektüre der hiesigen VLAN Tutorials und Threads doch langsam mal auf die Kette bekommen haben!
Dann kommen mit VLAN 1 ungetaggte Pakete auf dem physischen Device an
Wenn du von der Firewall redest dann ja. Aber auch nur dann, wenn am dazugehörigen Switchport das PVID VLAN auf 1 steht.Hast du z.B. die PVID ID an dem Port auf 10 stehen geht der ungetaggte Traffic vom "physischen Device" logischerweise ins VLAN 10 (siehe oben). Ein Switch hat kein "physisches Device" in dem Sinne.
Gemäß deines Beispiels oben dann ganz einfach:
- FW physisches (Parent) Interface = UNtagged = 10.1.1.1 = geht am Switch ins VLAN 1 wenn die Port PVID auf 1 steht
- VLAN 10 auf o.a. Parent = Tagged = 10.1.10.1 = Switch liest den mitgesendeten Tag und forwardet in VLAN 10
- VLAN 20 auf o.a. Parent = Tagged = 10.1.20.1 = Switch liest den mitgesendeten Tag und forwardet in VLAN 20
- Der dazugehörige Switchport (oder LAG Port) steht also auf
- PVID 1
- VLAN 10, tagged
- VLAN 20, tagged
(Hier siehst du das mal an einem Server statt Firewall wie das aussieht)
ich will es aus den Assignments rausnehmen ohne es zu löschen.
Das geht so nicht. Sowas wie Dummies gibt es da nicht. Wozu soll das auch gut sein wenn man seine physische Interface Belegung fest bestimmt hat und noch 1 oder 2 ungenutzte Interfaces zum Spielen hat.Sorry für meine "eigene Sprache" hier, ich bin nicht vom Fach
Kein Problem dafür versuchen wir das für dich hier ja zielführend zu klären. 😊Also, ich lösche VLAN1 einfach raus und alles sollte weiterhin funktionieren
VLAN 1 kann man als VLAN nicht zentral löschen weil es das Default VLAN ist.Du hast dich aber vermutlich nur gedrückt aus falsch und meinst das Tagging für das VLAN 1 an dem Port, richtig?!
Da lautet die Antwort JA. Kein VLAN 1 taggen und das Tagging entfernen. Macht auch keinen Sinn wenn am gleichen Port auch noch das PVID VLAN auf 1 steht. Das würde so oder so großes Chaos geben wenn man das gleiche Netz 2mal tagged und untagged gleichzeitig anliefert.
Gibts noch ne andere Idee dazu, wie ich alles was mit einem Interface zusammenhängt irgendwie parken kann,
So mit Dummie frickeln geht das nicht. Du kannst dann nur ein Setup Backup machen und das wieder einspielen wenn du was rückgängig machen willst.So dann taggen?
Das sieht gut aus! 👍mit dem Switch im LAG Modus...so taggen wie oben
Jepp genau richtig!Erst dem LAG Port (z.B. "LAG1") die beiden (unkonfigurierten!) Memberports zuweisen und dann das o.a. Tagging NUR auf dem LAG Port machen wie es oben zu sehen ist!
Denk dran: Der Switch "sieht" den LAG Port nur als einen einzelnen Port und repliziert die Konfig dann automatisch auf seine Memberports!
ich muss das Interface löschen oder nicht?!
Richtig!Du musst nicht nur das VLAN 1 Interface löschen sondern zusätzlich auch noch global das VLAN 1 selber! Beides muss weg.
Hier definiere ich das LAG und die Member:
Jepp, hast du richtig gemacht! Mode LACP und den Port 1 und 2 als Memberports zugewiesen. Alles richtig!Hier sieht man ihn dann, wenn ein Kabel eingesteckt ist
Auch korrekt!Hier werden die VLANs erstellt:
Ebenso korrekt!Ich habe hier die PVID 20 für Port 8 vergeben
Ist richtig. Port 8 ist dann ein Endgeräte Port im VLAN 20und Port 1 ans TRUNK gekennzeichnet.
Das ist falsch!!Dir wurde oben mehrfach gesagt das der Switch einen LAG1 als ein einzelnes Interface sieht! Du darfst also nach Anlegen des LAGs niemals mehr die Memberports einzeln anfassen. Dann kommt es zu einer Miskonfiguration der einzelnen LAG Memberports und damit zum Scheitern des LAGs! 😡 Port 1 und 2 sind Memberports deines LAGs mit dem Interface "LAG1"!
Also: Nach der LAG Konfiguration alle Konfig Settings immer nur auf dem LAG Interface ausführen und NICHT mehr auf den einzelnen Memberports!!
Konfigs auf dem LAG Interface sorgen dafür das diese dann immer sicher synchron auf beide Memberports übertragen werden ohne das die Gefahr eines Mismatches passiert wie du ihn oben durch deine Einzelkonfig provoziert hast. Kein Wunder also das "Chaos" passiert wenn man das missachtet.
Schlimm genug das die Zyxel Gurke solche Kommandos auf den Memberports überhaupt ausführt...
Damit sollte nun hoffentlich nach dieser 2ten Erklärung alle Fragen was es mit den LAG1-8 Ports auf sich hat geklärt sein?! 🤔
Ich dacht wenn der Port #8 ein Tag 20 und PVID 20 hat
Das ist mit Verlaub doch Blödsinn!! Denk mal selber nach... Du kannst doch niemals an einem gleichen physischen Port Frames aus dem gleichen Netzwerk Segment zugleich tagged und auch untagged konfigurieren. Kein normaler Switch würde so eine Unsinns Konfig zulassen. Was sollte die auch für einen tieferen Sinn haben den gleichen Traffic doppelt zu senden?! Endgeräte verstehen bekanntlich keinen getaggten Traffic.Auch das wurde dir oben schon mehrfach gesagt. 🙄
- PVID X = UNgetaggter Endgeräte Port im VLAN X = kein Tagging mit gleicher ID erlaubt!
- Tagged X = getaggter Port = X darf niemals gleich dem PVID Setting am Port sein!
Kann forbidden den PVID blockieren und da geht gar kein Traffic über den Port?
Ja, kann es aber das zu verwenden ist unsinnig und muss man nur in Ausnahmefällen. Wen n du hier kein VLAN X Tagging haben willst, dann konfigurierst du es dort schlicht und einfach nicht. Es trotzdem zu senden dann aber mit der Forbidden Funktion zu blocken macht ja wenig Sinn.Du meinst also dass ich einfach statt Port 1 und 2 nur noch LAG1 einstelle, ja?
Ja, das ist doch der tiefere Sinn dieser LAG Konfig Logik- Im LAG Setup die beiden nackten Memberports hinzufügen
- NUR noch mit dem virtuellen LAG Interface in der Konfig arbeiten! Die Memberinterfaces sind Tabu!!
Statt alle Interfaces einzeln konfigurierst du einfach nur das LAG Gruppeninterface der diese Konfigs dann automatisch auf die Memberports anwendet. Ist doch gang easy...
dass ab dem Zeitpunkt zu dem man ein LAG aktiv hat ALLE ports nur noch über die LAG Ports eingestellt werden
Richtig verstanden! 👍und die klassischen Ports 1-8 komplett deaktiviert sind.
Das ist dein katastophaler Denkfehler!! 1-8 ist kein Switchport!! Damit sind, wie oben bereits mehrfach gesagt, die "Gruppen" gemeint die dann wiederum die der Gruppe zugewiesenen Switchports (Memberinterfaces) enthalten. Dein Switch supportet max. 8 LAG Gruppen.Bei dir also das Gruppeninterface LAG1 zur LAG Gruppe 1 was dann wiederum die Member Interfaces Switchport 1 und 2 enthällt.
Die LAG Gruppe 2 (LAG2) kann dann z.B. die Switchports 10 und 11 enhalten und wird über das LAG2 Interface angesprochen. Einfache Logik!!
das macht vermutlich wieder keinen Sinn was ich hier geschrieben habe
Richtig!Wenn du nun endlich die o.a. Logik erkannt hast wirst du auch selber erkennen das das sinnfrei ist. Gruppennummern sind eben keine Ports.
andere Hersteller schaffen das ja auch...
Ja, da hast du Recht. Das Feature was das intelligent umsetzt und viele andere Hersteller supporten nennt sich Auto PVID.Du hast dich aber ja ganz bewusst und willentlich für deinen Hersteller entschieden der das nicht supportet! (Datenblatt) Also heul nicht rum, sei ein Admin und beachte das!
Ich mach es dann so: Ports 1-8 + LAG2-LAG8 deaktiviert.
Neiiiin! Switchports 1 + 2 sind Tabu, die gehören zu deiner LAG1 Gruppe!! 😡Port LAG2-8
...gibt es gar nicht und ist Schwachsinn. Den Unterschied LAG Gruppen und Switchports hast du ja nun hoffentlich verstanden?!Witzig ist ja, dass es trotzdem in der Config läuft
Zeigt wie mehr oder minder idiotensicher (sorry) VLAN Konfigs sind. 🤣Und es ist defitniv ein Firmware Bug wenn die LAG2-8 nicht definiert sind
Was soll denn "LAG2-8" genau sein. Die Bezeichnung ist doch völliger Unsinn! Wenn, dann gibt es nur einen LAG2 der sich auf die 2te LAG Gruppe bezieht. Der ordnet man dann wieder Memberports zu. Eine "8" in dem Namen ist da doch völliger Unsinn oder was willst du damit ausdrücken?Wie man unschwer an deinem eigenen Screenshot sieht ist die LAG2 Gruppe bzw. deren dazu korrespondierendes, gleichnamiges Interface sehr wohl definiert!!
Unverständlich wo du hier einen "Bug" siehst?! 🤔
also dass du einfach die Member in der normalen Liste trotzdem konfigurierst und die Gruppe ignorierst
Kann z.B. auf dem allereinfachstem Modell, einem 1200er, definitiv nicht passieren. Ich stell jetzt erst mal noch die Tags ein und teste dann gründlich.
Guter Punkt... Wir sind gespannt wie das VLAN Drama hier weitergeht. Die Gruppen LAG2 BIS 8 sind deaktiviert und trotzdem erscheinen sie in der Liste der zu konfigurierenden Ports, das ist einfach nur verwirrend.
Na ja, verwirrend ist das nicht. Du hast bei diesen LAGs sicher keine Memberports zugewiesen, oder? Ein LAG ohne Memberports ist dann natürlich kein funktionsfähiger LAG und folglich ist das Interface automatisch "disabled" was dann nicht nur logisch sondern auch folgerichtig ist. Erst wenn du Memberports zuweist entsteht ja überhaupt erst ein LAG und dann wechselt auch der Status automatisch auf "enabled". Ist eigentlich nachvollziehbar.Ein unbenutzer Switchport wird im Status "down" ja auch angezeigt in der Übersicht was für dich anscheinend dann nicht verwirrend ist. Du misst hier ein bisschen mit zweierlei Maß?!
was kann ich alternativ tun um auf das Modem zu kommen?
Den zweiten OOB Port des Modems nutzen! Das ist zu mindestens sicherer. Wenn du es dennoch inbound im Zugriff haben willst oder musst guckst du hier:
Modem Management Firewall 1
Modem Management Firewall 2
Solche Fauxpas' passieren auch dem besten Admin im Eifer des Gefechtes. Devise ist immer ruhig bleiben und strategisch vorgehen beim Troubleshooting. 😉
Das macht gar nichts und ist auch nicht schlimm. Der LAG funktioniert trotzdem. Ist ja auch der Sinn der Sache, denn der LAG bringt eben von Haus aus diese Redundanz Funktion gleich mit. Es ist also nicht nur die doppelte Bandbreite sondern auch die Redundanz.
Gute Switches melden im Log dann immer ein "Degraded" beim LAG Status so das man weiss das man da mal nachsehen sollte weil meistens ein Memberlink dann ausgefallen ist.
Works as designed..
Oder war die Frage jetzt anders gemeint?! 🤔
Was ist denn das Sicherheitsrisiko, wenn ich nur ein Kabel nutze?
Du meinst an einem LAG wenn du z.B. ein Kabel ziehst oder temporär nicht nutzt??Das macht gar nichts und ist auch nicht schlimm. Der LAG funktioniert trotzdem. Ist ja auch der Sinn der Sache, denn der LAG bringt eben von Haus aus diese Redundanz Funktion gleich mit. Es ist also nicht nur die doppelte Bandbreite sondern auch die Redundanz.
Gute Switches melden im Log dann immer ein "Degraded" beim LAG Status so das man weiss das man da mal nachsehen sollte weil meistens ein Memberlink dann ausgefallen ist.
Works as designed..
Oder war die Frage jetzt anders gemeint?! 🤔
aber von IPv6 noch weniger
Das muss ja nicht so bleiben und da hilft etwas kostenlose Literatur!https://danrl.com/ipv6/
dafür ist die ganze DNS Infrastruktur nicht definiert bei mir?!
Das ist egal weil im Default v6 so oder so lokal erstmal nicht aktiv ist sofern du es nicht explizit einrichtest. Ob am WAN Port Dual Stack aktiv ist spielt keine Rolle.Wenn du einen Dual Stack Anschluss hast macht es natürlich Sinn auch IPv6 zu aktivieren. Wie das geht auf der OPNsense kannst du z.B. hier sehen:
IPv6 auf der OPNsense
Auch lesenswert zu der Thematik:
PFsense IPv6 - Was mache ich falsch ?
Dual Stack Setup u. Ping Check
Du solltest dann hier auch fairerweise auf deine zahllosen Folgethreads verweisen damit wir uns alle hier nicht im Kreise drehen! 
OPNsense DNS "halb tot" - Keine Auflösung nach längerer Zeit
O2 VoIP mit Fritzbox als Client hinter OPNsense
OPNsense DNS "halb tot" - Keine Auflösung nach längerer Zeit
O2 VoIP mit Fritzbox als Client hinter OPNsense
und hänge den zweiten Port vom Modem an mein LAN Interface 10.10.10.1
WIE greifst du denn mit dem Client auf diese Modem IP zu bzw. WO befindet sich der Client??Mit einem Management Client der per Layer 2 auch ans LAN Interface angeschlossen ist, sprich also dann im gleichen IP Netz liegt wie das Modem selber?
Sollte der Management Client in einem anderen IP Netz liegen ist der Zugriff aufs Modem natürlich nicht möglich, weil dem Modem ein Default Gateway für die Rückroute fehlt! (Siehe Routing Grundlagen)
Der Management Client muss also L2technisch zwingend immer im gleichen IP Netz liegen sonst scheitert der Zugang.
Ob es generell sicherheitstechnisch sinnvoll ist ein am Internet offen exponiertes Modem direkt in einem lokalen LAN erreichbar zu machen musst du selber entscheiden. Verantwortungsvolle Admins machen sowas nicht.
Und dann mit Gateway und Route die Verbindung schaffen?
Route? Wieso Route? Default Gateway im Modem reicht doch sofern das an seinem Managementzugang supportet ist!Das Management UI hat ja keine Verbindung zum Internet
Das weisst du sicher?? 🤔Was wäre denn eine sinnvolle Lösung des Problems?
Den Zugang über das WAN Interface realisieren! Da ist zu mindestens die Firewall mit Regelwerk und NAT dazwischen. Das WAN Port NAT löst dir dann auch gleichzeitig das o.a. Gateway/Routing Problem. Modem Mgmt.Zugang 1
Modem Mgmt.Zugang 2
Sind wir mal ehrlich, wie oft brauch ich das?
Einsicht ist der erste Weg.... es soll performance/kontrolltechnisch von Vorteil sein, wenn die FW das VLAN 7 steuert anstatt des Modems
Nein!Wer hat dir diesen Unsinn erzählt?! Das erfordert a.) eine deutlich aufwändigere Konfig auf der Firewall selber mit einem überflüssigen Tagging Subinterface und b.) ist es mehr Overhead und Ballast für die Firewall.
Völlig unsinnig also das über die Firewall zu machen wenn es das Modem nebenbei erledigt. Das sagt einem aber auch schon der gesunde IT Verstand.
Für dein Vigor also:
Damit entfällt das dann überflüssige VLAN Tagging Subinterface und der gante Overhead in der Firewall WAN Port Konfig.
Aber was mach ich denn jetzt noch falsch, wenn das 100er Netz nicht ins 10er Netz gucken kann bzw auf deren Clients.
Auf einer Firewall spricht das immer klar für ein falsches Regelwerk! Oder ggf. falsche oder fehlende Gateway IP Adressen an den Endgeräten die ein Routing verhindern.Eins oder beides wird es wohl sein?? 🤔
Gateway am Modem ist ein guter Punkt, das prüfe ich gleich.
Sollte aber in dem Fall obsolet sein wenn der Port an dem das Modem hängt der FW WAN Port ist. Dort sollte per Default NAT (IP Address Translation) aktiv sein sofern du es nicht verfrickelt und/oder deaktiviert hast?!Dann werden so oder so ALLE internen Absender IPs auf die 10er IP translated und das Modem "denkt" so das sie alle aus dem lokalen Netz kommen. Ein Gateway auf dem Modem wäre dann eh obsolet.
Einfach mal den Interface Packet Capture auf dem WAN Port laufen lassen und auf die Ziel IP des Modems filtern. Dann solltest du dort TCP 80 oder 443 Frames vom Management Client sehen.
Wenn nicht hast du ein Problem im Regelwerk irgendwo.
Hier ein Beispiel von einem Browser Client im lokalen LAN 192.168.1.0 /24 der auf ein Modem (10.11.1.254) am WAN Port per HTTP GUI zugreift.
Wie man am o.a. Capture sieht greift hier das NAT am WAN Port der Firewall so das die ausgehende Absender IP erwartungsgemäß die WAN IP ist und nicht die 192.168er Client IP. Ein Gateway am Modem ist damit obsolet!
Works as designed!
Da sehe ich die hier:
Jepp, da pingt (ICMP Echo-Anforderung) die 10.10.11.1 (vermutlich WAN Interface) die 10.10.11.2 (vermutlich Modem) was auch prompt antwortet (ICMP Echo-Antwort) also fehlerfrei klappt wie man unschwer sieht!Works as designed!
Kann, muss aber nicht. Das du am WAN ggf. fälschlicherweise taggst kann man ja ausschliessen, denn sonst würde auch der Ping scheitern der ja nachweislich funktioniert.
Wenn lediglich nur TCP 80 und 443 geblockt werden spricht das eher für einen Fehler im Regelwerk.
Alternativ kannst du ja mal auf dem Client ein PuTTY starten und versuchen eine Telnet (TCP 23) oder SSH (TCP 22) Session auf das Modem zu öffnen.
Auch wenn das Modem diese Zugänge nicht supportet solltest du zumindestens ausgehende TCP Pakete mit diesen Ports mit der Modemziel IP sehen. Ggf. antwortet das Modem auch mit einem ICMP Zielport nicht erreichbar. Das wäre dann auch ein Indiz das 80 und ggf. 443 irgendwo blockiert sind. Wo auch immer?!
Mit einem Default Setup klappt es ja fehlerlos wie man oben am Wireshark Trace sehen kann.
Wenn lediglich nur TCP 80 und 443 geblockt werden spricht das eher für einen Fehler im Regelwerk.
Alternativ kannst du ja mal auf dem Client ein PuTTY starten und versuchen eine Telnet (TCP 23) oder SSH (TCP 22) Session auf das Modem zu öffnen.
Auch wenn das Modem diese Zugänge nicht supportet solltest du zumindestens ausgehende TCP Pakete mit diesen Ports mit der Modemziel IP sehen. Ggf. antwortet das Modem auch mit einem ICMP Zielport nicht erreichbar. Das wäre dann auch ein Indiz das 80 und ggf. 443 irgendwo blockiert sind. Wo auch immer?!
Mit einem Default Setup klappt es ja fehlerlos wie man oben am Wireshark Trace sehen kann.
Kann ich testweise den LAN Port ins gleiche Subnet verfrachten wie WAN Port
Nein!Das klappt nur mit reinen Ethernet Interfaces. Dazu erzeugt man eine Bridge, wählt die Memberports der Bridge aus und mappt die Interface IP auf das Bridge Interface! Es darf kein Bridge Member Interface mit einer IP versehen sein!! Logisch, denn Bridging ist immer Layer 2 only, also Forwarding rein auf Basis der Hardware Mac Adressen.
Allein diese Tatsache würde eine Bridge Kopplung von LAN und WAN Port völlig absurd machen weil die zwingend routingtechnisch getrennt sein müssen.
Wie gesagt: Kannst du abgesehen davon das es eh sinnfrei ist, auf einer routenden Firewall gleich vergessen, weil das PPPoE Interface nicht auf einem Bridge Parent Interface funktioniert!! Fliegt dir also gleich um die Ohren solche üble Frickelei!
Wozu sollte das auch gut sein??
Sniffern kannst du über die Interface Capture Funktion und mit einem Mirror Port am Switch. (Siehe dein VoIP Thread!)