Hallo zusammen,
am gestrigen Feiertag habe ich meinen "Fuhrpark" einheitlich auf die 10.40.0210 aktualisiert.
Zunächst (augenscheinlich) ohne Probleme...
Am Abend bemerkte ich erst, dass meine Telefonanlage (Agfeo ES548IT) sich nicht mehr beim Easybell und beim Telekom Account reistrieren konnte, angeblich Fehler bei der DNS-Auflösung für STUN-Server stun-t-online.de und stun3.l.google.com. Zudem sei der "Fernwartungsserver nicht erreichbar".
Die Anlage hat eine feste IP, als DNS ist die IP des Routers eingetragen.
Was hat sich zwischen den Versionen verändert, dass dieses Problem verursachen kann?
Da ich am Abend keine Lust auf Fehlersuche hatte, habe im 1781A wieder die 10.32.0176 aktiviert, kurz darauf ging bei der Telefonanlage wieder alles.
Was aber nun nicht mehr funktioniert, ist die Überwachung des Routers mit LAN-Monitor (10.40.0011). Er meckert:
"Die Anmeldung (...) war nicht erfolgreich. Entweder ist das Passwort falsch oder im Gerät wurde der Benutzer falsch konfiguriert. Verwenden Sie zur Authentifizierung SHA256 und für die Verschlüsselung AES256."
Das Passwort ist definitiv richtig. Wie und wo stelle ich aber SHA256 und AES256 ein?
Ein anderer 1781A am anderen Standort, an dem eine Agfeo ES548 (ohne "IT", also nur im anderen Gehäuse) hängt, läuft problemlos mit der 10.40.0201, ohne dass die Anlage dort Probleme macht.
Nachtrag: 1781A hat einmal Telekom Privatkunden ADSL über das interne Modem (nur für eine Gigaset IP-DECT Basis), einmal Telekom Busines VDSL über ein Allnet Modem. Drei Netze über ARF, eins für mich und meine Firma (über VDSL), eins für Schwester, Schwager und Neffen (auch über mein VDSL) und eben eins nur für das Gigaset Gerät (über ADSL). DNS-Server sind nirgendwo eingetragen (stehen also auf 0.0.0.0), weil die Daten ja eigentlich bei der Einwahl übermittelt werden.
1781A: Probleme nach Update
Moderator: Lancom-Systems Moderatoren
-
Carsten1972
- Beiträge: 197
- Registriert: 04 Jul 2016, 19:37
- Wohnort: Im schönen Sauerland
Re: 1781A: Probleme nach Update
Easybell soll man ohne STUN betreiben, die kommen mit NAT und wissen es auch ohne STUN oder andere Technologien zu kompensieren.
Hast du eventuell das SIP-ALG aktiv oder den VCM?
Ich kann solche Probleme aber nicht bestätigen, meine private OpenScape Business registriert sich auch bei Easybell und das mit der 10.40 ohne Probleme. Weiß jetzt aber nicht, ob ich gerade verschlüsselt oder unverschlüsselt konfiguriert habe.
In der Firma hab ich 50 Filialen mit Telekom-Anbindung, aber hier spielt der VCM mit. Probleme wurden aber keine gemeldet.
Hast du eventuell das SIP-ALG aktiv oder den VCM?
Ich kann solche Probleme aber nicht bestätigen, meine private OpenScape Business registriert sich auch bei Easybell und das mit der 10.40 ohne Probleme. Weiß jetzt aber nicht, ob ich gerade verschlüsselt oder unverschlüsselt konfiguriert habe.
In der Firma hab ich 50 Filialen mit Telekom-Anbindung, aber hier spielt der VCM mit. Probleme wurden aber keine gemeldet.
LCS NC/WLAN
Re: 1781A: Probleme nach Update
Hallo
Ich Nutze den 1781-VAW
Habe nach dem Update auf 10.40.Rel massive Probleme mit dem internen LC-DNS-Forwarder.
Externe Domains wurden gar nicht mehr aufgelöst, die DNS Answer ist REFUSE. Allerdings wurde für den internen VCM alles noch ordentlich aufgelöst " nutze auch Easybell".
Nach langem rumprobieren habe ich festgestellt daß es am Firewall liegt.
Wenn eine DenyAll Strategie aktiv ist (IP4), werden interne DNS-Anfragen an den LC, die eine externe Domain betreffen mit "REFUSE" beantwortet.
Die interne kommunikation mit dem DNS funktioniert noch, auch werden DNS Anfragen auf DHCP-Clients brav autorativ beantwortet.
Erstelle ich eine Firewallregel für EINEN Client, daß er DNS-Anfragen direkt ins Internet senden darf, so macht der LC-DNS Server auch wieder ein Forwarding zum externen DNS-server und beantwortet wieder korrekt.
Aber wieder nur für diesen EINEN freigegebenen Client, andere clients erhalten als DNS-reply weiterhin REFUSE.
Will man also per Firewall vermeiden daß interne Clients DNS-Anfragen direkt ins Internet senden, führt der interne DNS-Forwarder ebenfalls kein Forwarding für die betreffenden Clients aus (selbst nicht auf Netz-interne DNS-Server).
Eine Firewall-Regel die DNS-Namen beinhaltet hat auch nicht mehr gegriffen
.
Total unlogisch das ganze, wo es doch heißt, die internen Dienste arbeiten am Firewall vorbei.
Ein "trace dns" lässt erkennen daß er für die betreffenden Clients gar kein Forwaring versucht.
Nur für diejenigen, die im Firewall so wieso mit externen DNS-Servern reden dürfen.
Der Firewall meldet auch nichts auffälliges.
Das betrifft bei mir alle ARF-Netze auch jenes mit Routingtag 0.
Anfragen über IPv6 werden übrigens normal beantwortet.
Gruß Uwe
Ich Nutze den 1781-VAW
Habe nach dem Update auf 10.40.Rel massive Probleme mit dem internen LC-DNS-Forwarder.
Externe Domains wurden gar nicht mehr aufgelöst, die DNS Answer ist REFUSE. Allerdings wurde für den internen VCM alles noch ordentlich aufgelöst " nutze auch Easybell".
Nach langem rumprobieren habe ich festgestellt daß es am Firewall liegt.
Wenn eine DenyAll Strategie aktiv ist (IP4), werden interne DNS-Anfragen an den LC, die eine externe Domain betreffen mit "REFUSE" beantwortet.
Die interne kommunikation mit dem DNS funktioniert noch, auch werden DNS Anfragen auf DHCP-Clients brav autorativ beantwortet.
Erstelle ich eine Firewallregel für EINEN Client, daß er DNS-Anfragen direkt ins Internet senden darf, so macht der LC-DNS Server auch wieder ein Forwarding zum externen DNS-server und beantwortet wieder korrekt.
Aber wieder nur für diesen EINEN freigegebenen Client, andere clients erhalten als DNS-reply weiterhin REFUSE.
Will man also per Firewall vermeiden daß interne Clients DNS-Anfragen direkt ins Internet senden, führt der interne DNS-Forwarder ebenfalls kein Forwarding für die betreffenden Clients aus (selbst nicht auf Netz-interne DNS-Server).
Eine Firewall-Regel die DNS-Namen beinhaltet hat auch nicht mehr gegriffen
.Total unlogisch das ganze, wo es doch heißt, die internen Dienste arbeiten am Firewall vorbei.
Ein "trace dns" lässt erkennen daß er für die betreffenden Clients gar kein Forwaring versucht.
Nur für diejenigen, die im Firewall so wieso mit externen DNS-Servern reden dürfen.
Der Firewall meldet auch nichts auffälliges.
Das betrifft bei mir alle ARF-Netze auch jenes mit Routingtag 0.
Anfragen über IPv6 werden übrigens normal beantwortet.
Gruß Uwe
Re: 1781A: Probleme nach Update
Hallo Uwe,
schaue mal in diesen Thread:
feedback-lcos-release-update-betatest-f ... 18121.html
Gerade die letzten Antworten von backslash könnten dir helfen.
VG
Dirk
schaue mal in diesen Thread:
feedback-lcos-release-update-betatest-f ... 18121.html
Gerade die letzten Antworten von backslash könnten dir helfen.
VG
Dirk
Re: 1781A: Probleme nach Update
Danke.
Ich denke das passt genau auf meine Diagnose.
Ich denke das passt genau auf meine Diagnose.
-
Carsten1972
- Beiträge: 197
- Registriert: 04 Jul 2016, 19:37
- Wohnort: Im schönen Sauerland
Re: 1781A: Probleme nach Update
Hallo zusammen,
der Grund für "geht nicht" ist definitv, dass der 1781 keine DNS-Auflösung mehr macht.
Er hängt am externen Modem, er bekommt aber darüber die Telekom-DNS mitgeteilt.
Ich habe das nun erstmal so "gelöst", dass ich per DHCP die 1.1.1.1 als DNS-Server verteilen lasse, den Geräte mit fester IP habe ich ebenfalls diese Adresse als DNS eingetragen.
Firewall-Regeln im Sinne von "deny all" habe ich nicht.
Ich habe als einzige Besonderheit eine Regel, die Pakete von der Gigaset-DECT-IP-Basis mit einem Routing-Tag markiert und eine weitere, die der Telefonanlage Banbreite garantiert.
Also:
- Problem bei der 10.40.0210, dass DNS nicht durchgeleitet wird, besteht, habe ich aber unelegant umgangen
- Problem, dass der LanMonitor (10.40.0011) sich weigert, mit dem 1781A unter 10.32.0176 zu kommunizieren, würde weiter bestehen, aber ich habe ja jetzt die 10.40.0011 auf dem 1781A.
Beim Trace sehe ich, dass eine DNS Anfrage von z.B. 192.168.1.65 kommt, Routing Tag 1 (das ist INTRANET). Dann meckert er, er habe keinen DNS-Server für "default Route". Ich habe zwei Routen: VDSL und INTERNET. VDSL hat den Tag 0. Internet ist das ADSL und wird nur vom Gigaset benutzt, dessen Pakete halt in der Firewall entsprechend getaggt wurden.
der Grund für "geht nicht" ist definitv, dass der 1781 keine DNS-Auflösung mehr macht.
Er hängt am externen Modem, er bekommt aber darüber die Telekom-DNS mitgeteilt.
Ich habe das nun erstmal so "gelöst", dass ich per DHCP die 1.1.1.1 als DNS-Server verteilen lasse, den Geräte mit fester IP habe ich ebenfalls diese Adresse als DNS eingetragen.
Firewall-Regeln im Sinne von "deny all" habe ich nicht.
Ich habe als einzige Besonderheit eine Regel, die Pakete von der Gigaset-DECT-IP-Basis mit einem Routing-Tag markiert und eine weitere, die der Telefonanlage Banbreite garantiert.
Also:
- Problem bei der 10.40.0210, dass DNS nicht durchgeleitet wird, besteht, habe ich aber unelegant umgangen
- Problem, dass der LanMonitor (10.40.0011) sich weigert, mit dem 1781A unter 10.32.0176 zu kommunizieren, würde weiter bestehen, aber ich habe ja jetzt die 10.40.0011 auf dem 1781A.
Beim Trace sehe ich, dass eine DNS Anfrage von z.B. 192.168.1.65 kommt, Routing Tag 1 (das ist INTRANET). Dann meckert er, er habe keinen DNS-Server für "default Route". Ich habe zwei Routen: VDSL und INTERNET. VDSL hat den Tag 0. Internet ist das ADSL und wird nur vom Gigaset benutzt, dessen Pakete halt in der Firewall entsprechend getaggt wurden.
-
jwiesenberger
- Beiträge: 13
- Registriert: 23 Dez 2006, 12:54
Re: 1781A: Probleme nach Update
Hallo zusammen,
die Problembeschreibung von Carsten1972 passt genau auf das Problem, dass ich auch mit der FW 10.40.0210 bei einem LC-1906VA-4G beobachtet habe. Nachdem ich zurück auf die FW 10.32.0176RU9 gegangen bin, klappt mit der DNS-Auflösung wieder alles.
Auf dem Router sind drei Netze (Tag 0, 1, 3) konfiguiert. Im Netz mit Tag 0 scheint alles soweit zu klappen, in den beiden weiteren Netzen wird angemeckert, dass kein DNS für die Default-Route existiert (s.o.). Firewall-Regeln im Sinne von "deny all" habe ich ebenfalls nicht.
Bin für jeden Tipp dankbar. Bei Geräten (z.B. 1781VAW) läuft bei mir alles, solange keine unterschiedlich getaggten Netze konfiguriert sind.
Viele Grüße
Jan
die Problembeschreibung von Carsten1972 passt genau auf das Problem, dass ich auch mit der FW 10.40.0210 bei einem LC-1906VA-4G beobachtet habe. Nachdem ich zurück auf die FW 10.32.0176RU9 gegangen bin, klappt mit der DNS-Auflösung wieder alles.
Auf dem Router sind drei Netze (Tag 0, 1, 3) konfiguiert. Im Netz mit Tag 0 scheint alles soweit zu klappen, in den beiden weiteren Netzen wird angemeckert, dass kein DNS für die Default-Route existiert (s.o.). Firewall-Regeln im Sinne von "deny all" habe ich ebenfalls nicht.
Bin für jeden Tipp dankbar. Bei Geräten (z.B. 1781VAW) läuft bei mir alles, solange keine unterschiedlich getaggten Netze konfiguriert sind.
Viele Grüße
Jan
Re: 1781A: Probleme nach Update
Hi jwiesenberger und Carsten1972,
wenn der Forwarder anmerkt, daß er keinen DNS-Server auf der Default-Route hat, dann ist auf der zugehörigen WAN-Verbindung offenbar auch kein DNS-Server zugewiesen worden.
Was steht denn unter /Status/Info-Connection, /Status/WAN/IP-Addresses/IPv4, /Status/DHCP-Client/WAN-IP-List sowie /Status/PPP/Rx-Options/IPCP ?
Was sagt ein DNS-Trace, wenn die Verbindung getrennt und wieder neu aufgebaut wird (den nTrace während der Trennung laufen lassen und danach eine DNS-Anfrage stellen) ?
Gruß
Backsalsh
wenn der Forwarder anmerkt, daß er keinen DNS-Server auf der Default-Route hat, dann ist auf der zugehörigen WAN-Verbindung offenbar auch kein DNS-Server zugewiesen worden.
Was steht denn unter /Status/Info-Connection, /Status/WAN/IP-Addresses/IPv4, /Status/DHCP-Client/WAN-IP-List sowie /Status/PPP/Rx-Options/IPCP ?
Was sagt ein DNS-Trace, wenn die Verbindung getrennt und wieder neu aufgebaut wird (den nTrace während der Trennung laufen lassen und danach eine DNS-Anfrage stellen) ?
Gruß
Backsalsh