[Erledigt] Externe VoiP-App auf Digibox

[Tom Bombadil]

Hallo,

sind für die Anmeldung von VoiP-Apps 'von draussen' in einer Digibox spezielle Einstellungen notwendig, z.B. in der internen Firewall? Solange ich hier im LAN mit Zoiper und ähnlichen Apps herumprobiere, funktioniert alles prächtig; sobald ich von draußen komme, können sich die VoiP-Apps auf den Mobilgeräten nicht mehr einbuchen (Fehler 408, Request Timeout).

Konfiguration:

IP-Telefone <-- PoESwitch <--+
                             |
LAN <--- USG Pro Firewall <--+ DigiBox Premium <-- Telekom / Internet

Ist-Zustand:

• LAN traffic intern/extern läuft sauber, hier hängen u.a. 2 Exchange-Mailserver, die von intern und extern errreichbar sind.
• Die IP-Telefone buchen sich ordnungsgemäß aus dem Telefon-LAN in die Digibox ein.
• VoiP-Apps buchen sich ordnungsgemäß aus dem Firmen-LAN in die Digibox ein.

Aber:

• Dieselben VoiP-Apps können sich über das Internet *NICHT* in die Digibox einbuchen. Alle Einstellungen in den Apps bleiben gleich, es wurde nur von der internen auf die externe IP der Digibox umgestellt und WLAN ausgeschaltet (Zugang somit über LTE).

Anfragen von der WAN-Schnittstelle werden durch die Digibox pauschal an das USG weitergeleitet, somit sehr wahrscheinlich auch Port 5060. Ich vermute hier das Problem, weiß aber nicht so recht, wie weiter - kennt sich jemand damit aus?

/tom

 

[wari1957]

Hallo @Tom Bombadil ,
warum verbindest du die Smartphones nicht per VPN (IPSec) mit der DB?
Dann sollte die Registrierung eigentlich kein Problem sein.

 

[Tom Bombadil]

Weil

1. ich jeden User bzw. sein Mobilgerät zusätzlich als VPN-Verbindung in der Box einrichten und konfigurieren muss,
2. die User einen weiteren Schritt durchführen müssen (erst von Hand VPN aufbauen, dann VoiP-App aufrufen),
3. ich mir den VPN-Overhead im Traffic ersparen wollte,

und ich voraussichtlich in Spitzenzeiten mehr als 5 Verbindungen haben werde (die Digibox kann meines Wissens nur 5 gleichzeitige VPN-Verbindungen, kein Upgrade wie bei bintec möglich).

/tom

 

[wari1957]

@Tom Bombadil
Dann mußt du halt die "Uneingeschränkte Registrierung" erlauben.

 

[Tom Bombadil]

Benutzerklasse der neu angelegten "Home Office User" steht jeweils auf 'uneingeschränkt', Standort der entsprechenden Endgeräte auf 'Nicht definiert (Uneingeschränkte Registrierung)'. Mit dem eingangs genannten Ergebnis ...
/tom

 

[wari1957]

@Tom Bombadil
Dann würde ich mal einen Netzwerktrace in der DB auf der WAN-Schnittstelle starten und sehen ob Daten von den Smartphones an der DB ankommen.

 

[totalverrückteruser]

Anfragen von der WAN-Schnittstelle werden durch die Digibox pauschal an das USG weitergeleitet, somit sehr wahrscheinlich auch Port 5060. Ich vermute hier das Problem,

Wenn die Ports weitergeleitet werden, kommt die Registrierung nicht an der Box an.
Jetzt wäre eine Möglichkeit, die Weiterleitung entsprechend zu bearbeiten.

 

[Tom Bombadil]

Ja, das ist ein möglicher Ansatz - Ausnahmeregel vor dem globalen Forward definieren. Ich blicke nur nach wie vor bei diesen ganzen verwirrenden Schnittstellenbezeichnungen nicht durch - wohin (an welche konkrete Schnittstellenbezeichnung) müsste ich denn z.B. Port 5060 von wo weiterleiten, damit die Anfrage von der Digibox ausgewertet wird - WAN_DTAG_Internet-Zugang? BRIDGE_BR0? BRIDGE_BR0-1? WAN-EFM oder WAN-ETHx? Und reicht 5060, oder muss da noch mehr geforwarded werden?

Für das USG war es ja vergleichsweise einfach und logisch - Gerät 'USG' mit fester IP definieren, danach Weiterleitung aller Protokolle (ANY) von WAN_DTAG_Internet-Zugang an das Gerät 'USG'. Fertig ...

/tom

 

[totalverrückteruser]

Mit Any hast Du alles erschlagen.
Aber Du willst nicht Any. Also musst Du Dir mal Gedanken machen, was und warum Du überhaupt was weiterleitest.
Weiterleiten musst Du grundsätzlich nur die Serverdienste, welche von außen erreichbar sein müssen. An die Box leitest Du nix weiter - die fängt sich sowieso allen Verkehr von aussen ein - ausser das, wo Du gesagt hast "Gugg es Dir nicht an sondern schick es an die USG".

 

[wari1957]

Die normale Telefonie funktioniert doch mit der DB?
Also werden die Ports 5060 bzw, 5061 auch nicht weitergeleitet, sonst könntest du keine Gespräche empfangen.

 

[chrsto]

Diese Annahme ist falsch, da bei der Telekom (und vielen anderen Providern auch) VoIP Verbindungen ausschließlich mit ausgehenden Verbindungen (aus Sicht der DigiBox) hergestellt werden.

Konkret wird eine SIP Verbindung zum Provider aufgebaut und mit SIP Options oder Keepalives gehalten. Über diese Verbindung meldet der Provider dann auch eingehende Anrufe bei der Digibox. Anschließend wird über RTP eine Sprachverbindung, wiederum DigiBox -> Provider, aufgebaut.

 

[wari1957]

Diese Annahme ist falsch, da bei der Telekom (und vielen anderen Providern auch) VoIP Verbindungen ausschließlich mit ausgehenden Verbindungen (aus Sicht der DigiBox) hergestellt werden.

Das bestreite ich ja nicht.
Welchen eingehenden Port wird die DB verwenden?

 

[totalverrückteruser]

Dann sollten ja eigentlich Telefonanlagen hinter Routern, welche Port 5060 nicht für sich selbst anouncieren kein Problem sein. Oder sehe ich da was falsch.

Egal wie, auch bei einer Weiterleitung sollten im Log der be.ip plus mindestens 4 Zeilen zu der Verbindung zu finden sein. Hier ein beispiel einer vom nachfolgenden Server abgelehnten Verbindung:
Nov 16 05:39:59 192.168.222.5 INET: NAT: delete session on ifc 30010001 prot 6 192.168.222.4:1194/91.60.xxx.xxx:443 <-> 172.104.138.223:2424
Nov 16 05:39:35 192.168.222.5 INET: destroy session, 172.104.138.223:2424->192.168.222.4:1194 prot: 6
Nov 16 05:39:35 192.168.222.5 INET: TIMEOUT Session expired: 172.104.138.223:2424->192.168.222.4:1194 prot=6
...
Nov 16 05:39:22 192.168.222.5 INET: SIF: 4 Accept WAN_GERMANY - TELEKOM EN[30010001:172.104.138.223:2424] -> BRIDGE_BR0[39000000:192.168.222.4:1194] ovpn:6
Nov 16 05:39:22 192.168.222.5 INET: new session, 172.104.138.223:2424->192.168.222.4:1194 prot: 6 parent: false
Nov 16 05:39:22 192.168.222.5 INET: NAT: new incoming session on ifc 30010001 prot 6 192.168.222.4:1194/91.60.xxx.xxx:443 <- 172.104.138.223:2424

 

[Tom Bombadil]

Kurzes Update: Hab heute ein SIP-Protokoll mitschneiden lassen - die Digibox 'sieht' die einkommenden Registrieranfragen einfach nicht, egal was ich mache. Zoiper habe ich auch wieder verworfen - die Pro-Version läuft zwar auf einem per VPN verbundenen Notebook ganz gut, aber die Mobilversion (iOS) bucht sich aus, sobald das Handy in den Ruhemodus geht. Unbrauchbar.

Derzeit funktionierende Variante:

• Vorweg: VPN läuft schon seit langem für Homeoffice-Mitarbeiter im USG. Daher konnte ich die weiter oben genannte VPN-Variante in der Digibox auch bisher nicht nutzen, da diese Port 500 etc pp direkt an das USG weitergibt.
• Ich hab 2 zusätzliche Anwender im USG registriert, auf deren beiden iPhones VPN + Grandstream Wave Lite konfiguriert. Letzteres überlebt auch 'Sleep' am Handy. (yay!) Im Grunde verhalten sich die Handies nun wie unsere Mitarbeiter-Notebooks mit zusätzlicher Voip-App.
• Funktioniert: Testanruf von außen --> Annahme Zentrale Firma --> Weiterleitung auf Handy mit interner Digibox-Rufnummer, die auf den "Festnetz-Telefon-BLF" angezeigt wird. Man sieht auch in der Firma am BLF, ob der Mitarbeiter gerade verfügbar (=eingebucht, nicht telefonierend) ist, oder eben nicht. Für denjenigen, der in der Zentrale den Ruf annimmt, macht es also keinen Unterschied, ob der Mitarbeiter im Büro ist oder zu Hause - einfach per BLF-Rückfrage durchstellen, fertig. Passt.

Jetzt muss ich nur noch rauskriegen, ob ich die VPN's auf den Mobilgeräten trotz der Default-Weiterleitung an das USG irgendwie in ein "Paralleluniversums-VPN" in die Digibox direkt einbuchen kann (also auf deren eigene VPN-Ports). Denn ich will die Mitarbeiter-Handy's nicht im firmeninternen Netz haben, das USG-VPN fällt damit als Dauerlösung aus. Soweit ich weiss, sind VPN-Ports aber ziemlich strikt definiert bzw. nicht änderbar, muss also weiterforschen ...

/tom

 

[totalverrückteruser]

Erstens siehst Du oben in dem Ausschnitt des Logs eine Variante, VPN-Ports zu verbiegen.
Zweitens sollte Dein USG verschiedene VPN Profile beherrschen.
Leg ein separates VPN-Profil an, dessen Clients routest Du vom USG auf das interne LAN der Digibox und machst da dann eine Anmeldung aus dem lokalen Netzwerk (aus Digiboxsicht)

 

[Tom Bombadil]

Geht nach wie vor nicht, auch nicht mit Backroute auf die Digibox. Das USG war bis jetzt exposed Host, das habe ich heute geändert - mit dem Ergebnis, dass die DigiBox nach wie vor Registrierungsanfragen auf das USG forwarden will (Log ist von zu Hause - ich versuche, mich mit der SIP-App auf dem Handy direkt auf der Digibox anzumelden). Später eingestelltes Backrouting vom USG zur Digibox (natürlich vorher in der Digibox Port Forward eingestellt) hat auch nichts gebracht:

Nr.	Datum	Zeit	Level	Subsystem	Nachricht
4	17.11.2021	17:59:35	Debug	INET	destroy session, Handy_IP:22218->USG_IP:5060 prot: 6
5	17.11.2021	17:59:35	Debug	INET	TIMEOUT Session expired: Handy_IP:22218->USG_IP:5060 prot=6
6	17.11.2021	17:59:08	Debug	INET	NAT: delete session on ifc 30010001 prot 6 USG_IP:5060/DigiBox_IP:5060 <-> Handy_IP:22218
7	17.11.2021	17:59:05	Debug	INET	SIF: No Rule Ignore [30010001:Handy_IP:22218] -> [39000000:USG_IP:5060] :6
8	17.11.2021	17:59:05	Debug	INET	new session, Handy_IP:22218->USG_IP:5060 prot: 6 parent: false
9	17.11.2021	17:59:05	Debug	INET	NAT: new incoming session on ifc 30010001 prot 6 USG_IP:5060/DigiBox_IP:5060 <- Handy_IP:22218
10	17.11.2021	17:59:02	Debug	INET	NAT: delete session on ifc 30010001 prot 6 USG_IP:5060/DigiBox_IP:5060 <-> Handy_IP:22218
11	17.11.2021	17:58:59	Debug	INET	destroy session, Handy_IP:22218->USG_IP:5060 prot: 6
12	17.11.2021	17:58:59	Debug	INET	TIMEOUT Session expired: Handy_IP:22218->USG_IP:5060 prot=6
13	17.11.2021	17:58:46	Debug	INET	NAT: new incoming session on ifc 30010001 prot 6 USG_IP:5060/DigiBox_IP:5060 <- Handy_IP:22218
14	17.11.2021	17:58:43	Debug	INET	NAT: delete session on ifc 30010001 prot 6 USG_IP:5060/DigiBox_IP:5060 <-> Handy_IP:22218
15	17.11.2021	17:58:28	Debug	INET	SIF: No Rule Ignore [30010001:Handy_IP:22218] -> [39000000:USG_IP:5060] :6
16	17.11.2021	17:58:28	Debug	INET	new session, Handy_IP:22218->USG_IP:5060 prot: 6 parent: false
17	17.11.2021	17:58:28	Debug	INET	NAT: new incoming session on ifc 30010001 prot 6 USG_IP:5060/DigiBox_IP:5060 <- Handy_IP:22218

Das bringt mich zur eingangs gestellten Frage zurück - was muss ich machen, dass die Digibox von extern eingehende SIP-Requests akzeptiert.

So langsam hab ich aber auch keine Lust mehr, mit so einem Blödsinn meine Zeit zu vergeuden. Eigentlich wollte ich die Digibox nach dem 'Proof-of-concept' durch eine Originalversion mit Lizenzupgrade ersetzen, aber da ich das Versuchs-Setup nicht hinbekomme, gehen mir gegenüber der Geschäftsleitung die Argumente aus. Wir werden wohl einem der in der Warteschlange stehenden Online-Anbieter die Hand schütteln (Starface & Co, seid gegrüßt - Digibox/bintec adé) ...

/tom

 

[chrsto]

Was du wissen willst, wird in diesem Video erklärt:

be.IP - Fernzugriff über das Internet - helpcenter.bintec-elmeg.com

 

[Tom Bombadil]

Nein, wird es nicht.
Betrachtet das Thema als erledigt (nicht gelöst) - danke an alle, die geholfen haben.
/tom

 

[totalverrückteruser]

No rule - ignore
Das deutet auf ein "nicht vertrauenswürdig" Statement bei fehlender Firewall-Regel hin. Natürlich für die jeweilige Schnittstelle.
Der schnelle Test vor dem Design der passenden Regel ist das "vertrauenswürdig" Status der Schnittstelle.

So langsam hab ich aber auch keine Lust mehr, mit so einem Blödsinn meine Zeit zu vergeuden. Eigentlich wollte ich die Digibox nach dem 'Proof-of-concept' durch eine Originalversion mit Lizenzupgrade ersetzen, aber da ich das Versuchs-Setup nicht hinbekomme, gehen mir gegenüber der Geschäftsleitung die Argumente aus.

Dafür gibt es im Zweifel externe Dienstleister, die damit ihr Geld verdienen.

Starface & Co, seid gegrüßt - Digibox/bintec adé

Die Bankrotterklärung des Lokaladmins

 

[Tom Bombadil]

Das deutet auf ein "nicht vertrauenswürdig" Statement bei fehlender Firewall-Regel hin. Natürlich für die jeweilige Schnittstelle.

Wenn Du aufmerksam gelesen hast, weißt Du ja, dass ich oben genau danach gefragt habe. Aber man kann konkrete Fragen natürlich auch 'schwammig' beantworten, jeder wie er will.

Dafür gibt es im Zweifel externe Dienstleister, die damit ihr Geld verdienen.

Davon hatten wir 2 in den letzten 10 Jahren - wahrscheinlich genau die beiden ahnungslosen, die da draußen rumlaufen.
Alles, was 'überhaupt gar nicht geht', lief, nachdem ich selbst mit einem wirklich kompetenten T-Servicemitarbeiter direkt in Bonn telefonieren konnte.
Aber keine Sorge, wir haben ja jetzt wieder an einen externen Dienstleister, der damit sein Geld verdient.

Die Bankrotterklärung des Lokaladmins

Ja. Eine meiner ersten seit 1985 (seitdem mache ich IT mache, Elektronik entwickle und unser Netz neben denen einiger anderer befreundeter Firmen hobbymäßig 'nebenbei' betreue).
Ist aber nicht schlimm - nachdem wir schon in zweistelliger Zahl unsere Mobilverträge bei den Postbeamten gekündigt haben, fallen jetzt noch die 3 letzten Festnetzanschlüsse (2x Inet, 1x Telefonie).
Zum Glück hat der Kabelanbieter gerade auf GBit aufgestockt, da stimmt dann die Bandbreite wieder (T-Glasfaser liegt seit 8 Jahren fertig im Keller, aber die kriegen das einfach nicht aufgeschaltet).

Wie immer bei der Post ist es an gefühlten Lappalien gescheitert ...

/tom