Ubiquiti UniFi USG - Kein Internet im LAN

[Iwwazwersch]

Hallo zusammen,

ich habe seit gestern ein USG, bekomme Sie aber anscheinend nicht korrekt eingerichtet.

Spoiler: Alte Konfiguration mit Speedport Hybrid ohne Lösung :(

Das USG hängt an einem Speedport Hybrid.
Das USG hat eine Internetverbindung.
Das USG ist an einem US-8-150W angeschlossen und dann geht es noch weiter mit aber das sollte ja keine Rolle mehr spielen.

Speedport Hybrid Konfiguration:
IP: 192.168.6.1
DHCP Server an
Bereich 192.168.6.2 - 192.168.6.20

USG Konfiguration:
WAN: DHCP
LAN: 192.168.178.1
DHCP Server an
Bereich: 192.168.178.100 - 192.168.178.200

Alle Geräte hinter der USG bekommen keine Internetverbindung.
u.a. mit ping zu 8.8.8.8 geprüft

Kann mir jemand sagen, welchen Fehler ich hier mache? Der DHCP des Speedports sollte ja egal sein, da er ja nur den DHCP Server im Netz 192.168.6.1 stellt oder sollte das doch der Fehler sein?

Zu dieser der Konfiguration im Spoiler gab es leider keine Lösung für mich.

Da mein Internetanschluss nun umgestellt worden ist auf inexio nun ein weiterer Versuch.

EDIT: Schlussendlich war die USG kaputt

 

[benneq]

Was kriegen deine Clients denn per DHCP für eine Konfiguration? Vielleicht ist da das Gateway falsch gesetzt.

Kannst du von deinen Clients überhaupt den SpeedPort erreichen?

 

[madmax2010]

hast du zwischen
LAN: 192.168.6.0/24 und 192.168.178.0/24 ne route?

 

[KurzGedacht]

teste mal ob du 8.8.8.8 anpingen kannst. Vielleicht geht nur DNS nicht.

 

[Iwwazwersch]

Was kriegen deine Clients denn per DHCP für eine Konfiguration? Vielleicht ist da das Gateway falsch gesetzt.

Kannst du von deinen Clients überhaupt den SpeedPort erreichen?

192.168.178.1 Für DNS und Gateway

hast du zwischen
LAN: 192.168.6.0/24 und 192.168.178.0/24 ne route?

Nein, habe ich nicht.

Davon wird in keiner Anleitung ein Wort gesagt, nur das verschiedene Adressbereiche verwendet werden sollen zwischen WAN (Speedport) und LAN.

teste mal ob du 8.8.8.8 anpingen kannst. Vielleicht geht nur DNS nicht.

Alle Geräte hinter der USG bekommen keine Internetverbindung.
u.a. mit ping zu 8.8.8.8 geprüft

 

[Fenugi]

Was kommt denn heraus, wenn du vom Client aus ein tracert auf diverse Adressen (192.168.6.1, 8.8.8.8, heise.de) machst; wo bleibt es hängen?
Routen musst du nicht händisch im USG, bzw. im Unifi-Controller eintragen, das läuft automatisch.

 

[Iwwazwersch]

Was kommt denn heraus, wenn du vom Client aus ein tracert auf diverse Adressen (192.168.6.1, 8.8.8.8, heise.de) machst; wo bleibt es hängen?
Routen musst du nicht händisch im USG, bzw. im Unifi-Controller eintragen, das läuft automatisch.

Das müsste ich mal noch testen, denke aber an der 192.168.6.2, die kann ich pingen. Den Speedport auf der 192.168.6.1. nicht mehr

 

[madmax2010]

ich habe den edgerouter x zwischen einem router ohne bridge mode (aber mit dhcop) und den restlichen devices

ubnt@ubnt:~$ ip route
default via 192.168.1.1 dev eth0 proto zebra
10.0.0.0/24 dev switch0 proto kernel scope link src 10.0.0.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.38

Ist die minimale routing config, wobei 192.168.1.38 die IP ist, die der router vom modem bekommen hat
10.0.0.0/24 Ist bei mir einfach nur das Uplink-Netz was in der Richtung wirst du halt auch brauchen

Ohne route keine verbindung zwischen den Nentzen
Zeig mal deine routing seite

 

[Iwwazwersch]

ich habe den edgerouter x zwischen einem router ohne bridge mode (aber mit dhcop) und den restlichen devices

ubnt@ubnt:~$ ip route
default via 192.168.1.1 dev eth0 proto zebra
10.0.0.0/24 dev switch0 proto kernel scope link src 10.0.0.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.38

Ist die minimale routing config, wobei 192.168.1.38 die IP ist, die der router vom modem bekommen hat
10.0.0.0/24 Ist bei mir einfach nur das Uplink-Netz was in der Richtung wirst du halt auch brauchen

Ohne route keine verbindung zwischen den Nentzen
Zeig mal deine routing seite

Die ist leer, da ich ja keine Statischen Routen eingefügt habe.

 

[aranax]

Es werden auch keine zusätzlichen Routen gebraucht. Default Route genügt für Internetzugtriff.

Die WAN Verbindung hat keinen sinnvollen DNS-Server (FritzBox!) konfiguriert. Hat aber keinen Einfluss auf einen Ping zu 8.8.8.8. Anonsten sieht die Konfiguration richtig aus.

 

[Fenugi]

Diverse Schüsse ins Blaue:

• Ist zwar etwas weit hergeholt, aber existiert vielleicht ein Gerät im Speedportnetz, das die 192.168.6.2 statisch konfiguriert hat und einen Konflikt mit dem USG verursacht?
• Trage mal im Unifi-Controller für das WAN der USG statische Werte ein (IP: 192.168.6.2, Gateway/DNS: 192.168.6.1). Wie bereits von aranax gesagt gehört der DNS ohnehin rein, und ein USG-Neustart hilft auch mal ganz gern.
• Auf einem (Windows-)Client in einer CMD mit Adminrechten testweise eintragen: route add 192.168.6.0 mask 255.255.255.0 192.168.178.1 und testen, ob du damit den Speedport erreichst, bzw. ins Internet kommst. Der Eintrag ist übrigens nur temporär und nach einem Rechnerneustart wieder weg.

 

[aranax]

• Auf einem (Windows-)Client in einer CMD mit Adminrechten testweise eintragen: route add 192.168.6.0 mask 255.255.255.0 192.168.178.1 und testen, ob du damit den Speedport erreichst, bzw. ins Internet kommst. Der Eintrag ist übrigens nur temporär und nach einem Rechnerneustart wieder weg.

Diese Route ändert halt nichts. Hilfreich könnte ein eher ein "tracert 8.8.8.8" sein.

 

[Fenugi]

Diese Route ändert halt nichts. Hilfreich könnte ein eher ein "tracert 8.8.8.8" sein.

Ein tracert wäre in jedem Fall sinnvoll. Mache mal bitte einen @Iwwazwersch und kopiere die Ausgabe hier rein. Wobei ich davon ausgehe, dass das ins Leere läuft, wenn schon der Speedport aus dem USG-Netz nicht erreicht werden kann (und erster ja wohl keine ICMP-Pakete verwerfen wird).
Mein Bauchgefühl sagt mir trotzdem, dass irgendwas anderes faul ist. Ich hab jahrelang beruflich (IT-Systemhaus) mit Ubiquiti zu tun gehabt, und zumindest die grundlegenden Einstellungen haben wie erwartet funktioniert.

 

[Iwwazwersch]

Ein tracert wäre in jedem Fall sinnvoll. Mache mal bitte einen @Iwwazwersch und kopiere die Ausgabe hier rein. Wobei ich davon ausgehe, dass das ins Leere läuft, wenn schon der Speedport aus dem USG-Netz nicht erreicht werden kann (und erster ja wohl keine ICMP-Pakete verwerfen wird).
Mein Bauchgefühl sagt mir trotzdem, dass irgendwas anderes faul ist. Ich hab jahrelang beruflich (IT-Systemhaus) mit Ubiquiti zu tun gehabt, und zumindest die grundlegenden Einstellungen haben wie erwartet funktioniert.

Die tracerts laufen natürlich länger aber gleiches Ergebnis.

DNS ist nachgetragen bei WAN -> 192.168.6.1

Routenverfolgung zu dns.google [8.8.8.8]
über maximal 30 Hops:

1 * * * Zeitüberschreitung der Anforderung.
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.

Ablaufverfolgung beendet.

Routenverfolgung zu setup.ubnt.com [192.168.178.1]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms setup.ubnt.com [192.168.178.1]

Ablaufverfolgung beendet.

Routenverfolgung zu ubnt [192.168.6.2]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms ubnt [192.168.6.2]

Ablaufverfolgung beendet.

Routenverfolgung zu speedport.ip [192.168.6.1]
über maximal 30 Hops:

1 * * * Zeitüberschreitung der Anforderung.
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.

Ablaufverfolgung beendet.

Es werden auch keine zusätzlichen Routen gebraucht. Default Route genügt für Internetzugtriff.

Die WAN Verbindung hat keinen sinnvollen DNS-Server (FritzBox!) konfiguriert. Hat aber keinen Einfluss auf einen Ping zu 8.8.8.8. Anonsten sieht die Konfiguration richtig aus.

Also bei Routing&Firewall ist kein Eintrag, sollte dort eine Default Route hinterlegt sein?

Diverse Schüsse ins Blaue:

• Ist zwar etwas weit hergeholt, aber existiert vielleicht ein Gerät im Speedportnetz, das die 192.168.6.2 statisch konfiguriert hat und einen Konflikt mit dem USG verursacht?
• Trage mal im Unifi-Controller für das WAN der USG statische Werte ein (IP: 192.168.6.2, Gateway/DNS: 192.168.6.1). Wie bereits von aranax gesagt gehört der DNS ohnehin rein, und ein USG-Neustart hilft auch mal ganz gern.
• Auf einem (Windows-)Client in einer CMD mit Adminrechten testweise eintragen: route add 192.168.6.0 mask 255.255.255.0 192.168.178.1 und testen, ob du damit den Speedport erreichst, bzw. ins Internet kommst. Der Eintrag ist übrigens nur temporär und nach einem Rechnerneustart wieder weg.

Zu 1.: Nein, USG hängt allein an LAN 1, WLAN ist aus

Ich setzte mal die USG komplett zurück und versuche es mal ganz von vorne.

Danke schon mal für die Antworten.

Hier mal noch die Geräte Übersicht. Aber hier sollte sich auch nichts komisches verstecken.

 

[madmax2010]

Das eine default route im schema wie von mir geposted gesetzt sein sollte behaupte ich weiterhin.

Ich hab im Regal noch ein paar usg liegen - Donnerstag hätte ich Zeit das mal durchzuspielen

 

[Iwwazwersch]

Diverse Schüsse ins Blaue:

• Auf einem (Windows-)Client in einer CMD mit Adminrechten testweise eintragen: route add 192.168.6.0 mask 255.255.255.0 192.168.178.1 und testen, ob du damit den Speedport erreichst, bzw. ins Internet kommst. Der Eintrag ist übrigens nur temporär und nach einem Rechnerneustart wieder weg.

Hab ich gemacht, keine Änderung.

Das eine default route im schema wie von mir geposted gesetzt sein sollte behaupte ich weiterhin.

Ich hab im Regal noch ein paar usg liegen - Donnerstag hätte ich Zeit das mal durchzuspielen

Ich vermute das ist korrekt eingetragen.

Keine Änderung

 

[madmax2010]

Geh mal über die Schnittstelle

 

[Raijin]

Eine Standardroute sollte eigentlich bereits eingetragen sein. In den WAN-Settings sieht man, dass via DHCP das Gateway 192.168.6.1 zugewiesen wurde - das ist die Standardroute. Ob die in der GUI auftaucht oder nicht, muss nix heißen. Es gibt vieles was in der Unifi und der EdgeRouter-GUI nicht auftaucht, weil es hinter den Kulissen läuft. So werden beispielsweise auch bei Portweiterleitungen weder die DNAT-Regeln noch die Firewall-Ausnahmen angezeigt (zumindest war das in den mir bekannten Versionen so). Das heißt aber nicht, dass sie nicht existieren, weil ein Blick in die iptables via ssh offenbart dann, dass es dafür ne separate Chain gibt, die von der GUI nicht dargestellt wird.

Man kann das aber auch ganz einfach testen, indem man vom USG selbst aus die Internetverbindung testet, via ssh.

Da ich kein USG habe, kann ich das leider nicht selbst prüfen, aber laaaaange Zeit konnte man am USG das NAT am WAN nicht abschalten. Dies sollte aber schon vor geraumer Zeit in den Controller implementiert werden. Ob es nun "schon" da ist, nach gefühlt 10 Jahren Requests aus der Community, weiß ich nicht, angekündigt war es aber. Also bitte nochmal die WAN-Einstellungen des USG prüfen ob dort NAT aktiviert ist (wenn's denn nen Haken gibt).


Mein nächster Schritt wäre nun, einen PC mit Linux+tcpdump oder Windows+WireShark an den Speedport zu hängen (zB mit der 192.168.6.3) und am USG-WAN das Gateway auf dessen IP umzubiegen. Wenn man nun von einem PC aus dem USG-Netz einen Ping auf den Speedport-PC absetzt, geht dieser zum USG und dieses schickt ihn hoffentlich weiter zum PC am Speedport, der das dann wiederum mittels WireShark aufzeichnen kann. So kann man zumindest prüfen ob das USG ordnungsgemäß weiterleitet und vor allem ob es auch tatsächlich NATtet.

*edit
Zuvor solltest du aber noch einen kurzen Blick in die Firewall-Einstellungen des USG werfen ob dort nicht evtl. sogar eine alles blockierende Regel drinsteht


*edit2
Die Route aus #16 kannst du übrigens getrost wieder löschen. Du sagst dem USG effektiv, dass es sein eigenes Subnetz über ein Gerät im eigenen Subnetz erreicht. Eine Route und das dazugehörige Gateway weist aber den Weg in ein anderes Subnetz. Genau genommen würde sich die Route, die du da eingetragen hast, sogar im Kreis drehen, weil das USG zum erreichen einer IP im 192.168.6.0/24 Subnetz ein Gateway im 192.168.6.0/24 Subnetz verwenden muss, das es über die Route ins 192.168.6.0/24 Subnetz erreicht, welches ein Gateway im 192.168.6.0/24 Subnetz erreicht, das über die Route ins ........ Normalerweise müsste so eine Route sogar von der GUI abgefangen werden, weil sie schlicht und ergreifend keinen Sinn ergibt --> löschen.
Interface-Routen für die Subnetze der eigenen LAN-Schnittstellen (inkl. WAN) erstellt das USG automatisch, so wie Windows es zB auch tut. Kann man bei Windows schön sehen, wenn man "route print" eingibt und sich dann den Bereich mit dem lokalen Subnetz anschaut.

 

[Iwwazwersch]

Geh mal über die Schnittstelle

Keine Änderung, hab mit Schnittstelle LAN und WAN getestet.
Da ich nicht sicher bin, welche ich nehmen müsste

Man kann das aber auch ganz einfach testen, indem man vom USG selbst aus die Internetverbindung testet, via ssh.

USG selbst hat ja Internet.

*edit
Zuvor solltest du aber noch einen kurzen Blick in die Firewall-Einstellungen des USG werfen ob dort nicht evtl. sogar eine alles blockierende Regel drinsteht

Dort stehen nur 2 Standard Regeln drin würde ich sagen, diese sind auch nicht löschbar.

Mir ist eine weitere meiner Meinung nach seltsamkeit aufgefallen.

Wenn ich mit dem Speeport per LAN verbunden bin kann ich ich die USG auf 192.168.6.2 nicht pingen. PC hat die 192.168.6.10.

Habe die Adresse der USG Beim Neueinrichten statisch gesetzt auf 192.168.6.2.

Internet liegt weiterhin an der USG an.

 

[dzorg]

hast du zwischen
LAN: 192.168.6.0/24 und 192.168.178.0/24 ne route?

Das ist eigentlich schon der entscheidende Hinweis. Es geht hierbei aber nicht um die Route aus dem LAN hinter der USG in Richtung Internet, sondern um die Rückroute. Du musst deinem Speedport mitteilen, wo sich das 192.168.178.0/24 Netz befindet. Andernfalls schickt er alle Pakete mit Ziel 192.168.178.0/24 wieder zurück in Richtung Internet, da er selbst eine Default Route hat und nichts spezifischeres festgelegt wurde. Hierfür benötigt er eine statische Route, die auf den WAN-Port der USG zeigt.

Somit --> Im Speedport konfigurieren: Route auf Zielnetz 192.168.178.0/24 über Gateway 192.168.6.2

Aus diesem Grund sollte der WAN-Port der USG am besten eine feste IP haben (ob nun händisch konfiguriert oder fest durch DHCP vergeben). Sonst funktioniert die Rückroute plötzlich nicht mehr.

Die USG hat selbst bereits Internet, da sie ein Interface im LAN-Segment des Speedports hat.

(Ja, ich habe mich extra für diesen Beitrag angemeldet )