[Problem] be.IP plus - FB und VPN gelöst, jetzt noch Fragen zu AWS
- Ersteller ratatatatat
- Erstellt am
Hallo _tms und toschcom,
danke fuer eure Hinweise!
@tms: Ich denke auch, dass es irgendwas mit den Sicherheitssystemen der beIP zu tun hat. Die Firewall ist lt. Handbuch eine Stateful Inspection Firewall (SIF), aber ich habe die VPN-Verbindung zu den vertrauenswuerdigen Schnittstellen hinzugefuegt, sie sollte also nicht intervenieren. Und das NAT sollte doch eigentlich durch NAT-T gebaendigt sein, oder?
@toschcom: Ich habe den VPN-Zugang auch zuerst nach den Empfehlungen des elmegbintec-Channels konfiguriert. Wie Du in meinen Screenshots siehst, habe ich eigentlich auch alles wie im Video konfiguriert, nur mit besseren Sicherheitseinstellungen.
--------
Ich habe neben dem VPN noch ein weiteres Problem: die AWS (Anrufweiterschaltung). Zum Einen reagiert diese nicht, wenn an einer Nummer kein Geraet registriert ist. Ich moechte aber, dass die Anrufe immer dann weitergeleitet werden, wenn die Softphones der Kolleg*innen ausgeschaltet sind. Dann wird der Anruf allerdings ins Leere geleitet.
Zum anderen wuerde ich gerne bei der AWS die Nummer des Anrufers mit weiterleiten. Zur Zeit sieht der finale Anrufnehmer nur die Nummer der weiterleitenden Stelle.
Sind das beides etwas Probleme, die man direkt bei der Telekom loesen muss? Die schluessigsten Hinweise bei der bisherigen Recherche deuten darauf hin, dass das mit der Nummer bspw. nur durch Umleitung im Amt und nicht im System geschehen kann. Stimmt das?
Ich danke euch!
danke fuer eure Hinweise!
@tms: Ich denke auch, dass es irgendwas mit den Sicherheitssystemen der beIP zu tun hat. Die Firewall ist lt. Handbuch eine Stateful Inspection Firewall (SIF), aber ich habe die VPN-Verbindung zu den vertrauenswuerdigen Schnittstellen hinzugefuegt, sie sollte also nicht intervenieren. Und das NAT sollte doch eigentlich durch NAT-T gebaendigt sein, oder?
@toschcom: Ich habe den VPN-Zugang auch zuerst nach den Empfehlungen des elmegbintec-Channels konfiguriert. Wie Du in meinen Screenshots siehst, habe ich eigentlich auch alles wie im Video konfiguriert, nur mit besseren Sicherheitseinstellungen.
--------
Ich habe neben dem VPN noch ein weiteres Problem: die AWS (Anrufweiterschaltung). Zum Einen reagiert diese nicht, wenn an einer Nummer kein Geraet registriert ist. Ich moechte aber, dass die Anrufe immer dann weitergeleitet werden, wenn die Softphones der Kolleg*innen ausgeschaltet sind. Dann wird der Anruf allerdings ins Leere geleitet.
Zum anderen wuerde ich gerne bei der AWS die Nummer des Anrufers mit weiterleiten. Zur Zeit sieht der finale Anrufnehmer nur die Nummer der weiterleitenden Stelle.
Sind das beides etwas Probleme, die man direkt bei der Telekom loesen muss? Die schluessigsten Hinweise bei der bisherigen Recherche deuten darauf hin, dass das mit der Nummer bspw. nur durch Umleitung im Amt und nicht im System geschehen kann. Stimmt das?
Ich danke euch!
Hi,
Vertrauenswürdig muss die VPN-Schnittstelle nicht zwingend sein. Das hängt davon, welche Zugriffe darüber realisieren möchtest.
NAT brauchst du dafür auch nicht.
Nach dem Log kommt bei Dir die Verbindung wegen "no proposal chosen" zustande. Das weist darauf hin, dass mit den IDs und/oder den eingestellten Proposals etwas nicht stimmt.
Die Frage nach der FW hast Du leider nicht beantwortest. Es gab mehrere FWs bei denen IKEv2 nicht funktioniert hat.
Vertrauenswürdig muss die VPN-Schnittstelle nicht zwingend sein. Das hängt davon, welche Zugriffe darüber realisieren möchtest.
NAT brauchst du dafür auch nicht.
Nach dem Log kommt bei Dir die Verbindung wegen "no proposal chosen" zustande. Das weist darauf hin, dass mit den IDs und/oder den eingestellten Proposals etwas nicht stimmt.
Die Frage nach der FW hast Du leider nicht beantwortest. Es gab mehrere FWs bei denen IKEv2 nicht funktioniert hat.
@toschcom: ja! Sobald ich aber manuell in den VPN-Einstellungen auf IKEv2 und längere Schlüssel umgestellt hatte, funktionierte es nicht mehr. Liegt es also an einer möglichen Inkompatibilität Shrew / IKEv2? - in der Doku zu Shrew findet sich nix über IKEv2.
@_tms: Sorry, dann habe ich Deine Frage nicht recht verstanden. Es läuft die Defaultfirewall, ich wusste nicht, dass man da selber was installieren kann? Welche Firewall das genau ist, weiß ich nicht. "Vertrauenswürdig" habe ich deswegen erwähnt, weil damit die FW als Fehlerquelle doch eigentlich auszuschliessen wäre. NAT-T brauche ich dann aber später bei Voip schon, oder? Für den Tunnelaufbau ist es nicht relevant, meinst Du, oder? Oder habe ich das komplett falsch verstanden.
Proposals: hatte ich ja exakt gleich eingestellt bei beIP _und_ ShrewVPN, ABER vielleicht kann Letzterer ja wirklich kein IKEv2?
@_tms: Sorry, dann habe ich Deine Frage nicht recht verstanden. Es läuft die Defaultfirewall, ich wusste nicht, dass man da selber was installieren kann? Welche Firewall das genau ist, weiß ich nicht. "Vertrauenswürdig" habe ich deswegen erwähnt, weil damit die FW als Fehlerquelle doch eigentlich auszuschliessen wäre. NAT-T brauche ich dann aber später bei Voip schon, oder? Für den Tunnelaufbau ist es nicht relevant, meinst Du, oder? Oder habe ich das komplett falsch verstanden.
Proposals: hatte ich ja exakt gleich eingestellt bei beIP _und_ ShrewVPN, ABER vielleicht kann Letzterer ja wirklich kein IKEv2?
Tschuldigung, mit FW meinte ich nicht Firewall, sondern Firmware auf der be.IP.
Was meinst Du mit NAT für VoIP?
Was hast du genau vor? Der SHrew läuft doch auf einem PC/NB. Wenn du auf dem ein VoIP-Client installierst, dann braucht es dafür kein NAT.
Vertrauenswürdig muss die Verbindung nicht sein, wenn du die Kommunikationsregeln selber definieren möchtest.
Bei Vertrauenswürdig geht alles außer opt. Ausnahmen durch.
Bei Nicht-Vertrauenswürdig geht nichts durch, außer dem, was du explizit definierst.
Die be.IP kann auf jeden Fall IKEv2 (benutze ich auch). Probiere es doch erstmal mit einfacheren Prosopals und PSK.
Was meinst Du mit NAT für VoIP?
Was hast du genau vor? Der SHrew läuft doch auf einem PC/NB. Wenn du auf dem ein VoIP-Client installierst, dann braucht es dafür kein NAT.
Vertrauenswürdig muss die Verbindung nicht sein, wenn du die Kommunikationsregeln selber definieren möchtest.
Bei Vertrauenswürdig geht alles außer opt. Ausnahmen durch.
Bei Nicht-Vertrauenswürdig geht nichts durch, außer dem, was du explizit definierst.
Die be.IP kann auf jeden Fall IKEv2 (benutze ich auch). Probiere es doch erstmal mit einfacheren Prosopals und PSK.
Achsoo, sorry, da hätte ich auch drauf kommen können. Ich benutze die aktuellste FW, die "V.10.2.4.100 IPv6, IPSec, PBX from 2018/08/17 00:00:00"
Mein Plan: VPN für a) Zugang zum Fileserver und b) für SIP-Clients außerhalb (zB im Homeoffice) -- Könnte man die beip eigentlich mit der öffentlichen IP auch als Cloud-PBX nutzen?
Okay, dann habe ich NAT-T als Technik wohl nicht ganz verstanden. Mein Gedanke war, dass wenn eine interne Anruf-Umleitung o.Ä. von einem Client im Netzwerk auf den Remote-Client gehen soll NAT-T gebraucht wird, weil sonst die Informationen vom Host- oder Client-Router-NAT geblockt werden.
Wie gesagt, vertrauenswürdig habe ich nur deshalb aktiv, damit ich sichergehen kann, dass die Firewall nicht die VPN-Verbindung irgendwie beeinträchtigt. Später werde ich da die erforderlichen Regeln einrichten.
Ich glaube mittlerweile, dass einfach ShrewVPN und nicht die beIP plus mit IKEv2 Probleme haben. Leider funktioniert es mit den Windows7-Defaultprogrammen auch nicht, dafür müsste ich erst L2TP einrichten, wenn ich das richtig verstanden habe.
Sorry, meinerseits ist das sehr laienhaft, ich habe mich noch nie richtig mit solch einem (für mich) komplexen Router beschäftigt.
EDIT: IKEv1 funktioniert auch mit den langen Schlüssellängen AES256, SHA-512 und DH-16, liegt also wsl wirklich an v2.
EDIT2: Also die Verbindung Win 7 Boardmittel - IKEv2 mit geringer Verschlüsselung (AES / SHA1) bekomme ich einfach nicht hin. Als Fehler in Windows kommt immer "809", was angeblich auf Fehler in Firewall / NAT / etc. zurückzuführen sei. Auf der beIP werden die Proposals als Grund angegeben (IKE_SA: peer 0 () sa 16 (R): server ip <- client ip: proposal mismatch, jedoch sehe ich in Windows keine Möglichkeit die Proposals so fein wie in ShrewVPN einzurichten. Shrew dagegen kann höchstwahrscheinlich kein IKEv2 (vgl. https://www.reddit.com/r/sysadmin/comments/6l84ax/shrew_vpn_client_with_windows_rras/djry47a/ )
Mein Plan: VPN für a) Zugang zum Fileserver und b) für SIP-Clients außerhalb (zB im Homeoffice) -- Könnte man die beip eigentlich mit der öffentlichen IP auch als Cloud-PBX nutzen?
Okay, dann habe ich NAT-T als Technik wohl nicht ganz verstanden. Mein Gedanke war, dass wenn eine interne Anruf-Umleitung o.Ä. von einem Client im Netzwerk auf den Remote-Client gehen soll NAT-T gebraucht wird, weil sonst die Informationen vom Host- oder Client-Router-NAT geblockt werden.
Wie gesagt, vertrauenswürdig habe ich nur deshalb aktiv, damit ich sichergehen kann, dass die Firewall nicht die VPN-Verbindung irgendwie beeinträchtigt. Später werde ich da die erforderlichen Regeln einrichten.
Ich glaube mittlerweile, dass einfach ShrewVPN und nicht die beIP plus mit IKEv2 Probleme haben. Leider funktioniert es mit den Windows7-Defaultprogrammen auch nicht, dafür müsste ich erst L2TP einrichten, wenn ich das richtig verstanden habe.
Sorry, meinerseits ist das sehr laienhaft, ich habe mich noch nie richtig mit solch einem (für mich) komplexen Router beschäftigt.
EDIT: IKEv1 funktioniert auch mit den langen Schlüssellängen AES256, SHA-512 und DH-16, liegt also wsl wirklich an v2.
EDIT2: Also die Verbindung Win 7 Boardmittel - IKEv2 mit geringer Verschlüsselung (AES / SHA1) bekomme ich einfach nicht hin. Als Fehler in Windows kommt immer "809", was angeblich auf Fehler in Firewall / NAT / etc. zurückzuführen sei. Auf der beIP werden die Proposals als Grund angegeben (IKE_SA: peer 0 () sa 16 (R): server ip <- client ip: proposal mismatch, jedoch sehe ich in Windows keine Möglichkeit die Proposals so fein wie in ShrewVPN einzurichten. Shrew dagegen kann höchstwahrscheinlich kein IKEv2 (vgl. https://www.reddit.com/r/sysadmin/comments/6l84ax/shrew_vpn_client_with_windows_rras/djry47a/ )
Zuletzt bearbeitet:
Der Shrew ist ja auch schon ein bisschen älter. Kann durchaus sein, dass der Probleme mit IKEv2 hat.
Deinen Plan habe ich leider immer noch nicht ganz verstanden.
- Serverzugriff: kein Thema: Mit dem VPN zum Router bist du ja mit dem NB quasi im Servernetz. Ein SW-SIP Client auf dem NB sollte auch direkt funktionieren. Wozu NAT?
- Was meinst Du mit "SIP Clients außerhalb"? Das verstehe ich nicht. Möchtest Du z.B. ein eigenständiges IP-Telefon über die VPN Verbindung des Rechners routen? OK, hierfür braucht es wahrscheinlich schon NAT. Sowas habe ich aber bisher nicht gebaut.
Ansonsten: Es müsste schon gehen, dass man die be.IP im Netz öffentlich macht und VoIP Clients direkt anspricht. Du müsstest nachsehen, was du dazu alles auf der be.IP dafür öffnen müsstest. Ich persönlich hätte bei so einer Konfig spontan arge Bedenken, man müsste sich das aber im Detail ansehen.
Deinen Plan habe ich leider immer noch nicht ganz verstanden.
- Serverzugriff: kein Thema: Mit dem VPN zum Router bist du ja mit dem NB quasi im Servernetz. Ein SW-SIP Client auf dem NB sollte auch direkt funktionieren. Wozu NAT?
- Was meinst Du mit "SIP Clients außerhalb"? Das verstehe ich nicht. Möchtest Du z.B. ein eigenständiges IP-Telefon über die VPN Verbindung des Rechners routen? OK, hierfür braucht es wahrscheinlich schon NAT. Sowas habe ich aber bisher nicht gebaut.
Ansonsten: Es müsste schon gehen, dass man die be.IP im Netz öffentlich macht und VoIP Clients direkt anspricht. Du müsstest nachsehen, was du dazu alles auf der be.IP dafür öffnen müsstest. Ich persönlich hätte bei so einer Konfig spontan arge Bedenken, man müsste sich das aber im Detail ansehen.
Ich gebe aber auch zu, dass ich sehr kompliziert geschrieben habe, mir ordnet sich das selber im Kopf nur langsam.
Ich möchte das VPN genauso nutzen, wie Du es beschrieben hast: als Möglichkeit sicher in das Firmennetz zu kommen. Das brauchen die Mitarbeiter*innen, um auf den Fileserver zuzugreifen und die von der beIP verwalteten SIP-Anschlüsse mit Softphones auf dem Laptop und auf mobilen Endgeräten nutzen zu können.Soweit war das auch kein Neuland für mich und es klappte auch mit IKEv1 & Shrew wunderbar. Der Zugriff auf den Fileserver funktionierte und mein Softphone (Linphone) konnte sich an der beIP registrieren und Anrufe tätigen / empfangen.
Dann wollte ich auf IKEv2 umstellen, weil ich von diversen Vorteilen las und es mir sinnvoll erschien direkt die modernere Variante mit sichereren Schlüssellängen/Verschlüsselungsmethoden einzurichten. Damit begann das ganze Drama, bei dem ich jetzt mehr über IPSec / NAT / Firewalls etc. lernen durfte, als ich ursprünglich wollte. So sicher sitzt das aber alles nicht, wie Du an meinem Geschwurbel zB zu NAT-T ja bereits feststellen musstest
EDIT: IKEv2 funktioniert übrigens mit dem Bintec-Elmeg Secure Client mit exakt den Einstellungen meines ersten VPN-Postings... Damit suche ich nun eine Möglichkeit das mit Windows7-Boardmitteln oder einem nicht-proprietären und kostenpflichtigen Client hinzukriegen.
Ich möchte das VPN genauso nutzen, wie Du es beschrieben hast: als Möglichkeit sicher in das Firmennetz zu kommen. Das brauchen die Mitarbeiter*innen, um auf den Fileserver zuzugreifen und die von der beIP verwalteten SIP-Anschlüsse mit Softphones auf dem Laptop und auf mobilen Endgeräten nutzen zu können.Soweit war das auch kein Neuland für mich und es klappte auch mit IKEv1 & Shrew wunderbar. Der Zugriff auf den Fileserver funktionierte und mein Softphone (Linphone) konnte sich an der beIP registrieren und Anrufe tätigen / empfangen.
Dann wollte ich auf IKEv2 umstellen, weil ich von diversen Vorteilen las und es mir sinnvoll erschien direkt die modernere Variante mit sichereren Schlüssellängen/Verschlüsselungsmethoden einzurichten. Damit begann das ganze Drama, bei dem ich jetzt mehr über IPSec / NAT / Firewalls etc. lernen durfte, als ich ursprünglich wollte. So sicher sitzt das aber alles nicht, wie Du an meinem Geschwurbel zB zu NAT-T ja bereits feststellen musstest
EDIT: IKEv2 funktioniert übrigens mit dem Bintec-Elmeg Secure Client mit exakt den Einstellungen meines ersten VPN-Postings... Damit suche ich nun eine Möglichkeit das mit Windows7-Boardmitteln oder einem nicht-proprietären und kostenpflichtigen Client hinzukriegen.
Zuletzt bearbeitet:
Also wenn du es geschäftlich nutzen möchtest dann müßte es ja nicht immer die kostenlose Version sein. Ich benutze den Lancom Advanced VPN Client (denke das sind alle auf Basis des NCP Clients).
Mit dem mobilen Endgerät funktioniert bei mir z.B. einwandfrei. Hab auf meinem Samsung S6 ein VPN eingerichtet und in be be.ip eine Nebenstelle für mein Handy!
Mit dem mobilen Endgerät funktioniert bei mir z.B. einwandfrei. Hab auf meinem Samsung S6 ein VPN eingerichtet und in be be.ip eine Nebenstelle für mein Handy!
Ok, jetzt verstehe ich.
Es lief also alles schon mal bis zu der Idee mit IKEv2.
So, wie ich das sehe, hast du zwei Alternativen:
a) Du bleibst beim Shrew und IKEv1
b) Du besorgst dir "ordentliche" VPN Clients für die PCs. Empfehlenswert sind der NCP Client von Bintec oder gleich das Original von NCP = SecureEntryClient. Ich nehme immer den von NCP, weil man dann sofort von etwaigen Updates von NCP profitieren kann.
Es lief also alles schon mal bis zu der Idee mit IKEv2.
So, wie ich das sehe, hast du zwei Alternativen:
a) Du bleibst beim Shrew und IKEv1
b) Du besorgst dir "ordentliche" VPN Clients für die PCs. Empfehlenswert sind der NCP Client von Bintec oder gleich das Original von NCP = SecureEntryClient. Ich nehme immer den von NCP, weil man dann sofort von etwaigen Updates von NCP profitieren kann.
Aber Win7 ist doch IKEv2-kompatibel.... Ich bin gestern noch so durchgedreht, dass ich die Pakete mit Wireshark mitgeschnitten habe, um rauszufinden, was Windows denn der beIP so proposed. Vielleicht helfen meine Erkenntnisse ja jmd, der oder die sich spaeter mal mit Windows VPN und beIP beschaeftigen moechte.
Normalerweise sollte man die IPSec-Proposals von Win7 in der erweiterten Firewall -> Eigenschaften -> IPSec -> Erweitert -> Anpassen aendern koennen. Das scheint aber keinen Unterschied zu machen...
Default schlaegt Windows 7 in der SA_INIT als Encryption 3DES und als Auth. SHA1 (96bit) vor, mit Zahlen aus der DH-Gruppe 2 (1024bit) (bzw. ein Multiproposal mit AES256-CBC hintendran). Ich kam damit so weit, dass die beIP zumindest den ersten der 4 IKEv2 Schritte akzeptierte. Danach waren die Pakete natuerlich verschluesselt, sodass ich meine Analyse abbrechen musste (falls jemand weisz, wie man hier weiter verfaehrt, sagt mir bitte Bescheid!).
Ich werde meinen Arbeitgeber wohl vom NCP ueberzeugen muessen, ist mir selber auch ein Dorn im Auge, weil ich eigentlich moeglichst FOSS im Netzwerk bleiben moechte. Der Markt dazu ist aber seeehr ueberschaubar
-------------------------
Egal, Schlusz damit! Einmal mehr danke an euch! Kann mir zufaellig noch jemand bei den Telefonproblemen von vorher helfen?
Normalerweise sollte man die IPSec-Proposals von Win7 in der erweiterten Firewall -> Eigenschaften -> IPSec -> Erweitert -> Anpassen aendern koennen. Das scheint aber keinen Unterschied zu machen...
Default schlaegt Windows 7 in der SA_INIT als Encryption 3DES und als Auth. SHA1 (96bit) vor, mit Zahlen aus der DH-Gruppe 2 (1024bit) (bzw. ein Multiproposal mit AES256-CBC hintendran). Ich kam damit so weit, dass die beIP zumindest den ersten der 4 IKEv2 Schritte akzeptierte. Danach waren die Pakete natuerlich verschluesselt, sodass ich meine Analyse abbrechen musste (falls jemand weisz, wie man hier weiter verfaehrt, sagt mir bitte Bescheid!).
Ich werde meinen Arbeitgeber wohl vom NCP ueberzeugen muessen, ist mir selber auch ein Dorn im Auge, weil ich eigentlich moeglichst FOSS im Netzwerk bleiben moechte. Der Markt dazu ist aber seeehr ueberschaubar
-------------------------
Egal, Schlusz damit! Einmal mehr danke an euch! Kann mir zufaellig noch jemand bei den Telefonproblemen von vorher helfen?
Übrigens:
Ich hab's das mit dem Software SIP Client (bei mir war's PhonerLite) mal spaßeshalber ausprobiert und es funktioniert prima, auch per VPN.
Damit das ganze auch von unterwegs auch funktioniert, muss man an der be.IP einen passenden Standort (z.B. mit Interface = VPN_Peer) anlegen (oder einen vorhandenen anpassen) und diesen dann bei der IP-Telefon-Einrichtung berücksichtigen.
Tach zusammen, aus aktuellem Anlass (ich bin im Urlaub und an Tag 1 faellt die FritzBox als DECT-Gateway aus... fml) hole ich das Thema nochmal raus. Kann mir jemand mit dem Problem helfen, dass die AWS nicht funktioniert, wenn keine aktives Geraet auf die Nummer geschalten ist.
Derzeitiges Verhalten: DECT-Geraete tot. In der AWS eine Weiterleitung auf die jeweiligen Handynummern der Mitarbeiter*innen geschalten. Bei Anruf auf die Nummer --> sofortiges Besetztzeichen.
Gewuenschtes Verhalten: Bei Anruf -> Zugeordnetes Geraet nicht zu erreichen -> Weiterleitung auf Handynummer (am besten mit Weiterleitung der Nummer des originaeren Anrufers)
Danke schonmal fuer die Antworten!
Derzeitiges Verhalten: DECT-Geraete tot. In der AWS eine Weiterleitung auf die jeweiligen Handynummern der Mitarbeiter*innen geschalten. Bei Anruf auf die Nummer --> sofortiges Besetztzeichen.
Gewuenschtes Verhalten: Bei Anruf -> Zugeordnetes Geraet nicht zu erreichen -> Weiterleitung auf Handynummer (am besten mit Weiterleitung der Nummer des originaeren Anrufers)
Danke schonmal fuer die Antworten!
Komisch,
ich hab' vor zwei Tagen sowas ähnliches gehabt und da klappt es.
Konkret:
Benutzer verwendet ein IP-Telefon, welches derzeit wegen Renovierungsarbeiten nicht am LAN ist. Die AWS "Nichtmelden" auf sein Smartphone funktioniert trotzdem.
ich hab' vor zwei Tagen sowas ähnliches gehabt und da klappt es.
Konkret:
Benutzer verwendet ein IP-Telefon, welches derzeit wegen Renovierungsarbeiten nicht am LAN ist. Die AWS "Nichtmelden" auf sein Smartphone funktioniert trotzdem.
keine Ahnung. Ich habe mal meine Konfiguration drangehangen.
Die Idee ist, dass jede Nummer zuerst auf eine zentrale Nummer bei Besetzt/Nichtmelden geht und, wenn die auch nicht erreichbar ist, auf ein Firmenhandy. Aber auch die direkte Anwahl der zentralen Nummer leitet in den Telefontod.
Die Idee ist, dass jede Nummer zuerst auf eine zentrale Nummer bei Besetzt/Nichtmelden geht und, wenn die auch nicht erreichbar ist, auf ein Firmenhandy. Aber auch die direkte Anwahl der zentralen Nummer leitet in den Telefontod.
Anhänge
Ist die 60 von extern direkt erreichbar?
Wenn ja, klappt die AWS, wenn du von extern die 60 direkt anwählst?
Das entspräche der Konfig, die wir haben und bei der die AWS funktioniert.
Wenn ja, klappt die AWS, wenn du von extern die 60 direkt anwählst?
Das entspräche der Konfig, die wir haben und bei der die AWS funktioniert.
Ich weiß nicht ganz, was Du mit extern erreichbar meinst. Die 60 ist die interne Nummer der Fritz!Box, die als DECT-Basis dient. Ihr (und vier anderen internen Nummern = Softphones) sind zwei externe Nummern / Anschluesse zugeordnet. Beide sind nicht erreichbar, wenn weder Softphone noch DECT-Basis angemeldet sind. Aber anstatt auf die letzte Nummer des Screenshots umzuleiten, wird der Anruf gar nicht erst angenommen.
Ich hab' gerade mal getestet:
Hier funktionieren die AWS für analoge, ISDN, und IP Telefone, die gar nicht existieren und nur unter Endgeräte definiert sind.
Wie sind die DECT Telefone bei dir genau an der Be.IP angebunden?
Haben die einzelnen DECT Telefonnummer interne Rufnummern in der be.IP?
Was genau ist die 60?
Hier funktionieren die AWS für analoge, ISDN, und IP Telefone, die gar nicht existieren und nur unter Endgeräte definiert sind.
Wie sind die DECT Telefone bei dir genau an der Be.IP angebunden?
Haben die einzelnen DECT Telefonnummer interne Rufnummern in der be.IP?
Was genau ist die 60?
Tach _tms, danke fuer Deine bestaendige Hilfe!
DECT Geraete 1 bis 4 sind an der FB angemeldet -> 5 interne Nummern in der beIP: 1 fuer alle (60) und jeweils 1 fuer jedes einzelne DECT-Geraet (62-65).
Aber zur Zeit ist ja einfach kein einziges in der beIP verzeichnetes Geraet erreichbar, deshalb sollte doch jeder Anruf mit obiger Konfiguration auf die im Screenshot zuletzt definierte Nummer weitergeschalten werden, oder?
Also bspw. rufe ich die zur 63 gehoerige externe Nummer an. Zu ihr gehoert auszerdem die 73, die dem nicht angemeldeten Softphone der 63-BenutzerIn entspricht. Beide Nummern sind nicht erreichbar = Nichtmelden. Die beIP versucht also den Anruf auf die 60, also auf alle DECT-Geraete weiterzuschalten und wieder = Nichtmelden. Nun sollte der Anruf doch auf die zuletzt definierte Nummer, einer externen Handynummer, leiten. Wo liegt mein Fehler?
DECT Geraete 1 bis 4 sind an der FB angemeldet -> 5 interne Nummern in der beIP: 1 fuer alle (60) und jeweils 1 fuer jedes einzelne DECT-Geraet (62-65).
Aber zur Zeit ist ja einfach kein einziges in der beIP verzeichnetes Geraet erreichbar, deshalb sollte doch jeder Anruf mit obiger Konfiguration auf die im Screenshot zuletzt definierte Nummer weitergeschalten werden, oder?
Also bspw. rufe ich die zur 63 gehoerige externe Nummer an. Zu ihr gehoert auszerdem die 73, die dem nicht angemeldeten Softphone der 63-BenutzerIn entspricht. Beide Nummern sind nicht erreichbar = Nichtmelden. Die beIP versucht also den Anruf auf die 60, also auf alle DECT-Geraete weiterzuschalten und wieder = Nichtmelden. Nun sollte der Anruf doch auf die zuletzt definierte Nummer, einer externen Handynummer, leiten. Wo liegt mein Fehler?
Neueste Beiträge
-
Mesh System- schlechter Empfang- Letzte: Jstessi
-
[Sammlung] Fritz!Box 5690Pro, Inhaus/Labor 7.90, Pfad 'Smart24P1FCS'
- Letzte: streetjumper16
-
5690 Pro Datenraten Problem 5ghz und 6ghz
- Letzte: BlacknightSat
-
[Problem] T41s registriert nicht an Fritzbox
- Letzte: ernesto_filo
-
Wer versucht mich da zu hacken?- Letzte: Roboto
-
Keine Tastenprogrammierung im WBM- Letzte: schwester
-
