Beiträge von Ben2003

Hallo,

hinter 192.168.188.19 und 192.168.188.18 stehen PiHole-Systeme zur Filterung von unerwünschten Domains wie z.B. ssl.google-analytics.com

hier ist das Haupt-LAN

Hallo,

auch mit dem DHCP Nameserver 1.1.1.1 und 1.0.0.1 kann kein Zugang zu m Internet hergestellt werden.

ZUvor war da die IP vom DSL Router eingetragen.

Hallo,

hier ist das Screenshot.¨

Hallo,

wie können die Daten analysiert werden, die über einen bestimmten Port im Switch gehen?

Hintergrund: Bislang habe ich alle Clients durch ein DNS-Filter vor unerwünschten Domains geschützt. Ein TV-Gerät kommt mit der Filterung nicht zurecht und verhält sich fehlerhaft, wenn der Filter auf Domain-ebene aktiv ist. Sobald der TV-Fernseher direkt am Router (eines Fremdherstellers) angeschlossen wird Nun will ich sehen, welche Domains von dem TV-Gerät angesprochen werden.

Meines Wissens nach muss dazu der Datenverkehr zusätzlich auf einen anderen Port gespiegelt werden, damit vom zweiten Port die übersendeten Daten z.B. mit Wireshark analysiert werden können.

Kann mir da jemand weiterhelfen?

Hallo,

im Unifi-Controller wurde ein neues Netzwerk erstellt. Nach der Zuweisung der Clients habe ich festgestellt, dass die Clients kein Zugang auf das Internet möglich ist.

Bei der letzten Einrichtung eines neuen Netzwerks vor etwa 14 Monaten (??) war es noch so, dass irgendwo die WAN-Schnittstelle für das neue Netzwerk explizit freigeschaltet werden musste, so dass die Clients über die WAN Schnittstelle auf das Internet zugreifen können. Diese Einstellung finde ich weder in der "Classic-Oberfläche" noch in der neuen Oberfläche der Einstellungen.

Bislang wurde für das neue Netzwerk eine VLAN-ID und ein DHCP-Service festgelegt.

Kann mir jemand weiterhelfen?

Hallo iTweek,

es handelt sich in der Tat um eine Linux VM. Die Webservices sind ebenfalls VMs.

Öffentliche IP... Weiterleitung an interne IP ... klingt logisch.

Muss eine öffentliche IP grundsätzlich im Proxy speziell "bearbeitet" werden?

Wie kann man das Problem weiter eingrenzen?

Hallo,

im LAN laufen mehrere Webservices die jeweils an eine Subdomain gebunden sind. Alle Zugriffe werden über einen Proxy geleitet.

In der USG sind zwei Portweiterleitungen für die Ports 80 und 443 an den Proxy freigegeben:

Schema Webservices Proxy.pdf

Wenn der "Client" vom LAN aus einen Webservice aufruft, geht der Aufruf über den Proxy zum entsprechenden Webservice. Der Proxy kann anhand der Subdomain/Domain unterscheiden, an welchen Webservice die Anfrage weitergeleitet werden muss.

Die zur Verfügung stehende Bandbreite sollte im LAN immer unabhängig von der Bandbreite des Internet-Zugangs sein.

Wenn der Client z.B. ServiceA.Domain.com vom LAN aus aufruft steht nur die Upload-Bandbreite des Internet-Zugangs zur Verfügung.

Beim Aufruf des Webservices direkt z.B. ServiceA.localdomain steht die ganze Bandbreite des LANs zur Verfügung.

Der Proxy leitet lediglich die Anfragen nach den Regeln weiter. Hier werden keine Bandbreitenbeschränkungen vorgenommen. Es werden auch keine Anfragen an den USG gemacht, um zu erfahren, wie groß die Bandbreite des Internet-Anschlusses ist.

Aufgefallen ist diese Besonderheit beim Bereitstellen einer großen Datei, die auf dem System "Client" vorhanden ist und bei einem der Webservices hochgeladen werden sollte.

Beim Aufruf der URL ServiceA.Domain.com war eine Transferrate von etwa 400kb/s möglich.

Beim Direkten Aufruf über die URL: ServiceA.localdomain werden die Daten etwa 16-25MB/s transferiert.

Beim Direkten Aufruf über ServiceA.localdomain meckert der Browser, weil die verwendete Domain vom verwendeten https-Zertifikat abweicht. Daran dürfte es doch nicht liegen?

iperf-Test-Messungen wurden zwischen Client und allen Webservices und Proxy sowie zwischen Proxy und den Webservices durchgeführt. Überall stehen die volle Bandbreite des LANs zur Verfügung. Die Bandbreite stand sogar dann noch zu 90% zur Verfügung, wenn mehrere iPerf Tests parallel aufgeführt werden.

Es scheint so, als wenn die USG einen Einfluss nimmt, wie hoch die Transfer-Bandbreite sein darf, mit der Daten von A nach B übertragen werden.

Kann diese Einschätzung jemand mit mir teilen? Oder irre ich mich hier total?

Weiß jemand, wie man die Fehlerursache eingrenzen kann?

Hallo,

vielen Dank für die Informationen

Zitat von razor

Wer terminiert in Deinem Szenario die VPN-Verbindung?

Eine VPN Verbindung wird nicht terminiert. Bei der Verbindungsaufnahme wird kein Sitzungs-Ende festgelegt. Via regelmäßigen Ping-Befehle wird die Verbindung aufrecht erhalten.

Zitat von razor

Was passiert, wenn Du keine Firewall-Regeln - die Telefonie betreffend - aktiv hast?

Die bestehenden SIP-Regeln müssen aktiv bleiben, da vor dem USG eine "FritzBox Cable 6490" hängt. Diese FritzBox kann nur mit eigenem NAT Modus betrieben werden. Ein "Nur-Modem-Modus" kann bei dieser FritzBox nicht aktiviert werden. Wegen dem Doppeltem NAT existieren auch weitere Einschränkungen.

Abhilfe ist schon in Sichtweite: Derzeit werden in der Umgebung fleißig Leerrohre für Glasfaser verlegt. In etwa 2 Jahren werden alle Anschlüsse umgestellt worden sein. Dann wird das Problem mit dem doppeltem NAT Geschichte sein.

Wenn keine Telefonie-Regeln aktiv sind, kann kein Telefonat geführt werden.

An dieser Stelle kannn ich mir weitergehende testläufe nicht erlauben, da die Telefone von mehreren Personen täglich im Einsatz sind.

Vor der Einführung von Unifi-Komponente wurden alle Funktionen von beide FritzBoxen (6490 Cable und 7390) übernommen. VPN wurde damals von der FritzBox auch eingerichtet (Begriff: Fernzugriff) Danach kam Unifi und das doppelte NAT...

Zitat von razor

Wie hast Du die Fritz!Fon-App mit der Fritz!Box verbunden, dass die App via VPN "grün" wird? MyFritz?

In der FritzFon-App ist direkt die IP-Adresse der Telefon-Anlagen-FritzBox angegeben (in diesem Fall 192.168.188.232) Nach dem Aufbau der VPN-Verbindung via OpenVPN kann auf alle LAN-IP-Adressen zugegriffen werden. Daher schaltet der Status auf Grün um.

Zitat von razor

Wie lange kannst Du mit einem Teilnehmer telefonieren?

Das habe ich noch nicht ausprobiert. Bislang gab es keine Probleme. Das längste Telefonat war mal bei etwa 40 Minuten.

Die eigene SIP-Konfiguration bezieht sich nur auf eine Verbindung von der FritzBox 6490 Cable zur eigentlichen Telefonanlage (die ebenfalls eine FritzBox ist).

Zitat von Loxor

in der Regel wird bei VoIP der SIP Port 5060 verwendet (ist für den Rufaufbau und das klingeln zuständig). Das Problem mit dem "auflegen" passt auch in das Schema. Bei der Sprachübertragung werden die sogenanten RTP Ports verwendet diese müssen höher liegen als Port 1024, diese "High-Prorts" werden in in der Regel von bis geöffnet z.B. 30001-300040 = 40 Sprachkanäle. Ich glaube das dort das Problem zu suchen ist. Zum testen kannst du dir mal ein Softphone auf einem Notebook installieren, VOP, Phoner Lite etc. dann die Open VPN aufbauen und das Tool "LiveTcpUdpWatch" öffnen (kostenlos downloadbar) dann siehst du genau welche Ports das Softphone noch aufmacht außer Port 5060.

Das ist ein guter Gedanke. Da werde ich in den nächsten Tagen einige Testläufe durchführen.

Hallo Zusammen,

Ausgangslage:

Habe eine "Unifi USG 3P".

Im LAN ist eine FritzBox als Telefonanlage integriert. Es sind mehrere Funktelefone und LAN-Telefone als App angemeldet. Alle weiteren FritzBox-Funktionen sind deaktiviert.

Innerhalb des LAN-Netzes können Telefonate beliebig untereinander geführt werden. - Es treten keine Probleme auf.

Auf mehreren Smartphone Geräten ist eine App "AVM Fon" installiert, welche eine Verbindung zur Telefonanlage im LAN herstellt.

Wenn ein Smartphone via OpenVPN angemeldet ist, kann mit der FritzBox als Telefonanlage eine Verbindung erfolgreich hergestellt werden:

Telefonie: Status grün

FritzBox: Status grün

Bei einem Telefonat zu einem internen Telefon (Nummer: **614) vom Smartphone via VPN passiert folgendes:

1. Smartphone stellt eine Verbindung via VPN her. - Verbindung erfolgreich hergestellt.

2. Smartphone App "AVM Fon" wird geöffnet.

3. Status "FritzBox" wird als Grün angezeigt

4. Status "Telefonie" wird aus Grüm angezeigt

5. Telefonbuch von der FritzBox wird erfolgreich angelesen

6. Eintrag mit dem anzurufenden Teilnehmer wird ausgewählt. - Anruf wird eingeleitet.

7. angerufenes Telefon läutet. Als Anrufer wird das Smartphone angezeigt.

8. Eingehendes Telefonat wird angenommen.

9. Der Gesprächsteilnehmer kann nicht gehört werden - auf beiden Seiten kommt nix an.

10a. Wenn das Telefonat vom angerufenen Telefon beendet wird, bekommt das Smartphone das nicht mit. Es wird weiterhin eine aktive Verbindung angezeigt, obwohl der Teilnehmer schon lange aufgelegt hat.

10b. Wenn das Telefonat vom Smartphone beendet wird, bekommt der Teilnehmer das sofort mit. Im Display wird angezeigt, dass das Telefonat beendet wurde.

Das gleiche Szenario wurde sowohl mit aktivierter HD-Telefonie aus auch ohne durchgeführt. Das Ergebnis ist immer das gleiche.

Zur Info: Wie bereits oben geschrieben wurde, treten diese Probleme nur auf, wenn das Smartphone via VPN im LAN angemeldet wurde.

Hat jemand Erfahrungen wie die Fehlerursache eingegrenzt werden kann?

Ich vermute, dass irgend welche Pakete in der Firewall hängen bleiben. Das zeigt sich schon deshalb, weil ein Telefonat-Gesprächsende durch Auflegen vom Smartphone nicht mitbekommen wird:

Telefon-Teilnehmer im LAN legt auf -> Smartphone-Teilnehmer bekommt das nicht mit.

Firewall:

In der Firewall sind folgende Regeln aktiv:

Internet:
SIP-Telefonie: Internet In - Aktion: accept all Protocols
SIP-Telefonie: Internet Out - Aktion: accept all Protocols

zwischenzeitlich wurde eine Lösung gefunden:

In einem anderen Access Point war eine Option "Meshing mit einem anderen Access Point erlauben" nicht aktiv.

Nach der Aktivierung hat auch die Einbindung des drahtlosen Access-Points geklappt.

Hallo,

im Netz befinden sich mehrere Access Points. Eines ist erfolgreich drahtlos angebunden.

Nun soll ein bestehender Access Point auf "Drahtlos Verbindung" umgestellt werden.

Folgendes wurde bereits durchgeführt:

1. PoE Injektor vor dem Access-Point geschaltet, damit dieser Energie bekommt
2. LAN-Verbindung vom Switch getrennt
3. Access Point stromlos gemacht (für etwa 10 Sekunden)
4. Access Point wieder angeschlossen am POE Injektor (ohne LAN Verbindung)

Nach dem Neustart des Access Points verbindet dieser sich nicht via Funk. Im Controller wird dieser als getrennt gelistet.

Kann mir jemand erläutern, was man unternehmen muss damit eine Access Point sich drahtlos verbinden kann?

In den Geräte Einstellungen habe ich keine entsprechende Option "Drahtlos Verbindung" o.ä. gefunden,

Im Controller ist bereits der "Verbindungs-Monitor und Drahtlos-Uplink" aktiviert. Andernfalls könnte ja ein weiterer Access Point sich nicht drahtlos verbinden.

Hallo,

das Problem hat sich zwischenzeitlich erübrigt.

Ursache war, dass ein Endgerät sich als DHCP ausgewiesen hat. Im Unifi-Controller war außerdem nicht die Option "DHCP Guard" aktiv, so dass es hier keinen Schutz gegen unerlaubter übernehme gegeben hat.

Nachdem der falsche DHCP Service offline genommen wurde, haben innerhalb kurzer Zeit alle Geräte und Endgeräte wieder eine gültige IP Adresse zugewiesen bekommen.

Vielen Dank dennoch für die Unterstützung.

Hallo,

zwischenzeitlich haben schon einige Geräte (switches und Access Points) eine neue IP von 192.168.1.xxx zugeteilt bekommen. Dadurch können diese nicht mehr administriert werden. (Fehlermeldung: Einbindung fehlgeschlagen)

Ferner wurde versucht, den IP-Bereich vom Hauptlan zu anzupassen an 192.168.1.0/24. Dies ist gescheitert, da die Änderung nicht übernommen werden können. Jeglicher Versuch, einen neuen Bereich zu efinieren, schlägt fehl.

Wenn noch weitere Stunden vergehen, entziehen sich immer mehr Geräte der Administration,

Hat irgend jemand weitere Ideen?

Eine Reparatur der Datenbank wurde schon erfolglos durchgeführt: https://help.ui.com/hc/en-us/a…s-on-the-UniFi-Controller

Ein Request an den Hersteller wurde bereits erstellt. Warten wir mal ab, was da kommt.

Hallo,

die Adresse 192.168.1.1 gibt es nicht. Diese läßt sich auch nicht anpingen.

Im Controller sind drei Netze angelegt worden:

Hauptnetz: 192.168.188.0/24

Gästenetz: 10.1.0.0/24

VLAN Netz: Nur eine VLAN ID vorgegeben

Es wird eine USG 3P eingesetzt.

Als Controller wird derzeit Version 5.14-23-13880-1.

Nach einem Update auf eine aktuelle Version 6.x gab es WLAN-Fehler. Es konnten sich keine WLAN-Geräte mehr anmelden.

Auch im Controller konnten keine Eigenschaften von den bestehenden Netzen mehr angezeigt werden. Beim Anklicken des "Edit"-Links ist keine neue Box angezeigt worden.

Daher wurde ein neues Debian System mit MongoDB 3.6.19 (Unifi unterstützt nur MongoDB < 4.0.0) aufgesetzt, in dem die letzte Controller Version 5.14..... wieder installiert wurde. Als Backup ist ebenfalls eines zum Einsatz gekommen, das mit der Programm-Version 5.14.... eingesetzt wurde.

Mir ist bewusst, dass irgendwann, ein Update auf Version 6.x erfolgen muss. Vor einem Update sollte dennoch Fehler wie diese erst aus der Welt geschaffen werden.

Hallo,

eine FritzBox ist am "WAN 1" angeschlossen.

Die FritzBoẍ hat die Statische IP 192.168.105.1

Hinter der USG sind einige Unifi Switches und 2 Access Points.

Im LAN ist zusätzlich noch eine weitere FritzBox als Telefonanlage für DECT-Telefone. Alle weiteren Funktionen sind deaktiviert woren. (Die erste FritzBox 192.168.105.1 steht an einer ungünstigen Stelle für eine DECT-Basis-Station).

In der FritzBox 192.168.105.1 ist nur die Internet-Zugang aktiviert. Diese FritzBox kann nicht ausgetauscht werden, da es sich um eine "Cable 7490" handelt. Weitere Funktionen wie WLAN, DHCP u.s.w.sind deaktiviert. Ausnahme: Telefonie; diese Funktion ist aktiv.

Auffällig ist, dass speziell alle Windows-Systeme seit heute melden, dass kein Internet-Zugang mehr möglich sei.

Diese haben eine öffentliche IP zugeteilt bekommen: z.B. 192.168.1.239 Als DHCP Server wird 192.168.1.1 in den Windows-Systemen angegeben.

Von Android Systemen und Ubuntu-Systemen kommt man fehlerfrei ins Internet.

Hallo,

unter Netzwerk steht folgendes:

Network size: Small LAN(253 Clients)

Gateway IP/Subnet: 192.168.188.1/24

DHCP Range: 192.168.188.20 - 192.168.188.254

DHCP Mode: DHCP Server

DHCP Name Server: DNS Server 1: 192,168.18.19 / DNS Server 2: 10.1.0.10

DHCP Lease Time: 86400

DHCP Gateway IP: Auto

Alle weiteren Optionen sind deaktiviert.

Unter 192.168.188.19 und 10.1.0.10 läuft ein Primärer und Sekundärer Domain Name Server, der nur innerhalb des LANs zur Verfügung steht.

Hallo,

ich verwende einen Unifi USG zusammen mit einem Controller unter Debian.

In meinem Netz ist standardmäßig ein DHCP aktiviert, der automatisch eine IP von einem Bereich zuteilt.

Seit neuestem wird für manche Endgeräte eine IP zugewiesen, die total aus dem Rahmen fällt: z.B. 192.68.1.211

Im DHCP ist jedoch ein Bereich von 192.168.188.20 - 192.168.188.254 vorgesehen.

Kann mir irgend jemand mitteilen, wie so etwas zustande kommen kann?