DHCP Fritzbox zu Cisco und Einbindung von Unifi Geräten

Mitglied: DrPfiend

DrPfiend (Level 1) - Jetzt verbinden

14.12.2020, aktualisiert 20:47 Uhr, 1151 Aufrufe, 39 Kommentare

Hallo!
Ich bin gerade dabei mein Heimnetzwerk aufzubauen und habe eine Menge Gerätschaften miteinander zu verknüpfen. Bisher lief alles über die FB und einen L2 Switch mit AVM Repeatern.

Stand jetzt:

FB7490
Cisco SG350-28P
Unify USG
4 Unifi nanoHD

Ich habe nach der Anleitung 5 Vlans aufgesetzt und dem Router eine feste IP in jedem VLAN gegeben.
Dann habe ich die AP´s, den USG und einen VM Proxmox Server via tagged Trunk angebunden und meine kabelgebundenen Heimgeräte in die entsprechenden VLANs gesteckt. Leider habe ich keine so schöne Übersicht der Vererbungen in meinem GUI :-( face-sad

admin: PV, S7-300, Wallbox
home Server, PC´s, Mediaplayer
iot noch leer
gast noch leer

ich möchte jetzt das Routing durch den Cisco durchführen lassen. Mein erster Versuch ging schief, indem ich dhcp bei der FB deaktiviert habe und am Router aktiviert. Danach ging gar nichts mehr... Ich benötige hier eine kleine Anleitung step by step. DHCP durch das USG bringt mir glaube ich keine Vorteile.

Wie richte ich diese VLAN´s (home, iot und gast sollen ins WLAN) dann in den Unifi AP´s über den Cloudkey ein ? Der soll später als VM auf dem Proxmox server laufen.

Das USG hat ja ein eigenes VLAN, kommt dort auch die FB mit rein? Derzeit ist das USG noch nicht zwischen FB und Router. Wenn das klappt würde ich gerne die FB zum Modem und DECT basis degradieren.

Besten Dank für eure Hilfe
1 - Klicke auf das Bild, um es zu vergrößern2 - Klicke auf das Bild, um es zu vergrößern3 - Klicke auf das Bild, um es zu vergrößern
39 Antworten
Mitglied: Pjordorf
14.12.2020 um 21:09 Uhr
Hallo,

Zitat von @DrPfiend:
Wenn das klappt würde ich gerne die FB zum Modem und DECT basis degradieren.
Wenn du deine FB noch als nur MODEM Konfigurieren kannst, und wenn deine Fritte nur noch als MODEM agiert, wird dein DECT alles können - nur du kannst nicht mehr Telefonieren oder angerufen werden.

Gruß,
Peter
Bitte warten ..
Mitglied: DrPfiend
14.12.2020 um 21:25 Uhr
Hallo Peter,
danke für diesen wichtigen Hinweis, dann werde ich noch eine zusätzliche DECT Basisstation ordern, die Fritz.Fon´s sollen ja kompatibel sein.
VG
Alexander
Bitte warten ..
Mitglied: aqui
15.12.2020, aktualisiert um 09:05 Uhr
und dem Router eine feste IP in jedem VLAN gegeben.
Wie ist das zu verstehen ?? Mit "Router" meinst du ja ganz sicher NICHT die FritzBox, oder ? Die kann das technisch gar nicht.
Dein VLAN Design und Konfig des SG350 sollte so aussehen:
https://www.administrator.de/forum/verständnissproblem-routing-sg30 ...

Ist dem so ??
Wenn nicht baue das Design genau so um wie im Thread beschrieben. Dort findest du auch eine Step by Step Anleitung.
Sinnvoll ist in der Tat die FritzBox als reines NUR Modem zu betreiben aber sehr wahrscheinlich wird sie das nicht supporten und du musst sie und die Firewall mit einer Router Kaskade mit doppeltem NAT und Firewalling betreiben. Technisch nicht die beste Lösung aber machbar.
Alle Details dazu findest du hier:
https://administrator.de/tutorial/ipsec-vpn-mobile-benutzer-pfsense-opns ...

Reine NUR xDSL Hybrid NUR Modems sind z.B. Draytek Vigor 165 oder Zyxel VMG3006 oder du beschaffst dir über eBay eine preiswerte FritzBox 7412:
https://www.spiegel.de/netzwelt/gadgets/fritzbox-7412-als-dsl-modem-dect ...
https://www.heise.de/select/ct/2020/2/1578238295698254
Bitte warten ..
Mitglied: DrPfiend
15.12.2020 um 11:17 Uhr
Ich bin nach deiner Anleitung vorgegangen. Meine Einstellungen entsprechen laut Bildern auch den Vorgaben.
Derzeit ist es so, dass sich die Geräte nur finden, wenn ich alle nicht-Trunks Ports im Default VLAN als Accepted festlege. Ich mache das immer über den Wizard.
Trunk-Ports auswählen, in meinem Fall die AP´s, der USG und der VM-Server (6 Ports),
dann das entsprechende VLAN, dort die Trunkports als untagged markiere, die nicht zur Verfügung stehen sollen und dann die Ports als accepted dem VLAN zuordne. Einige Geräte fanden sich so allerdings nicht im Netzwerk, (Bspw. Handy über nicht zugeordnetes WLAN auf Home-VLAN) sondern erst als ich alle Ports auch im Default VLAN eingebunden habe.

Der Router (Cisco) hat jetzt eine IP, vergeben von der Fritzbox in einem Gateway welches ich gar nicht brauche. Wie bekomme ich die IP des Routers im neuen Default LAN raus, brauch ich die überhaupt? Welche IP bekommt die Fritzbox fest oder eine vom Router? Ich habe auch noch nichts gefunden, wo ich den IP-Bereich der einzelen VLANS einstellen kann.

Bzgl. Unifi, habe ich es so verstanden, dass ich die Netzwerke im CloudKey einrichten muss und dann die SSID´s dem entsprechenden Netzwerk zuordne. Die Berechtigungen habe ich ja bereits über den Router geregelt bspw. VLAN 40(iot) nur untagged Zugriff auf den Trunkport USG (WAN)?
Draytek 166 ist geordert, hatte gehofft mit der Fritzbox ist das einfacher...
Bitte warten ..
Mitglied: aqui
15.12.2020, aktualisiert um 12:17 Uhr
Der Router (Cisco) hat jetzt eine IP, vergeben von der Fritzbox in einem Gateway welches ich gar nicht brauche.
Unverständlich ??
Du hast doch gar keinen Cisco Router laut deiner Beschreibung ?? Wo kommt der denn jetzt her ??
Gehe doch erstmal ganz strategisch vor.
Bevor wir ins Eingemachte gehen solltest du erstmal wasserdicht dein Design klären
Wenn man dich richtig versteht willst du ja zentral über den Layer 3 Switch routen wie es HIER beschrieben ist, oder ??

Oder willst du den Switch NICHT im Layer 3 (Routing) Modus betreiben sondern rein im Layer 2 und über die USG zentral routen ??
Wenn das der Fall ist dann gilt dieses_Tutorial hier.
Das sind 2 völlig verschiedene Routing Konzepte und daraus folgende Konfigs die du zwingend ZUERST klären solltest
hatte gehofft mit der Fritzbox ist das einfacher...
Das ist es auch wenn du die FritzBox in einer simplen Router Kaskade mit der USG betreibst !
Dieses Design (VLAN Routing auf der USG) sähe dann so aus:

usg1 - Klicke auf das Bild, um es zu vergrößern

Solltest du doch die VLANs über den Switch routen wollen (Switch im L3 Mode "IP Routing") dann sähe das Design so aus:

usg2 - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: DrPfiend
15.12.2020, aktualisiert um 12:22 Uhr
Ok, dann habe ich hier wohl ein grundlegendes Verständnisproblem.
Ich bin davon ausgegangen, dass der Cisco im L2 Modus ein smart Switch und im L3 einen Router darstellt. Letzteres ist die Wunschkonfiguration. Dazu habe ich o.g. Einstellungen anhand deines HowTo´s bereits erstellt.

Der Cisco "Switch" hat als Standardgateway jetzt die Fritzbox und von ihr auch eine IP bekommen. ich möchte aber die Fritzbox (oder bald das Vigor als reines Modem, vor dem USG (das nicht routen soll) betreiben und die IP-Vergabe durch den Cisco machen lassen. Im Cloudkey auf einer VM des Servers möchte ich die Statistikanzeige nutzen, die mir bei Unifi sehr gefällt.

Den USG bekomme ich auch nicht richtig angeschlossen, zumindest kann ich nicht auf Ihn zugreifen, wenn via WAN an Fritzbox und LAN an einen tagged trunkport des Cisco verbunden.

Das 2. Design ist so korrekt! Der Cisco ist sicher das potentere Gerät und daher für die ganze Geschichte besser geeignet.
Bitte warten ..
Mitglied: aqui
15.12.2020, aktualisiert um 12:29 Uhr
Ich bin davon ausgegangen, dass der Cisco im L2 Modus ein smart Switch und im L3 einen Router darstellt.
Das ist auch genau richtig so ! Hast du vollkommen richtig verstanden.
Der Cisco "Switch" hat als Standardgateway jetzt die Fritzbox und von ihr auch eine IP bekommen.
Das ist per se auch richtig aber dennoch ist es immer sinnvoll und auch Standard festen Routern immer eine statische IP zu vergeben. Sollten sich dynamische IPs einmal ändern zeigt deine VLAN Route auf der FritzBox ins Nirwana und nix geht mehr. Dynamische IPs sind deshalb immer ein NoGo auf Routern.
Besser also dem Koppelport eine statische IP zu setzen die AUßERHALB des FritzBox DHCP Bereichs liegt also z.B.: 192.168.178.254
Deine statische VLAN Route auf der FritzBox sollte dann immer auf diese IP zeigen.
zumindest kann ich nicht auf Ihn zugreifen, wenn via WAN an Fritzbox und LAN an einen tagged trunkport des Cisco verbunden.
Via WAN kannst du auch vermutlich nicht zugreifen, denn dort ist die NAT Firewall aktiv.
Über das LAN sollte es aber immer klappen.

Wie du zugreifst ist aber eine generell eine Frage des grundsätzlichen Designs: VLAN Routing auf Switch oder VLAN Routing auf USG !!!
Wenn du dich jetzt fest fürs VLAN Routing auf dem Switch entschieden hast dann wird die USG am LAN Port NICHT Tagged über einen Trunk angeschlossen sondern über einen stinknormalen UNtagged Accessport. Logisch, denn das VLAN Routing macht ja dann der Switch und die USG manged rein nur noch abgehenden Traffic ins Internet. Siehe Design 2 oben !!
Über das LAN VLAN kannst du dann problemlos von allen Switchports auf die USG zugreifen !
Bitte warten ..
Mitglied: DrPfiend
15.12.2020, aktualisiert um 14:45 Uhr
Gut ich komme mit deiner Erklärung mit, allerdings musste ich jetzt den Switch resetten, ich habe es nicht geschafft den Trunkport (an dem jetzt die Fritzbox dran hängt und zwischen den dann dass USG soll) zu entfernen.
Ich habe jetzt dem Cisco Switch eine statische IP vergeben und kann auch auf diesen zugreifen. ich habe die IP sowohl für das default VLan (1) als auch in der FB festgelegt.

Das USG ist an einem Port vom Cisco angeschlossen und kann über 192.168.1.1 erreicht werden. DHCP habe ich dort zuerst deaktiviert.

Wie mache ich jetzt weiter: Ich erstelle das erste VLAN (10) in das das USG kommen soll oder verwende ich dafür gleich das default Vlan1? In diesem sind meine alle AP´s und der Server als untagged Trunks markiert und alle Ports mit Berechtigung ins Internet inkl. des jetzt zur FB und später zum USG gehenden sind als Accessmember festgelegt. korrekt?
Bitte warten ..
Mitglied: aqui
15.12.2020, aktualisiert um 15:55 Uhr
ich habe es nicht geschafft den Trunkport (an dem jetzt die Fritzbox dran hängt und zwischen den dann dass USG soll) zu entfernen.
Die FritzBox darf niemals an einem Trunk Port (Tagged Port) hängen, denn bekanntlich supportet die FritzBox keinereli VLAN Funktion und kann mit Tagging nichts anfangen. Klar das das in die Hose geht...
Die FritzBox darf immer nur an einen UNtagged Access Port angeschlossen werden eben wegen ihrer fehlenden VLAN Funktion !
Übrigens hätte eine Screeshot des Port Setups hier sicher geholfen... ;-) face-wink
So oder so ist es aber besser und sauberer du fängst mit einem Reset nochmal neu an. Also intuitiv alles richtig gemacht. ;-) face-wink
ich habe die IP sowohl für das default VLan (1) als auch in der FB festgelegt.
Etwas verwirrend... Wie meinst du das ? FritzBox: 192.168.178.1 /24 und Switch VLAN 1 IP: 192.168.178.254 /24 ? Das wäre dann OK aber kann niemals sein weil du die USG dazwischen vergessen hast !!!
Die FritzBox arbeitet doch mit der USG in einer Kaskade. Sprich also WAN Port der USG ist im FritzBox LAN z.B. .178.254 und der Switch hängt am LAN der USG. Das USG LAN muss logischerweise in einem anderen IP Netz liegen und damit dann auch die VLAN 1 IP des Switches.
FritzBox und Switch sind doch nicht direkt verbunden !!
Gleich darf die IP natürlich auch keinesfalls sein denn doppelte IP Adressen sind verboten. Weist du ja auch sicher selber ?!
Wie mache ich jetzt weiter:
Du baust im ersten Schritt einzig und allein erstmal nur die Kaskade auf und nur das Default VLAN 1 auf dem Switch.
So sieht das dann aus:

usg3 - Klicke auf das Bild, um es zu vergrößern

Denke dir in diesem ersten Schritt alle VLANs außer 1 weg. Das kommt im 2ten Schritt. Du setzt erstmal nur die Grundkonfig mit VLAN 1 auf !
Das ist das Grundsetup was wasserdicht funktionieren muss !! Sprich also ein Client an einem Access Switchport in VLAN 1 muss eine IP über den DHCP Server entweder in der USG oder Switch bekommen und über das USG und über die FritzBox ins Internet kommen und dort fröhlich surfen können. (Vorsicht: DHCP Server darf hier im VLAN 1 nur entweder der Switch oder die USG spielen. Niemals beide parallel !)
Rennt das alles, machen wir mit den VLANs im Switch weiter !
Bitte warten ..
Mitglied: DrPfiend
15.12.2020 um 16:22 Uhr
Ich drehe mich leider hier im Kreis. USG ist jetzt zwischen FB und Switch gehangen, das war davor, wie ich schrieb,noch nicht der Fall! Da hatte ich die USG ohne WANverbindung nur per LAN als Client am Switch. Daher auch die festen IP´s auf Switch und FB.

Stand jetzt: Zugriff auf das USG über jeden Client des Cisco möglich. IP des Switch ist vom USG ín der LAN IP-Range vergeben worden, kann nicht geändert werden. DHCP vom USG ist an, schalte ich es aus, habe ich keinen Zugriff mehr auf den Switch.
DHCP in der FB ist auch an, IP fest . WAN in der USG auf DHCP, DNS ist die IP der FB. Zugriff vom LAN der FB auf den Router geht auch nicht.
Bitte warten ..
Mitglied: aqui
15.12.2020, aktualisiert um 16:45 Uhr
USG ist jetzt zwischen FB und Switch gehangen, das war davor, wie ich schrieb,noch nicht der Fall!
Tja, das war ja leider immer das Verwirrende bei dir. Mal so mal so... Oben schreibst du das du es so mit USG aufbauen willst redest aber vom FritzBox Netz was sich widerspricht. Dann ist nur die Lösung mit der FritzBox, dann wieder nicht....

Wenn du die USG GAR NICHT benutzen willst dann sieht das Design natürlich etwas anders aus:
usg4 - Klicke auf das Bild, um es zu vergrößern
Auch hier: Erstmal alles nur mit VLAN 1 aufbauen. Internet muss klappen. Dann kommen die restlichen VLANs.
DHCP vom USG ist an, schalte ich es aus, habe ich keinen Zugriff mehr auf den Switch.
Sorry, aber weisst du selber das das technischer Unsinn ist. Was hat denn ein DHCP Server mit der IP Erreichbarkeit eines Hosts im Netz zu tun. Es sei den natürlich die statische IP des Switches liegt mittem im DHCP Bereich.
Der Switch muss eine statische IP außerhalb jeglichen DHCP Bereiches haben !!! Idealerweise nimmt man bei 24er Prefixes immer die IPs ganz oben oder ganz unten und legt den DHCP Pool mit einem Sicherheits Abstand dazu an. Z.B. .1 bis .5 und .250 bis .254 und den Pool von .50 bis .230 oder sowas. Banale Adressierungs Grundlagen... ;-) face-wink

Vielleicht solltest du wirklich im stillen Kämmerlein zuerst einmal in dich gehen und in Ruhe klären WELCHEN Netzdesign Weg du denn nun gehen willst.
Ansonsten drehen wir uns hier wirklich alle sinnfrei im Kreis was bekanntlich wenig Spaß macht. :-( face-sad
Bitte warten ..
Mitglied: DrPfiend
15.12.2020 um 16:55 Uhr
Das Netzdesign habe ich doch schon im ersten Post festgelegt. Der Switch soll DHCP Server sein, das USG zwischen FB und Switch, so wie im 2. Bild von dir sehr anschaulich dargestellt.

Das Problem war erstens, dass ich den USG überhaupt nicht gefunden habe, daher habe ich alle Kombinationen ausprobiert. An die FB per LAN an den Cisco per LAN bis ich den gefunden habe. Jetzt ist alles wie geplant verkabelt aber es funktioniert halt nicht.

Ich komme von beiden Seiten des USG nicht auf die jeweils andere. Die Fritzbox hat doch ein eigenes IP-Netz?! in dem befindet sich das USG. Dann habe ich eine IP-Route in der FB angelegt für den IP Bereich des USG mit dem Gateway IP USG im FB Netz.

FB 192.168.178.1 DHCP ein mit fester IP für das USG 192.168.178.254
USG seite: WAN DHCP Gateway von der FB
LAN USG: DHCP ein gateway (IP USG) 192.168.1.1

Daraus resultiert, dass ich die IP des Switch nicht ändern kann und das oben Geschriebene.
Bitte warten ..
Mitglied: DrPfiend
16.12.2020, aktualisiert um 10:15 Uhr
Zitat von @aqui:
Sorry, aber weisst du selber das das technischer Unsinn ist. Was hat denn ein DHCP Server mit der IP Erreichbarkeit eines Hosts im Netz zu tun. Es sei den natürlich die statische IP des Switches liegt mittem im DHCP Bereich.
Der Switch muss eine statische IP außerhalb jeglichen DHCP Bereiches haben !!! Idealerweise nimmt man bei 24er Prefixes immer die IPs ganz oben oder ganz unten und legt den DHCP Pool mit einem Sicherheits Abstand dazu an. Z.B. .1 bis .5 und .250 bis .254 und den Pool von .50 bis .230 oder sowas. Banale Adressierungs Grundlagen... ;-) face-wink

Ich denke hier liegt das Problem. Der Switch hat eine dynamische IP für VLAN1 (vergeben vom USG oder der Fritzbox, je nachdem, wer zuerst dran war nach dem Reset) die ich NICHT ändern kann. ich kann zwar auf statisch umstellen aber die IP über das GUI nicht ändern. Daher liegt die IP immer im DHCP-Pool des Gerätes, dass eigentlich gar kein DHCP Server sein soll und ist nach dem Deaktivieren des Letzteren nicht mehr erreichbar.

Ich habe einen Pool für VLAN1 im Cisco angelegt, (.50-.200) mit Defaultrouter auf der xxx.1.1 aber DHCP kann ich nicht enablen weil DHCP clients am iInterface hängen...
Bitte warten ..
Mitglied: aqui
16.12.2020, aktualisiert um 11:05 Uhr
ich kann zwar auf statisch umstellen aber die IP über das GUI nicht ändern.
Das ist natürlich Unsinn. Bei jedem Switch kann man bzw. muss man die IP Adresse auf eine statische ändern können. Das geht natürlich auch beim Cisco egal ob GUI oder CLI.
Bei dir ist das essentiell und zwingend nötig, da du ja routen willst mit dem Switch und die VLAN IP Adressen die Router Interfaces darstellen. Muss man sicher nicht weiter erläutern warum dort dynamische DHCP Adressen Unsinn sind.
Wenn du es im GUI nicht hinbekommst ziehst du den Switch halt ab von USG oder FB und rebootest ihn isoliert. Dann hat der Switch eine feste statische Management IP 192.168.1.254
https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/350xg/admin ...
Seite 9
Die connectest du dann via Browser im VLAN 1 und überschreibst sie im GUI mit einer statischen deiner Wahl. Den DHCP Client deaktivierst du natürlich !
gui - Klicke auf das Bild, um es zu vergrößern
Obwohl das Ziehen nicht wirklich erforderlich ist. In einem schnellen Test hier auf einem SG350X funktionierte das auch mit einem aktiven DHCP Client VLAN Interface ohne jegliche Probleme. Was du oben behauptest ist also de facto unrichtig ! Was immer geht ist auf "Add" klicken und ein neues VLAN 1 Interface anlegen mit deiner neuen IP und nachher mit "Delete" das ursprüngliche Interface zu löschen. ;-) face-wink

Solltest du das wider Erwarten per GUI dennoch nicht schaffen, dann gehst du eben per Telnet oder SSH (z.B. mit PuTTY) auf den Switch und machst das über das CLI. Auch das klappt sofort:
Switch#conf t
Switch(config)#int vlan 1
Switch(config-if)#no ip address dhcp
Switch(config-if)#ip address 192.168.1.254 255.255.255.0
Switch(config-if)#exit
Switch(config)#exit
Switch#write mem

Fertisch !
Gibst du ein show run ein sieht das dann so aus:

interface vlan 1
name "Lokales VLAN-1"
no ip address dhcp
ip address 192.168.1.254 255.255.255.0

Und schon hat dein VLAN die gewünschte statische IP Adresse !
Bitte warten ..
Mitglied: DrPfiend
18.12.2020, aktualisiert 21.12.2020
Super, der Tipp, eine neue VLAN 1 Verbindung zu erstellen und die Alte zu löschen hat sofort funktioniert.

Ich hatte davor sowohl über den USG, als auch über den Router, als auch über die Direktverbindung nach dem Reset folgendes Bild:

bild_2020-12-18_120344 - Klicke auf das Bild, um es zu vergrößern

Über FB und USG war jeweils dynamisch voreingestellt, nach dem Reset über Direktverbindung (Rechner hatte die IP 192.168.1.200/24) statisch. Die IP Adresse war in jedem Fall nicht veränderbar. Ich hoffe heute kommt noch der Vigor, dann geht es weiter. Jetzt habe ich vorerst ein funktionierendes VLAN1 mit USG und FB.

Ich melde mich wenn es weiter geht.
Bitte warten ..
Mitglied: aqui
19.12.2020 um 10:08 Uhr
als auch über die Direktverbindung nach dem Reset folgendes Bild:
Wenn du bei den eingebetteten Bilder auch mal das "+" Zeichen an die richtige Stelle klickst wie es in der Beschreibung steht, dann erscheint das Bild auch im richtigen Kontext deines Threads und nicht ohne Bezug, verwirrend irgendwo am Ende... ;-) face-wink Kann man übrigens noch nachträglich mit "Bearbeiten" (rechts unter "Mehr") anpassen...
Jetzt habe ich vorerst ein funktionierendes VLAN1 mit USG und FB.
Perfekt !
Dann kannst du jetzt auch weitere VLANs mit VLAN IP einrichten auf dem Switch. Default Route 0.0.0.0/0 dann via VLAN 1 IP auf die USG und in der USG eine statische Route der VLAN IP Netze auf die VLAN 1 IP des Switches. Und schon rennt dein oben gepostetes Wunschdesign ! ;-) face-wink
Ich melde mich wenn es weiter geht.
Wir sind gespannt...! :-) face-smile
Bitte warten ..
Mitglied: DrPfiend
21.12.2020, aktualisiert 22.12.2020
Es geht weiter,

die Fritzbox wurde durch eine Vigor 166 ersetzt. Der Aufbau entspricht jetzt in etwa dem des o.d. -Switch im L3 Mode "IP Routing"- bis auf den Wegfall des Koppelnetzes und des Gateway im USG. In diesem Zuge habe ich auch auf die standardisierte Bezeichnung des Class-B Netzes (kannte ich vorher gar nicht, Danke für diese Wissensvermittlung!) umgestellt mit statischer Route im Unifi Controller 172.16.0.0/16
Hier hatte ich wirklich erhebliche Probleme das USG in den Controller einzubinden, wenn der Switch DHCP Server war. Das USG ist ständig auf die Default IP zurückgesprungen obwohl im Controller ganz klar alles definiert war. mit DHCP im USG hat es dann geklappt, dann wieder alles zurückgestellt.

Stand jetzt: Alle Netzwerkgeräte haben mehr oder weniger Zugriff auf das Internet. Mich wundert, das einige Zugänge bspw. auf der Nvidia Shield über Ethernet: Netflix läuft die ARD App aber "kein Internetcerbindung" meldet. Das defaultgateway im Cisco ist als statische Route eingetragen 0.0.0.0/0 eine Eintragung als default gateway habe ich nicht gefunden, ist das korrekt? Woran könnte diese Reglementierung noch liegen?
bild_2020-12-21_215155 - Klicke auf das Bild, um es zu vergrößern
Internetzugriff habe ich mehr oder weniger wie oben beschrieben über alle im VLAN1 definierten kabelgebundenen Geräte. WLAN geht natürlich noch nicht, da mache ich mich morgen dran, diese dann in den Unifi Controller einzubinden. Diese werden ja als neues Netzwerk in diesem hinterlegt und eine SSID für das im CIsco erstellte VLAN vergeben. Hier brauche ich noch etwas Zeit...

Die Fritzbox war ja mein Zeitserver im Netzwerk, wie wird das ohne das Vorhandensein dieser realisiert.

P.S.Nachdem ich im DHCP Pool unter Option 3 auch die IP des Gateways eingetragen habe läuft jetzt alles ins Internet ohne App-Beschränkung etc, ich weiß aber nicht warum...
bild_2020-12-22_102939 - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
22.12.2020 um 11:56 Uhr
auf die standardisierte Bezeichnung des Class-B Netzes
Netzwerk Klassen gibt es schon seit 1993 mit der Einführung des CIDR_Standards nicht mehr. Das sollte eigentlich auch langsam bei dir angekommen sein ?! ;-) face-wink
Das defaultgateway im Cisco ist als statische Route eingetragen 0.0.0.0/0 eine Eintragung als default gateway habe ich nicht gefunden, ist das korrekt?
Ja, das ist korrekt !
Woran könnte diese Reglementierung noch liegen?
Was meinst du mit "Reglementierung" ??
Wenn du aus allen deinen VLANs mit einem Testrechner fehlerlos eine Internet IP wie z.B. ping 9.9.9.9 UND auch einen Hostnamen wie ping www.heise.de anpingen kannst hast du ja nachweislich einen sauber Internet Zugang und korrekte DNS Auflösung aus allen deinen VLANs.
Netztechnisch ist dann alles erledigt, denn Switch und Router arbeiten ja rein nur auf Layer 3.
Was dann ggf. noch für Firewall Regeln und Einstellungen auf deiner Firewall greifen ist eine ganz andere Geschichte. Nur die kann dann noch weitere Traffic Reglementierungen machen. Zu diesem Regelwerk sagst du leider rein gar nichts so das man da nur im freien Fall raten kann. :-( face-sad
Die Fritzbox war ja mein Zeitserver im Netzwerk, wie wird das ohne das Vorhandensein dieser realisiert.
Indem du stattdessen einen lokalen Timeserver nutzt:
https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html
Vermutlich kann deine USG auch NTP Zeitserver spielen.
Nachdem ich im DHCP Pool unter Option 3 auch die IP des Gateways eingetragen habe läuft jetzt alles ins Internet. ich weiß aber nicht warum...
Erklärung ist eigentlich ganz logisch und leicht....
Da lag der Fehler etas zwischen den Kopfhörern (PEBKAC Problem) ! ;-) face-wink
Das funktioniert natürlich auch im "Auto" Mode allerdings hättest du oben die Netzwerk Adresse dafür setzen müssen was du nicht getan hast. Generell ist das schon ein Konfig Fauxpass im DHCP !!
Unter Subnet IP Address gehört natürlich 172.16.1.0 hin damit das für den Pool eindeutig ist.
Du hast das aber letztlich aber intuitiv richtig gemacht, denn "Auto" würde die VLAN IP Adresse des Switches vergeben. Das VLAN 1 ist aber ein Sonderfall, da dies ja das Koppelnetz zur USG ist indem sich normal ja gar keine Clients befinden. Hier macht es natürlich wenig Sinn die Switch IP den Endgeräten (die eigentlich da gar nicht sein sollten) zu geben sondern das kann dann sinnvollerweise direkt die USG IP sein, denn warum sollte lokaler VLAN 1 Traffic der Clients nochmal als "Durchlauferhitzer" über die Switch IP im gleichen VLAN gehen bevor es zur USG IP im gleichen VLAN geht.
Insofern ist das richtig, gilt aber NICHT für alle anderen VLANs !! Dort muss das Gateway für die Endgeräte immer die Switch IP sein, denn der Switch routet da ja zw. den VLANs. DNS ist dann dort auch die USG IP 172.16.1.1.

10 Tage Leasetime ist keine intelligente Idee. Das belastet den Pool stark mit geblockten IPs. Hier solltest du maximal auf 3 Tage gehen. Normal ist ein Tag. Aktive Geräte machen so oder so immer ein Renewal bei Ablauf der Leasetime und behalten ihre IP.
Bitte warten ..
Mitglied: DrPfiend
23.12.2020, aktualisiert um 01:05 Uhr
Heute kam die Gigaset N510 DECT Basis, diese habe ich erstmal an den Cisco geklemmt und die Telefonie funktioniert wieder komplett. Adressbücher übertragen, geht vorerst. Ich habe allerdings gelesen, dass Telefonie in einem eigenen VLAN besser aufgehoben ist.

Nun zur VLAN-Geschicht:. Die entsprechenden VLANs habe ich erstellt, der Cisco hat in jedem VLAN eine IP und vergibt als DHCP Server automatisch die IP´s an die verbundenen Geräte. Was noch nicht klappt ist der Internetzugriff aus den VLANs (nicht VLAN1) Zudem habe ich festgestellt, dass ich alle Geräte und Router IP´s anpingen kann, wenn ich mit dem Rechner selber einem anderen VLAN bin, nur aus dem VLAN1 klappt das nicht. Ein Ping auf bspw. eine Router IP eines anderen VLANs liefert stets: Antwort von 172.16.1.1 (USG): Zielhost nicht erreichbar. (keine Pakete verloren) Ich denke hier fehlt es an einer entsprechenden Rückroute im USG, aber habe ich das nicht mit der statischen Route 172.16.0.0/16 in der USG erledigt? Eine statische Route im Cisco wäre ja in diesem Fall nicht zielführend.

bild_2020-12-23_003236 - Klicke auf das Bild, um es zu vergrößern

Zweiter Teil die WLAN´s. Ich möchte 3 WLANs haben eins für home, eins für iot ohne Internetzugriff und eins für Gäste. Die VLAN´s dafür sind ja erstellt. Die Unifi AP´s und der VM server sind für alle drei als tagged trunk (letzterer für gast untragged).
Im Unifi controller habe ich die Netze erstellt:
10 - Klicke auf das Bild, um es zu vergrößern
Was mache ich jetzt mit dem Gast-WLAN. Das hat ja keinen Pool auf dem Cisco. Der hat in diesem Subnetz aber eine IP. Wenn ich das USG jetzt als DHCP Server in diesem VLAN agieren lasse, werden die IP´s aber im Subnetz 172.16.1.0/24 vergeben. Das schein mir unsauber oder?
bild_2020-12-23_005125 - Klicke auf das Bild, um es zu vergrößern

Aqui, ich denke ich bin hier durch deine ganze Hilfe schon gut voran geschritten. An dieser Stelle daher ein herzliches Zwischendankeschön! :-) face-smile
Bitte warten ..
Mitglied: aqui
23.12.2020, aktualisiert um 14:35 Uhr
dass Telefonie in einem eigenen VLAN besser aufgehoben ist.
In Firmennetzen ist das auch schon aus gesetzlichen Gründen (Fernmeldegeheimnis) immer Pflicht aber in privaten Netzen ist das Geschmackssache.
nur aus dem VLAN1 klappt das nicht.
Das ist auch ganz klar warum das nicht geht ! Denke mal selber etwas nach... ;-) face-wink
Im VLAN 1 hast du als Cleint Gateway die USG und die USG hat ganz sicher keine statische Route auf die Switch IP Adresse. (Sceenshots dieser Route fehlen oben !)
Sprich also Traffic der aus einem der nicht VLAN 1 VLANs auf dem USG ankommt hat keine Rückroute mehr und scheitert so.
Folglich schlägt also jeglicher Zugriff aus den VLANs via Internet also auch Traffic der vom VLAN 1 in die Switch VLANs geht sofort fehl wegen dieser fehlenden VLAN Route.
In den Switch VLANs haben die Clients ja immer die Switch IP als Gateway und deshalb können so alle anderen VLANs problemlos erreicht werden. Außer VLAN 1 natürlich. Dort haben die Clients als Gateway nicht die Switch IP sondern die USG IP, würden deshalb also Rücktraffic in die anderen VLANs erst ans USG schicken, dort fehlt aber, wie bereits gesagt, die Rückroute und dann scheitert die Verbindung.
Es ist alles alles logisch das es nicht geht... ;-) face-wink

Der Screenshot der USG VLAN Route ist natürlich Blödsinn, denn die 172.16er Netze dürfen ja niemals auf die Schnittestelle "default" geroutet werden denn dann landen sie logischerweise beim Provider im Nirwana.
Das das falsch ist sagt einem eigentlich schon der gesunde Menschenverstand.
Richtig wäre dort Folgendes anzugeben beim Erstellen einer neuen statischen Route:
  • Name: VLANs
  • Haken: Route aktivieren
  • statisch
  • Zielnetz: 172.16.0.0 /16
  • Typ: Nächster Hop
Danach sollte sich ein IP Adress Eingabefeld aufmachen in dem man die IP Adresse der VLAN 1 IP des Switches einträgt ! Schnittstelle müsste logisch auf "VLAN1" stehen aber vermutlich kann das dieser gruselige Ubiquity Müll nicht ?!
Eine statische Route im Cisco außer der Default Route ist in der Tat Unsinn. Die Default Route im Cisco routet ja alles was der Cisco lokal nicht kennt an die USG VLAN 1 IP und das reicht ja denn. Die USG sollte ja wissen wo alles hingeht...sollte...wenn denn Routing und Regelwerk stimmen ?! ;-) face-wink
Was mache ich jetzt mit dem Gast-WLAN. Das hat ja keinen Pool auf dem Cisco. Der hat in diesem Subnetz aber eine IP
Das ist richtig und einen Gefahr, denn das Gastnetz darf natürlich niemals auf dem Cisco enden und dort geroutet werden.
Die Lösung ist aber kinderleicht.
Du entfernst einfach die Gast VLAN IP Adresse auf dem Cisco. Damit ist ein Routing dort physisch unmöglich.
Du musst das Gast VLAN dann auf die USG "durchschleifen" und dort auf einem VLAN Interface terminieren genau wie du es mit dem VLAN 1 gemacht hast.
Das setzt dann voraus das du den Switch Uplink zur USG in den Mode: "Trunk" ändern musst und das Gast VLAN dort tagged übertragen musst.
Auf der USG dann analog. Der physische Port muss auch ein Trunk (tagged) Uplink sein über das dann das VLAN 1 und das Gast VLAN auf der USG mit VLAN Ports terminiert wird. DHCP fürs Gast VLAN kommt dann auch von der USG.
So hast du beide VLANs auf der USG liegen und kannst hier mit einem entsprechenden Regelwewrk und einem Gäste Captive Portal das Gastnetz entsprechend steuern.
Wie so ein Tagged Uplink (Trunk) auf einer Firewall terminiert wird kannst du dir am pfSense_Beispiel_im_VLAN-Tutorial ansehen. Das dürfte auf der USG Gurke mehr oder minder identisch sein.
An dieser Stelle daher ein herzliches Zwischendankeschön!
Immer gerne und danke für die weihnachtlichen Blumen ! ;-) face-wink
Dein Setup sieht dann so aus (Auszug)
test - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: DrPfiend
23.12.2020, aktualisiert um 15:43 Uhr
Das heißt also, aus dem VLAN 1 darf es per se keinen Zugriff auf die anderen VLANs geben?!
bild_2020-12-23_152433 - Klicke auf das Bild, um es zu vergrößern
Hier hatte ich Schnittstelle "LAN" eingetragen, jetzt die IP vom Cisco. Anbei die Netzwerke:
13 - Klicke auf das Bild, um es zu vergrößern
GatewayIP für home und iot ist jeweils der Router im entsprechenden VLAN. Bei guest ist es das USG.

Am Router sind alle AP´s und der Server (wobei der primär gar nicht in das VLAN soll sondern in VLAN20) im VLAN1 (noch nicht mit festen IP) als untagged markiert. Für die restlichen VLAN´s stehen Sie als tagged drin.
bild_2020-12-23_153304 - Klicke auf das Bild, um es zu vergrößern
Kann es sein, dass ich das L3-Switching gar nicht aktiviert habe trotz IPvP4 routing? Im Interface Setting steht im Switchport mode bei allen L2. Änderungen für einen einzelnen Port haben keine Auswirkungen in der Membership-Übersicht. Port 26 ist der Uplink zum USG. Ich kann mit diesen Einstellungen einem nicht Trunk-Port nicht untagged VLAN1 und tagged VLAN40 gleichzeitig angehören.
bild_2020-12-23_153543 - Klicke auf das Bild, um es zu vergrößern

Für mich als Laien wird die Anfrage von jedem Client aus allen VLANs ans USG weitergeleitet. Der schickt die Anfrage ins Internet, kann aber die "Antwort" nicht zurück an die VLANS schicken. obwohl die statische route für alle "Netze" des Routers gilt oder ist diese Route nur eine Einbahnstraße?!
Bitte warten ..
Mitglied: aqui
23.12.2020 um 16:15 Uhr
Das heißt also, aus dem VLAN 1 darf es per se keinen Zugriff auf die anderen VLANs geben?!
Nein !
Wie kommst du jetzt auf den wirren Unsinn ??
VLAN 1 ist weiterhin das zentrale Koppelnetz auf deine Switch VLANs. Muss es ja, denn du routest ja alle VLANs zentral am Switch. Jedenfalls hast du gesagt das du das tun willst...
Das Gast VLAN darf aber keinesfalls eine IP Adresse am Switch haben denn das willst du ja zu Recht aus Security Gründen da nicht routen. Folglich also schleift man es schlicht und einfach im Layer 2 durch und legt es IP Routing seitig mit seiner IP auf die USG. Fertisch...
Nichts anderes wird oben gemacht und zeigt auch noch einmal das Übersichstbild was du scheinbar übersehen hast ?!

Rein technisch gesehen kannst du natürlich auch das Gast VLAN L3 seitig am Switch terminieren aber dann musst du zwingend dort mit Access Listen arbeiten um das Gast Netzwerk von den anderen zu isolieren. Der L3 Switch ist ja keine Firewall....
Das wäre aber designtechnischer Unsinn, denn
  • ACL sind nicht Stateful
  • Du hast doppeltes Security Management
  • Wozu hast du eine Firewall die das besser kann
3 triftige Gründe also das Gastnetz NICHT L3 seitig auf den Switch zu legen sondern auf die USG.

Kann es sein, dass ich das L3-Switching gar nicht aktiviert habe
Das kann natürlich sein !! Leider fehlt ein entsprechender Screenshot dazu von dir. :-( face-sad
Du solltest also erstmal das Setup Menü oben rechts auf Advanced klicken.
Dann findest du unter IP Setup den entscheidenden Haken:
https://administrator.de/images/c/1/6/644d759b869bc8d280d51c8f1696e88f.j ...
Ist der gesetzt dann ist auch IP Routing, sprich L3 Switching aktiv wenn du den VLANs unten in der "Interface Table" entsprechende IPs auf dem Switch gegeben hast.
route - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: DrPfiend
23.12.2020, aktualisiert um 16:56 Uhr
Also der Haken ist gesetzt. Dann ist L3 aktiv, mich hat nur das L2 im Switchport mode irritiert.
bild_2020-12-23_165549 - Klicke auf das Bild, um es zu vergrößern

Der Cisco-Router hat keine IP im Gäste-VLAN kennt aber das VLAN. über die standard default-Route werden ja mmn. auch sämtliche Anfragen aus diesem VLAN an die USG durchgeschleift. Der Router ist somit in Bezug Gästebetreuung raus.

Aber, Beispiel:
Es meldet sich ein Gast an einem Gasthotspot genau wie ich an einem AP an. Das heißt der AP ist als Trunk in beiden VLAN tagged und versieht meine Geräte IP mit einem Tag. Wie kann er das Gastgerät taggen, wenn der Switch für das Gerät gar keine IP hat. Die wird ja erst vom USG verteilt. Wird dann quasi nur eine Anfrage mit Tag übermittelt?

Ich bin hier immer noch an dem Punkt, dass ich aus den nicht VLAN1 VLANs kein Internetzugriff habe und das ich bspw. den Uplink nur als untagged Accessport dem VLAN1 zufügen kann. eine Ahnung woran das liegt? Die Pools der einzelnen VLANs haben als Default-Router-IP die jeweilige VLAN SwitchIP und als DNS das USG.
bild_2020-12-23_165346 - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
23.12.2020, aktualisiert um 18:31 Uhr
Das heißt der AP ist als Trunk in beiden VLAN tagged und versieht meine Geräte IP mit einem Tag. Wie kann er das Gastgerät taggen, wenn der Switch für das Gerät gar keine IP hat.
Du machst hier einen gehörigen Denkfehler. VLANs sind eine reine Layer 2 Funktion !!!
Mit IP Adressen hat das rein gar nichts zu tun. Der VLAN Tag liegt am Layer 2 Ethernet Frame also auf Mac Ebene und niemals am IP Header wie du oben behauptest: Guckst du hier:
https://de.wikipedia.org/wiki/IEEE_802.1Q

Mit dem Gast geht das grob erklärt so:
  • Gast connected sich mit der Gast SSID und AP tagged damit alle Paket die von der Gast SSID kommen
  • Connecteter Client schickt einen DHCP Request Broadcast um eine IP zu erlangen
  • Der Broadcast wird vom MSSID AP mit dem Gast VLAN Tag am Frame via Layer 2 über die Trunk Links an die USG durchgereicht denn da ist ja jetzt statt Switch das L3 Interface fürs Gastnetz.
  • USG empfängt den Frame und weiss anhand des VLAN Tags auf welches VLAN IP Interfaces es diesen Frame zu forwarden hat.
  • USG beantwortet den DHCP mit einem Offer von seinem DHCP Server, hängt den Gast VLAN Tag wieder ans Frame der dann via Layer 2 zurück über die Tagged Uplinks zum AP kommt.
  • Der AP strippt die Tags ab und sendet auf der WLAN Schnittstelle in der Gast SSID den Offer an den Client
Et voila...so gehts.
Fazit:
Nochmal genau die VLAN Funktion nachlesen und verstehen... ;-) face-wink
immer noch an dem Punkt, dass ich aus den nicht VLAN1 VLANs kein Internetzugriff habe
Das liegt sehr wahrscheinlich daran das du keine statische Route in deine VLAN Netze auf dem USG definiert hast. Damit scheitert die Rückroute und damit die Internet Verbindung !
Was passiert denn wenn du aus diesen VLANs mal eine Traceroute auf die 8.8.8.8 machst. tracert 8.8.8.8 unter Winblows.
Wo kommt das Paket nicht mehr weiter ?? Genau da liegt der Fehler !
Hilfreich wäre auch mal die Routing Tabelle des USG zu posten um dein Routing dort zu checken.

Du kannst ja auch einfach mal einen Client im VLAN 1 als Gateway die Switch IP Adresse im VLAN 1 setzen. Dann wirst du sehen das das Routing innerhalb der Switch VLANs sauber funktioniert.
Du kannst vermutlich auch die VLAN 1 IP Adresse des USG 172.16.1.1 nicht pingen aus den anderen VLANs, richtig ??
Das spricht dann für die fehlende Route auf dem USG.
Kannst du sie pingen aber 8.8.8.8 nicht dann spricht das für ein falsches oder fehlendes Regelwerk oder NAT für diese IP Netze in der USG und damit einer Fehlkonfig.
Bitte warten ..
Mitglied: DrPfiend
23.12.2020 um 20:20 Uhr
Es ist schon unheimlich. Deine Vermutungen die Pings betreffend, kann ich allesamt bestätigen. Es lag in der Tat an den fehlenden statischen Routen auf dem USG. Um diese zu erstellen musste ich allerdings die Netzwerke, so wie ich sie erstellt hatte löschen, da die statische Route nicht zwischen einem Gateway und einem Netzwerk aufgespannt werden kann, das Teil des USG Netzwerks ist. Die Netzwerke sind jetzt als "Reine VLANs" hinzugefügt. Und jetzt komme ich mit auch mit den ganzen Netzwerkgeräten per WLAN und kabelgebunden ins Netz...

Ich bin immer davon ausgegangen, dass mit der 172.16.0.0/16 alles zurück auf den Cisco geht und der dann zwischen den VLANs schon dafür sorgt, dass jeder seinen Happen bekommt. Phuu... hartes Stück Arbeit, für mich und für dich.
Gäste kommen Weihnachten eh keine die das Gästenetz benötigen, dem widme ich mich später.

Für Geschenke ist es zwar noch etwas früh, aber hast du, aqui, eine digitale Kaffeekasse oder eine statische Route zur IP eben dieser?
Bitte warten ..
Mitglied: aqui
24.12.2020, aktualisiert um 00:35 Uhr
Ich bin immer davon ausgegangen, dass mit der 172.16.0.0/16 alles zurück auf den Cisco geht
Das ist auch richtig so und die richtige Route. Damit würde sämtlicher Traffic der in alle 172.16.x.y Netze geht an die VLAN 1 IP Adresse des Switches geroutet. Der routet sie dann wieder auf die dedizierten VLANs.
Da die lokalen 172.16er IP Netze an der USG einen kleineren Prefix haben werden die dort lokal geroutet.
Eine einzige Route auf der USG mit dem /16er Prefix reicht also vollkommen aus um die Rückrouten aller 172.16er VLAN Netze auf den Cisco zu routen.
Es ist also völlig unsinnig alle /24er Netze auf der USG einzeln einzugeben.
Wenn sich die Switch Subnetze im Bereich .0 bis .63 bewegen würde auch ein 18er Prefix reichen. Es gilt:
  • /18 = 255.255.192.0 = 172.16.0.0 bis 172.16.63.254
  • /17 = 255.255.128.0 = 172.16.0.0 bis 172.16.127.254
Man kann hier also beliebig mit der Maske spielen...eine einzige Route reicht.
Fazit: Du bist also schon vom richtigen und logischen ausgegangen und hast richtig gedacht: Wie bereits gesagt: Eine Route mit größerem Prefix reicht völlig.
eine digitale Kaffeekasse
Wenn dann Glühweinkasse ;-) face-wink Nee alles gut, ist ja Weihnachten.
Bitte warten ..
Mitglied: DrPfiend
09.01.2021, aktualisiert um 18:57 Uhr
Hi! Gesundes neues Jahr. Es geht weiter mit meinem Projekt.

Ich habe jetzt im neuen Jahr fast Alles wie geplant umsetzen können. Das Netzwerk läuft ganz hervorragend, Proxmoxserver mit vielen LXC´s und VM´s läuft prima. Pihole arbeitet mittlerweile als DNS-Server und die ganzen Bridges für Zigbeegeräte sind Dank Conbee 2 zu den Kleinanzeigen gewandert.

Probleme habe ich noch beim Gastnetzwerk. Dieses ist im Cisco Router nur als separates VLAN angelegt und die Unifi-AP´s tagged an den entsprechenden Ports. Der Cisco wie besprochen ohne IP in diesem Netzwerk. Für dieses Subnetz soll ja das USG DHCP Server sein. Nun stellt sich mir natürlich die Frage, wie kann das USG hier DHCP Server sein, wenn es gar keine IP in diesem Subnetz hat? Ich finde in diesem Schickimicki-UI einfach nicht die Möglichkeit wie beim Cisco eine zusätzliche (Neben der als Standardgateway) IP zu vergeben und diese dann als Gateway für das Gästenetz zu verwenden. Bzw. ist automatisch die xxx.xx.xx.1 als Standardgateway ausgewählt, ich lege nur das Subnetz fest. Statische Route scheint mir nicht zielführend. Kenn sich jemand in der Unifi-Controllersoftware aus?

Des weiteren kommen vom Cisco permanent Anfragen an: time-a.timefreq.bldrdoc.gov (tim-a, time-b und time-c), die ca 90% aller Anfragen aus meinem Netz ans pihole darstellen. Kann man das deaktivieren/reduzieren? Atomuhr muss ich nicht unbedingt haben :-) face-smile
Bitte warten ..
Mitglied: aqui
09.01.2021 um 19:03 Uhr
wie kann das USG hier DHCP Server sein, wenn es gar keine IP in diesem Subnetz hat?
Das geht natürlich nicht, da hast du Recht.
Der Witz ist ja aber das du dieses Gast VLAN ja eben nur ohne IP rein im Layer 2 zur USB "durchschleifst". Logischerweise hat die USG dann mit ihrem Bein in diesem VLAN eine IP Adresse ! Die musst du ihr dann natürlich konfigurieren und auch den DHCP Server dazu.
So bekommen dann alle Gäste IP usw. vom USG ohne das sie irgendeine Verbindung zu den anderen IP Netzen haben. Genau das war ja die Intention !
ch finde in diesem Schickimicki-UI einfach nicht die Möglichkeit
OK, das ist die gerechte Strafe wenn man so einen Ubiquity Müll kauft aber muss dann einer der UBQT Gurus hier benantworten. Oder du musst doch nochmal Handbuch lesen oder googeln. ;-) face-wink
Des weiteren kommen vom Cisco permanent Anfragen an: time-a.timefreq.bldrdoc.gov (tim-a, time-b und time-c), die ca 90% aller Anfragen aus meinem Netz ans pihole darstellen.
Ja, logisch weil du schlicht und einfach vergessen hast im NTP Time Setup des Switches diese US NTP Server zu deaktivieren und nur einen hiesigen aktiv zu halten. Typisches PEBKAC Problem. :-( face-sad
https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html
Bitte warten ..
Mitglied: DrPfiend
06.02.2021 um 14:51 Uhr
Hallo, kurze Rückmeldung von mir, wie es hier weitergegangen ist. Habe auch festgestellt, dass der Titel gar nicht mehr zum jetzt bestehenden Problem passt. Ich habe mit dem USG jetzt mehrere Stunden vergeblich versucht ein Captive Portal einzurichten. Unifi Foren befragt und unheimlich viel ausprobiert. In das Gäste VLAN erfolgt einfach keine Vergabe einer IP durch den USG. Das Gateway soll laut Forumsmitglieder direkt im Controller eingetragen werden. Problem ist, der Cisco hat ja eben keine IP in dem Netzwerk und die AP´s standen schon drin. Alles nicht zielführend... Zudem habe ich versucht den Nextcloudserver über eine externe Verbindung via VPN zu erreichen. Auch hier gibt es scheinbar erhebliche Einschränkungen beim Mischbetrieb von Unifi Geräten mit anderer Hardware.
Ich bin daher den für mich schweren Schritt gegangen, den ich anfänglich vermeiden wollte, habe mir ein Odroid H2+ gekauft und Opnsense darauf installiert. (Hier gibt es bei pfsense noch Probleme mit dem Treiber der Realtek 2,5GB/s NIC´s. Diese werden nicht erkannt und das mounten eines USB Sticks unter FreeDos und händische Installieren der Treiber sowie das Anpassen der bootconfig war mir zu umständlich.)
Meinen Netzwerkaufbau möchte ich gerne so belassen: Firewall nach dem Modem regelt nur den Internetverkehr und das Gästenetz, und der Switch routet zwischen den restlichen VLANs.
Aufbau jetzt: Ports der Firewall entsprechend zugewiesen und entsprechend HowTo Zugangsdaten eingetragen. Am LAN direkt habe ich Internetzugriff, WAN funktioniert also. In der Opnsense habe ich jetzt ein Gateway eingerichtet (Adresse des switch im VLAN1), die LAN Adresse ist im selben Netzwerk. Dann eine Statische Route vom LAN1 an eben dieses Gateway gesetzt. Jetzt sollten doch alle VLANs am Cisco eine Internetverbindung aufbauen können. (Im Cisco ist selbstverständlich die statische Route 0.0.0.0 zur Opnsense gesetzt)?! Die Regeln in der FW für LAN sind unverändert, jeder darf alles.
Bei mir klappt das leider nicht. Ich kann aus allen VLAN die Opnsense anpingen. Daher gehe ich nicht davon aus, dass ich eine Regel für das VLAN1 (das ja das default VLAN des Cisco ist) einrichten muss oder täusche ich mich hier? Oder muss ich zusätzlich neben dem LAN-Port ein VLAN1 definieren mit entsprechenden Regeln?
Die zweite Frage betrifft das Gästenetz. Bei VLAN1 und VLAN40 (guest), die beide getrennt sind, muss ich doch jetzt zwangsläufig die Verbindung des Switch mit der Firewall als Tagged Trunkport einrichten. Sonst würde ich ja doppeltes VLAN Tagging bekommen, richtig? für das Gästenetz soll ja auch die FW DHCP Server sein, was ich als Schnittstelle und DCSP schon eingerichtet habe. Die Kommunikation zwischen der FW und den AP´s erfolgt ja direkt und wird nur über den VLAN-Tag zuordbar. (Die Regeln in der FW dafür habe ich noch nicht eingerichtet.)
Bitte warten ..
Mitglied: aqui
06.02.2021, aktualisiert 07.02.2021
Hier kannst du sehen wie man problemlos ein Gastnetz mit Captive Portal auf der pfSense einrichtet:
https://administrator.de/tutorial/wlan-lan-gastnetz-einrichten-captive-p ...
Das sollte mit der OPNsense absolut identisch sein.
Ansonsten kannst du hier nachlesen wie man Gastnetze z.B. mit einem Mikrotik einrichtet. Das dynamische VLAN kannst du dir wegdenken.

Was man dann noch so drumherum an Einmalpasswort Verwaltung machen kann siehst du hier:
https://administrator.de/contentid/193763
https://www.administrator.de/wissen/captive-portal-plus-pfsense-voucher- ...

Im Grunde ist das alles kein Hexenwerk und mit ein paar Mausklicks im Setup erledigt.
Bitte warten ..
Mitglied: DrPfiend
07.02.2021 um 12:59 Uhr
Hi Aqui,

das Tutorial sieht machbar aus, allerdings sollte vorher, wie auch im HowTo geschrieben, der Zugriff aufs Internet vom LAN aus eingerichtet sein. Hier hapert es allerdings noch. Meine LAN Schnittstelle hat die feste IP x.x.1.1 dazu sind 2 VLAN Schnittstellen eingerichtet (VLAN1(default) und VLAN40(guest)) und dem LAN zugeordnet. VLAN40 habe ich eine statische IP vergeben. Im festgelegten Adressbereich ist die FW DHCP-Server. der VLAN1 Schnittstelle kann ich aber nicht die benötigte IP zuweisen, die hat ja schon das LAN-Interface. Mein Switch ist ja über ein Trunk an die FW angebunden. (VLAN1 untagged, VLAN40 tagged).
Gelten FW Regeln der LAN Schnittstelle für alle VLANs, die dieser zugeordnet sind? Über den LAN Port direkt (also nicht aus VLAN1 des Switches) habe ich Internetzugang....

Zudem noch eine ganz grundsätzliche Frage: DNS Server (pihole) und WLAN-AP´s habe ich jetzt im IP Bereich des Netzes FW-Switch gelegt. Dort sollten aber eigentlich keine Geräte liegen. Der DNS-Server soll ja aber auch für Gäste genutzt werden, weshalb ich den nicht in die privaten VLANs legen möchte. Macht man sich hier einfach einen zweiten Server oder gibt es da elegantere Lösungen?
Bitte warten ..
Mitglied: aqui
07.02.2021 um 13:43 Uhr
der Zugriff aufs Internet vom LAN aus eingerichtet sein.
Das wäre in der Tat essentiell um die Funktion sicherzustellen. ;-) face-wink
Hier hapert es allerdings noch.
Ooops, warum das ?? Das klappt doch schon im Default Setup der FW ohne das man überhaupt irgend eine Konfiguration machen muss ! Sieht dann eher nach einem grundsätzlichen IP Adressierungsproblem aus, kann das sein ?!
dazu sind 2 VLAN Schnittstellen eingerichtet (VLAN1(default) und VLAN40(guest))
Mmmhhhh...da kann schonmal irgendwas nicht stimmen.... Das Default VLAN 1 liegt ja immer untagged am Uplink (Trunk) von der Firewall zum Switch an und das physische LAN Interface (bei dir also das x.x.1.0 /24 Netz, Paren Interface) IST dann immer das Default VLAN, denn das physische Interface wird immer UNtagged gesendet. Nur die VLAN Interfaces sind immer Tagged mit der VLAN ID. In sofern ist deine Einrichtung falsch, denn du bräuchtest ja nur ein VLAN:
  • LAN Interface (physisch, Parent) = UNtagged = .x.x.1.0 /24
  • VLAN Interface 40 = Tagged mit ID 40 = x.x.40.0 /24
VLAN 1 ist also immer das physische LAN Interface. Vermutlich ist das der Denbkfehler den du gemacht hast ?! Das Tutorial spricht das auch mit dem Thema "PVID" explizit an.
habe ich jetzt im IP Bereich des Netzes FW-Switch gelegt.
Bahnhof, Ägypten ?? Welches IP Segment/VLAN soll das sein ??
Der DNS-Server soll ja aber auch für Gäste genutzt werden, weshalb ich den nicht in die privaten VLANs legen möchte
Da gibt es 3 Optionen:
  • Du packst ihn ins Private LAN und erlaubst über das FW Regelwerk rein nur TCP und UDP 53 (DNS) Zugriff aus dem Gastnetz auf den PiHole
  • Du packst ihn in ein separates VLAN getrennt von beidem
  • Du packst ihn schlicht und einfach in dein Koppelnetz zwischen Firewall und Internet Router. Gut, das geht nur wenn du eine Router_Kaskade betreibst.
Im Falle einer Router Kaskade ist Option 3 das Beste.
Du richtest den DNS Proxy in der Firewall entsprechend richtig ein mit der Weiterleitung auf die PiHole IP im WAN Koppelnetz:
https://administrator.de/forum/pfsense-web-de-aktiver-scheunentor-regel- ...
Das ist die eleganteste Lösung. Ein 2ter DNS Server wäre natürlich Unsinn.
Bitte warten ..
Mitglied: DrPfiend
07.02.2021, aktualisiert um 16:19 Uhr
Achso!!, ich ging davon aus, dass PVID ein Cisco eigener "Service" ist und ich bei anderen Geräten das VLAN1 direkt mit angeben muss. Check

Mit IP Bereich des Netzes FW Switch meine ich in meinem Fall das Netz x.x.1.0/24. Dort waren bisher das USG, die Wifi-AP´s, der Cloudkey, das pihole und der Switch (x.x.1.254) drin.
den DNS Server habe ich jetzt in ein separates VLAN gelegt. Und in den VLAN Netzen und für die festen static host s als DNS server hinterlegt. Und jetzt kommt das kuriose: Mit Unifi USG habe ich Internetzugang, mit Opnsense nicht. Ich denke also es ist ein reines DNS Problem kombiniert mit dem von mir bekannten PEBKAC :-) face-smile
Die Firewall 172.16.1.1 und das pihole 172.16.2.2 kenen sich ja nicht... Ist hier eine statische route vom Pihole zur FW (d.h. neues Gateway die Lösung?) Aber warum funktioniert es mit dem USG und der Opnsense nicht?
Bitte warten ..
Mitglied: aqui
07.02.2021, aktualisiert um 17:25 Uhr
dass PVID ein Cisco eigener "Service" ist
Weit gefehlt...!!! Lesen und verstehen:
https://www.administrator.de/forum/gibt-pvid-vlans-325880.html
Mit Unifi USG habe ich Internetzugang, mit Opnsense nicht
Was meinst du genau mit "Internet" ??? Geht das IP technisch nicht, sprich also ein Ping auf eine öffentliche IP wie 8.8.8.8 schlägt auch fehl oder ist "das Internet" für dich lediglich bloß ein nicht funktionierendes DNS ??
Das wäre ja zum Troubleshooting mal wichtig zu wissen !
Ist es nur das bloße Scheitern von DNS Hostauflösungen, ist es ja nicht das IP Routing ins Internet an sich. Hier solltest du in einem Administrator Forum also schon etwas präziser werden. Übrigens nslookup ist hier auch dein bester Freund. ;-) face-wink
Scheitern nur die DNS Auflösung kann man wohl von einer falschen DNS Einrichtung oder von einem falschen Regelwerk an der Firewall ausgehen. Hier hilft dann, wie immer, das Firewall Log !
ein reines DNS Problem kombiniert mit dem von mir bekannten PEBKAC
Einsicht ist der erste Weg.... Das wird es vermutlich sein. :-D face-big-smile
Die Firewall 172.16.1.1 und das pihole 172.16.2.2 kenen sich ja nicht...
Was dann natürlich logischerweise fatal und falsch wäre !!!
Die Firewall muss als DNS Server statisch die PiHole IP 172.16.2.2 konfiguriert haben und im General Setup darf NICHT "PPPoE and DHCP can override DNS Settings" angehakt sein !!
Zudem muss es eine FW Regel geben die den Zugang vom .1.0er Netz (und auch anderen Netzen) in das .2.0er Netz regelt ! Ganz besonders was DNS Anfragen betrifft.
Ist hier eine statische route vom Pihole zur FW
Wäre ja Quatsch. Es reicht das Default Gateway des PiHole auf die FW IP 172.16.2.1 einzutragen wie es ja generell für alle Endgeräte üblich ist.
Möglicherweise hast du eine Firewall Regel am neunen PiHole VLAN vergessen ?! Fehlt die, blockt die Firewall wie es bei FW's ja üblich ist dann alles !
Etwas mehr intelligentes Troubleshooting mit Ping und nslookup hilft hier. ;-) face-wink
Bitte warten ..
Mitglied: DrPfiend
08.02.2021, aktualisiert um 12:33 Uhr
Gut, dann hier eine detailiertere Fehlerbeschreibung:

Mit Unifi USG nach dem Modem bekomme ich:
n1 - Klicke auf das Bild, um es zu vergrößern
Also alles Paletti.
Tausche ich das USG gegen die OpnSense bekomme ich:
n2 - Klicke auf das Bild, um es zu vergrößern
Für mich ganz klarer Fall, dass es an den Regeln der FW liegen muss, da die Weiterleitung der DNS Requests nicht weitergeleitet werden. Im pihole ist natürlich das entsprechende Gateway hinterlegt
n5 - Klicke auf das Bild, um es zu vergrößern
und die Requests der Clients kommen an, werden vom pihole verarbeitet und dann ist irgendwo ein Fehler.
Das pihole ist auch als Standard DNS server in der FW eingetragen, den Haken hatte ich vorher allerdings vergessen.
n4 - Klicke auf das Bild, um es zu vergrößern
Als Firewallregel habe ich jetzt testweise alle TCP/UDP-anfragen für das "DNS-VLAN" sowohl rein und raus zugelassen, LAN ist noch auf default:
n3 - Klicke auf das Bild, um es zu vergrößern
Statische Route existiert nur zwischen 172.16.0.0 und 172.16.1.254(switch). Als Gateways sind 172.16.2.1 und 172.16.1.254 eingetragen.
n6 - Klicke auf das Bild, um es zu vergrößern
Gast-Vlan ist eingerichtet (noch ohne CP) funktioniert einwandfrei. IP bekomme ich von der FW und das pihole wird via nslookup auch erreicht nur ping ins öffentliche Netz gibt DNS request timed out.
Bitte warten ..
Mitglied: aqui
08.02.2021, aktualisiert um 13:42 Uhr
Mit Unifi USG nach dem Modem bekomme ich:
Sorry für die harten Worte aber was du da oben machst ist doch Schwachsinn. Weisst du auch selber wenn du dir das mal genau ansiehst !!!
Du kannst doch im nslookup Tool nicht nach einem Hostnamen suchen der "ping 8.8.8.8" lautet. Das ist doch völliger Quatsch.
Wenn, dann gibt man das doch immer in einer Zeile an !! nslookup www.heise.de z.B. und ein Ping hat mit nslookup so viel zu tun wie ein Fisch mit einem Fahrrad. Das ist ein separates Tool um die reine IP Connectivity zu testen und gibt man auch immer direkt am Kommando Prompt ein.
Wenn also dann bitte richtig und sinnvoll nutzen diese Tools ! :-( face-sad

Desweiteren ist der PiHole Screenshot ebensolcher Unsinn. Diese Settings dort gelten doch nur dann wenn der PiHole selber als DHCP Server arbeitet. Dann gibt er diese IP Range und das dort konfigurierte Gateway raus. Da der Haken oben nicht gesetzt ist und du ja auch den PiHole logischerweise NICHT als DHCP Server benutzt ist das inaktiv. Sorry, aber wenn's...schon an solchen Banalitäten scheitert drehen wir uns im Kreis hier... :-( face-sad
Die IP Adresse des PiHole selber konfigurierst du nicht im GUI sondern per SSH (PuTTY, TeraTerm) in der Datei /etc/dhcpcd.conf Dazu benutzt du den nano Editor mit nano /etc/dhcpcd.conf
....
#Example static IP configuration:
interface eth0
static ip_address=172.16.2.53/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
static routers=172.16.2.1
static domain_name_servers=<IP_Provider_DNS>

#.

Wenn du das änderst rebootest du den PiHole danach mit shutdown -r now.
Dann solltest du aus dem Firewall "Diagnostics" Menü mit dem dortigen Ping Tool den PiHole per Ping erreichen können was dann verifiziert das er IP technisch erreichbar ist. Idealerweise testet man das auch einmal mit einer anderen Absender IP eines der anderen Firewall LAN Interfaces um die geroutete erreichbarkeit zu verifizieren.
Das wiederholt man dann auch nochmal mit einem Ping und einen Traceroute von einem Client.
Ist der Ping positiv testet man das dann mal vom Client mit nslookup www.heise.de
Ist das auch positiv rennt der PiHole fehlerfrei.
Wichtig ist das die Firewall den PiHole als DNS Server konfiguriert hat:
dns - Klicke auf das Bild, um es zu vergrößern
Dazu muss die Firewall selber noch korrekt als Resolver eingerichtet sein:
https://administrator.de/forum/pfsense-web-de-aktiver-scheunentor-regel- ...
Sie selber ist dann Proxy DNS zu den Clients und leitet alles an den PiHole weiter der es dann final zu einem deiner auf dem PiHole ausgewählten Upload DNS Dienstleister oder zum Provider DNS schickt.
Das DNS System ist ein simples Baum System.
Du kannst es auch anders machen und im Firewall DHCP Server den Clients direkt die PiHole IP geben. Dann fragen sie statt der Firewall gleich direkt den PiHole, das bedingt dann aber das du zumindesten in den Firewall Regeln immer TCP und UDP 53 für die PiHole IP freigeben musst damit diese Clients den PiHole DNS erreichen können.
Das ping 8.8.8.8 checkt immer nur die eigentliche IP Connectivity um ganz sicher zu sein ob Problematiken reine DNS Problematiken sind oder IP Routing Dinge... So einfach ist das ! ;-) face-wink
Bitte warten ..
Mitglied: DrPfiend
08.02.2021 um 14:34 Uhr
m5 - Klicke auf das Bild, um es zu vergrößern
Sorry...

Ich hatte die IP des Pihole nur im Adapter des Linuxcontainers geändert, im GUI geht das glaube ich gar nicht. Das führte dazu, dass in der config zwei Einträge für eth0 vorhanden waren. Die passt jetzt also. Ein Ping von der Firewall aus liefert für alle Netze Erreichbarkeit des DNS.
bild_2021-02-08_142805 - Klicke auf das Bild, um es zu vergrößern
Wenn ich das mit dem DNS-tool teste steht da noch was von 127.0.0.1? Wo kommt der denn her, den habe ich doch gar nicht eingerichtet?
m1 - Klicke auf das Bild, um es zu vergrößern
Traceroute vom Cisco schlägt schon vom Switch Gateway 172.16.1.254 (sowohl zum Gateway der FW im VLAN2 als auch zum pihole selber) fehl (request timeout). Zum Spaß mal dem Cisco eine IP im VLAN 2 gegeben, dann erreiche ich das pihole und das FW Gateway ( x.x.2.1).
Bitte warten ..
Mitglied: aqui
08.02.2021, aktualisiert um 14:53 Uhr
Sorry...
He he der war gut ! 🤣
Wenn ich das mit dem DNS-tool teste steht da noch was von 127.0.0.1?
Jupp, was ist denn die 127.0.0.1 für eine IP Adresse ??? Erinnere dich ! .....Richtig... die lokale Loopback Adresse.
Das ist die Firewall selber (Proxy DNS). Sie fragt sich also selber und du hast ja im General Setup dort dann hoffentlich die PiHole IP als DNS angegeben. (Sieh Screenshots oben zum DNS Setup !) Dann leitet die Firewall alles an den PiHole weiter.
Haken entfernen das der DHCP oder PPPOE nicht die DNS IP überschreiben darf !
Traceroute vom Cisco schlägt schon vom Switch Gateway 172.16.1.254 (sowohl zum Gateway der FW im VLAN2 als auch zum pihole selber) fehl
Zu 99% eine fehlende oder auch falsche Firewall Regel in der Firewall ! Checke das Firewall Log ob dort TCP/UDP 53 Pakete gefiltert werden !
Oder....fehlende Default Route /Default Gateway des Switches auf die Firewall IP !
Oder...falsches Tagging Setup des Switch Uplink Ports
3 Fallen und in eine von denen bist du ganz sicher getappt.
Zum Spaß mal dem Cisco eine IP im VLAN 2 gegeben, dann erreiche ich das pihole und das FW Gateway
Oh man...und auch noch das Firewall Uplink Interface auf den Switch falsch konfiguriert so das falsche VLAN IDs falschen Ports zugewiesen werden !

Bedenke das das physische Interface immer UNtagged gesendet wird von der Firewall. Die IP die du also auf dem LAN Interface direkt hast wird immer UNtagged gesendet und landet beim Cisco dann bei einer Standard Trunk Konfig in VLAN 1 ! VLAN 1 ist bei einem Cisco Trunk Port mit Default Settings immer das Native VLAN (PVID 1). Es sei denn du setzt es anders im Switch Setup.
Nur die VLANs die in der Firewall unter VLANs gesetzt sind werden mit einer entrechenden VLAN ID die dort eingegeben wurde Tagged gesendet. Wegen der Default 1 VLAN Problematik und möglichen Doppelbelegung am Switch sollte man die ID 1 in der Firewall tunlichst NICHT verwenden sofern man das Native VLAN am Switchport nicht umgeändert hast.
Das nur das du das auch immer auf dem Radar hast !
Langsam kostet das aber "Erschwerniszulage" mit dir hier ! Kontrolliere doch bitte vorab immer einmal die simplen Baiscs eines solchen Setups. Das erleichtert uns allen das Troubleshooting.
Bitte warten ..
Mitglied: DrPfiend
08.02.2021 um 20:30 Uhr
Zitat von @aqui:
Sie fragt sich also selber und du hast ja im General Setup dort dann hoffentlich die PiHole IP als DNS angegeben. (Sieh Screenshots oben zum DNS Setup !) Dann leitet die Firewall alles an den PiHole weiter.
Haken entfernen das der DHCP oder PPPOE nicht die DNS IP überschreiben darf !
Das ist der Fall, siehe zwei Postings darüber.
Zu 99% eine fehlende oder auch falsche Firewall Regel in der Firewall ! Checke das Firewall Log ob dort TCP/UDP 53 Pakete gefiltert werden !
In der Diagnose sind die Anfragen der einzelnen Schnittstellen mit Port53 grün. Ich habe keine geblockte gesehen...
Oder....fehlende Default Route /Default Gateway des Switches auf die Firewall IP !
Ich muss hier aufgrund fehlender Kenntnis das Setup mit USG heranziehen. Dort funktioniert ja auch alles mit nur zwei Routen, einer im Switch 0.0.0.0 zu 172.16.1.1 und einer in der Firewall 172.16.0.0/16 zu 172.16.1.254 (so ist es auch in der Opnsense konfiguriert) und der Regel "ins DNS darf alles rein und alles raus" (zusätzlich noch in der Opnsense LAN die Defaultregel Scheunentor).
Oder...falsches Tagging Setup des Switch Uplink Ports
Cisco Port26 Trunk operational VLAN 1U, 2T, 10T, 20T, 30T, 40T, 50T, 60T (in allen Netzen bis auf VLAN2 und VLAN40 hat der switch auch eine IP um intern zu routen)
Oh man...und auch noch das Firewall Uplink Interface auf den Switch falsch konfiguriert so das falsche VLAN IDs falschen Ports zugewiesen werden !
In der Firewall habe ich keine VLAN1-Schnittstelle eingerichtet(dort sind nur (physisch)LAN (Statische IP & Autogateway) und WAN (PPPoe) sowie VLAN 2,10-60 mit jeweils einer statischen IP x.x.x.1 und Autogateway) und zusätzlich dazu dem Gateway 172.16.1.254 (für die route) eingerichtet. Das zusätzliche Gateway 172.16.2.1 habe ich gelöscht. Die IP hat die FW ja im VLAN2. DNS ist am Port 53 unbound, Dnsmasq demzufolge disabled.
Bitte warten ..
Heiß diskutierte Inhalte
Switche und Hubs
Probleme im Netzwerk Switche teilweise nicht erreichbar
hukimanVor 19 StundenFrageSwitche und Hubs29 Kommentare

Guten Morgen, seit Monaten haben wir hier immer wieder Probleme mit dem Netzwerk, das Problem konnte ich leider aber noch immer nicht finden. Es ...

Erkennung und -Abwehr
Einer Malware auf der Spur. Benötige Sherlock Holmes!
streamVor 1 TagFrageErkennung und -Abwehr7 Kommentare

Guten Abend Wenn ich meine Windows-10-Kiste starte, so gibt mir mein Router eine Meldung aus, dass eine bestimmte IP-Adresse wegen Bösartigkeit geblockt wurde. Auf ...

Batch & Shell
Tabellarische Ausgabe der Netzwerkschnittstellen
gelöst dysti99Vor 17 StundenFrageBatch & Shell18 Kommentare

Mit - ip a - werden ja die Netzwerkschnittstellen angezeigt. Ich möchte mit ein Batchscript folgende Ausgabe erreichen: 1 eth0 192.168.1.1 AD:13:67:56:14:D1 2 eth1 ...

Ubuntu
Mailserver Test Provider IP
gelöst it-blzVor 1 TagFrageUbuntu9 Kommentare

Hallo, ist es möglich einen "Mailserver" (Imap + smtp) in einer Virtual Box mit einer Provider IP (dynamisch - ist allerdings konstant) zu testen? ...

Microsoft
MS Teams und Office im gemeinnützigen Verein
DanielBodenseeVor 1 TagFrageMicrosoft6 Kommentare

Hallo zusammen, ich würde gerne in unserem anerkannten gemeinnützigen Verein eine gemeinsame Platform aufbauen, über die wir Diskutieren und uns austauschen können, insbesondere bei ...

Hardware
DisplayPort zu USB-C Adapter Converter
gelöst felixhuth-itVor 1 TagFrageHardware11 Kommentare

Hallo liebe Gemeinde Ich habe da ein kleines Problemchen. Der Kunde wollte einen 14 Zoll Monitor mit Touch in Verbindung mit einem Mini PC ...

Linux Netzwerk
SAMBA FS Portfreigabe
gelöst Jannik2018Vor 1 TagFrageLinux Netzwerk17 Kommentare

Hallo zusammen, ich habe eine Portfreigabe für meinen SAMBA Server mit Netzwerkfreigaben auf port 445 TCP eingerichtet allerdings wenn ich per DNS oder externer ...

Ausbildung
FISI Projektantrag GPO
gelöst JenzooVor 1 TagFrageAusbildung10 Kommentare

Moin, leider wurde mein Projektantrag abgelehnt mit folgender Begründung abgelehnt "Antrag kann so nicht genehmigt werden. Uns fehlt hier die Tiefe und der entsprechende ...