OSBiz-X myportal@work VPN Homeoffice

[Unify-TK]

Hallo Zusammen,

wir haben ein Problem mit myportal@work für unsere Homeoffice User.

Problem: ausgehende Anrufe über myportal@work über VPN -> keine Sprachübertragung beidseitig
Nimmt man nach dem klingeln ab, ist es auf beiden Seiten still. Die Verbindung wird dann nach einer Zeit automatisch abgebaut.

Setup VPN:
HomeOffice User über VPN (IPSec IKEV2 Watchguard mit Standart Windows VPN Client) mit LAN verbunden.
Erhalten die IP: 192.168.114.x

HomeOffice User können sich über myportal@work auf dem UC Server anmelden. (192.168.254.11:8802)
Die WAN Adresse im myportal Client wird nach der Beschreibung nicht benötigt. Was nachvollziehbar ist, da man über VPN auf die Anlage zugreift.
VoIP ist im myportal@work aktiviert. Per Ping ist das Netzwerk der Telefonanlage erreichbar.

Setup Unify Telefonanlage (OSBiz-X) Mainboard
LAN 1 (WAN) wird nicht verwendet
LAN 2 IP:192.168.254.10/24 Gateway:192.168.254.250 (Watchguard Router)
LAN 3 (Admin) IP: 192.168.252.5/24

Setup Unify Telefonanlage (OSBiz-X) Application Board
LAN 2 IP: 192.168.254.11/24

Soweit zu der Konfiguration.

Als erstes möchte ich eine Problematik mit der Firewall ausschließen. Hier wurde zum Test der gesamte Datenverkehr von in- und extern freigegeben. Dies brachte keine Änderungen. Ein SIP ALG ist nicht im Einsatz.
Die Signalisierung funktioniert problemlos für kommende und gehende Anrufe. Sprachübertragung klappt ebenfalls problemlos, wenn die User im HomeOffice angerufen werden.

Protokoll-Dumps von gehenden und kommenden Anrufen habe ich von der Telefonanlage und den HomeOffice Usern (auf dem Laptop per Wireshark) bereits gespeichert.

Dump von der Telefonanlage (Gespräch zum VPN)





Dump vom Laptop (HomeOffice) (Gespräch zum VPN)


Ab Zeile 188 werden die Audiodaten übertragen. Hier seht man die Verbindung zwischen der Telefonanlage 192.168.254.10 und dem VPN Teilnehmer 192.168.114.5.

Dump von der Telefonanlage (Gespräch vom VPN)





Dump vom Laptop (HomeOffice) (Gespräch vom VPN)



[Edit Novize: Riesenbilder gemäß der Forumsregeln auf Vorschau verkleinert]

Hier scheint etwas nicht zu stimmen, der myportal@work Client baut eine Verbindung zur IP 20.54.36.229 auf, ab Zeile 141 zu sehen. Müsste hier nicht die Verbindung zur Telefonanlage aufgebaut werden? Also zur 192.168.254.10? Hat das eventuell noch was mit dem STUN zu tun? In Zeile 145 ist noch unsere externe IP der Firma zu sehen in Verbindung mit STUN.

Wenn Jemand eine Idee hat was unter Umständen falsch konfiguriert ist, wäre ich dankbar.

 

[TECHNIKERMEYER]

Hallo,

das ist mal ein schönes Phänomen

Ist für diesen User Device@home eingerichtet worden? Erkennt man an der Einstellung "Internet-Registrierung..."


Steht denn überhaupt ein STUN Server bei den ITSPs drin?


Steht Device@home im Dashboard?



Können sich die jeweils anderen Gesprächspartner gegenseitig anpingen? (Für gewöhnlich findet Direct Payload statt und oft wird vergessen das IP-Routing entsprechend anzupassen - Also VPN1 User zu VPN2 User und umgekehrt).

Viele Grüße

 

[Unify-TK]

Vielen Dank für Ihren Hinweis. Nach Rücksprache kann ich folgende Aussagen geben.

- STUN steht beim ITSP drin
- die Home Office User sind im System als Deskshare User eingerichtet und lizensiert ( Rufnummer 7xxx )
- laut Service ( Komsa ) wurde eine MULAP / Team eingerichtet in der sich das Tischtelefon im Büro und der Deskshare User befinden
- Device ( Gerät )@home ist an diesen nicht eingerichtet / aktiviert ( soll eigentlich nur für Telefone sein, brauch nicht wenn nur VoiP aus dem Softwareclient genutzt wird )
zumindest habe ich es beim lesen der Dokus so verstanden
------------------------------------------------------------------------------------------
Auszug aus AdminDoku Seite 932
myPortal @work konfigurieren
Damit myPortal @work über das Internet auf das Kommunikationssystem zugreifen kann, müssen Sie Folgendes durchführen:
• STUN-Server für System/Client konfigurieren
• Port 8802 öffnen und weiterleiten (andere Weiterleitungen sind ungültig)
• Das SBC-Flag wird nicht benötigt. Es ist keine Authentifizierung erforderlich.

 

[LastRaven]

Der Auszug aus der Doku ist für deinen Fall uninteressant, da myPortal(at)work ja aus dem internen Netz (VPN) und nicht aus dem Internet kommt. (dein fett markierter Teil ist für myportal(at)work grundsätzlich egal, da der sich gegenüber der UC authentifiziert und nicht gegenüber dem Teilnehmerprofil.)

Ist das mit dem fehlenden Payload nur bei extern gehend oder auch bei internen Teilnehmern?

Wenn das nur bei extern gehend auftritt sollte das Flag "immer DSP benutzen" in der Richtung zu deinem Provider helfen.

 

[Unify-TK]

Auch bei gehenden Anrufen vom VPN ins interne Telefonnetz, fehlt der Payload.

Haben den STUN Server am myportal Client genau wie in der Telefonanlage eingestellt. (stun.t-online.de:3478)

 

[Unify-TK]

Hallo Zusammen,

vielleicht würde es uns weiterbringen, zu verstehen wie der Kommunikationsablauf vom HomeOffice aus ablaufen müsste?!
Die Signalisierung und die Sprachdaten müssten doch ausschleißlich über die Telefonanlage laufen?, also zur 192.168.254.10.
Warum wird aber , wie auf dem letzten Screenshot zu sehen Zeile 141, eine externe Adresse "angewählt? 20.54.36.229.

Mit freundlichem Gruß

 

[xsatze]

Klick mal im @work Client auf NAT Typ prüfen.
Was wird da angezeigt?

 

[Unify-TK]

NAT Typ Normal. VoIP Funktionalität kann ohne Einschränkungen genutzt werden.

 

[xsatze]

Aktivier mal testweise in den erweiterten ITSP Einstellungen SDP Filter=Compatibility profile
und ruf dann ins Amt.

 

[Unify-TK]

Habe ich ausprobiert, bleibt beim selben Effekt. Keine Übertragung der Sprache, die Verbindung wird nach einer gewissen Zeit automatischabgebaut.

 

[xsatze]

Etwas müssig nur anhand von Screenshots...
Bekommt man am @work PC überhaupt einen STUN Response?
Im Screenshot Dump vom Laptop (HomeOffice) (Gespräch vom VPN) sehe ich nur Requests.

 

[Unify-TK]

Hallo Zusammen,
nur anhand von den Bildern ist es sicher nicht unbedingt einfach, der Sache auf den Grund zu gehen. Von derher wäre es gut zu verstehen wie der allgemeine Verbindungsaufbau zustande kommt?!
Vielleicht hat einer von Euch eine funktionierende Konfiguration und könnte ein Paketmittschnitt hier einstellen um vergleichen zu können?

Habe hier mal nach STUN sortiert. Zwischen dem Request und dem Response liegen 10 Sekunden. Die IP 217.xxx.xxx.xxx ist wieder unsere öffentliche IP.

 

[xsatze]

Ist der Screenshot von einem Anruf?

Wenn du einen Anruf vom @work zur Osbiz tätigst sollte zwischen PC und Osbiz
ein STUN Request und Response zu sehen sein, inkl der IP von PC und Osbiz sowie der Ports die danach für die Sprache
verwendet werden.

Funktioniert bei mir so einwandfrei via VPN.

 

[Unify-TK]

Ja der Screenshot ist von einem Anruf.
Der STUN Request und Response findet nicht zwischen dem Laptop und der Osbiz statt, das ist zu erkennen.
Der Request wird vom Laptop gestellt es kommt aber keine Antwort vom Osbiz zurück auf (Port 30524)...

In kommenden Anrufen hingegen ist der STUN Request und Response zwischen Laptop und der Obiz zu erkennen(Port 30526) . Zusätzlich aber auch ein Binding zwischen Laptop und einer anderen externen IP Adresse (Port 3478)?

[Edit Novize: Beiträge zusammengeführt - siehe Forumsregeln]

So jetzt klappt es so wie es soll!
Danke für den Support.
Lösung: Den STUN Server von der Telefonanlage in den myportal@work Client einragen, in unserem Fall 192.168.254.10.

Muss mich korrigieren, *heul*

Geht doch nicht, war nämlich nicht über VPN Verbunden, sondern über interns WLAN.

 

[elvis65]

Hallo zusammen,

haben bei uns eine ähnliche Konstellation wie @Unify-TK Lancom, WatchguardT55, SSL-Client, FX5 V3_R2.1.1_018, @work 3.6.6

Wir haben es über die öffentliche IP lösen müssen da über die VPN es nicht funktionierte (Support Firewall/Telefonanlage liegt bei der Telekom). Es wurde am Ende die Firewall komplett für die Anlage geöffnet und es funktionierte auch nicht, ist allerdings auch schon vor ca. einem Jahr gewesen.

Habe es aktuell mal wieder mit einem HotSpot über die Telekom getestet.

Anrufsignalisierung ist jeweils gegeben auf beiden Seiten

Anruf von extern kommend beide Parteien können reden.
Anruf gehend extern beide Parteien hören sich nicht.
Anruf von intern über Systemtelefon/SIP beide Parteien können reden.
Anruf gehend intern zu Systemtelefon/SIP hören sich nicht.
Anruf intern unter @work-Teilnehmer bei Parteien können reden.

Wenn ich es richtig verstanden habe ist es ein Problem mit dem Payload.

Der SIP-Client (Phonerlite) funktioniert einwandfrei über den HotSpot.

Ob die V3R3 Besserung bringt bezweifle ich wenn man die Entwicklung/Bugs des @work-Client sieht, wäre aber positiv überrascht.

Gruß elvis

 

[Unify-TK]

Vielen Dank für deinen Beitrag elvis65.

Wir sind noch nicht weiter gekommen mit der Thematik. Jedoch gut zu hören, dass wir scheinbar nicht die einzigsten mit dem Problem sind.
VPN wäre bei uns schon zwingend erforderlich, um produktiv aus dem HomeOffice arbeiten zu können.
Wenn es mit der öffentichen IP Adresse möglich wäre, müsste man über Split Tunneling nachdenken...

 

[LastRaven]

mir ist da grad noch was aufgefallen:

Haben den STUN Server am myportal Client genau wie in der Telefonanlage eingestellt. (stun.t-online.de:3478)

warum? Die Verbindung vom Homeoffice via VPN zur OSBiz ist durchgehend intern. Wozu braucht man da am Client einen STUN-Eintrag?

 

[Unify-TK]

Hallo LastRaven,

beim ergründen des Problems wird halt auch mal das probiert .

Habe jetzt ohne VPN Tunnel mich mit der Anlage verbunden. Klappt soweit. Signalisierung in beide Richtungen in Ordnung, was fehlt ist der Payload.

@elvis65 Phonerlite wäre zum testen eine Alternative.
Welche Ports müssten zur Telefonanlage geleitet werden? (Neben 5060?)
Beim Proxy/Registrar gebe ich unsere öffentliche IP ein? STUN Server "stun.t-online.de"
Leider registiert sich Phonerlite nicht. Benutzer und Kennwort habe ich vom myportal@work Client übernommen.

 

[elvis65]

Hallo @Unify-TK ,

Phonerlite erfordert einen SIP-Client mit den @work-Clients geht es leider nicht, die müssen auf der Anlage unter Teilnehmer unter den IP-Clients als SIP-Client angelegt werden und dann anschließend als Team zusammengeführt werden. Im Grunde doppelte Nutzer aber ich habe leider keine andere Lösung.

Wenn nur über VPN dann die obige Konstellation und wenn ohne VPN dann muss eine öffentliche IP rein. Keine schöne Lösung, leider.

Phonerlite läuft - für uns zumindest - eigentlich relativ gut. Vor allem wenn man nur telefonieren möchte und das auch über einen mobilen HotSpot da ist der @work-Client komplett raus.

Bei den @work-Clients habe ich dann beim Anmeldefenster auch eine zweite Anmeldung machen müssen. Anmeldung 1 für die interne Anmeldung oder VPN (wenn dies funktionieren würde) und Anmeldung 2 mit der öffentlichen IP, in einer gemeinsamen Anmeldung hat es bei uns zumindest nicht funktioniert.

Ich denke wir können noch soviel probieren solange Unify an das nicht bereinigt wird es nicht funktionieren und das Problem besteht schon seit es die Anwendung gibt und anscheinend wird momentan die Unfiy X bevorzugt behandelt. Wenn der @work-Client intern genutzt wird funktioniert er eigentlich relativ gut für extern (sagt auch der Support) ist er meiner Meinung nach nicht zu empfehlen.

Zum einen bis er läuft sind zwei, drei Gespräche erforderlich (solange die "Köpfe" im Protokoll nicht erscheinen funktioniert dieser nicht bzw. sehr versetzt), die Statusaktualisierung in der Favoritenliste funktioniert auch recht bescheiden (intern/extern), und vor allem es muss der Zugang über eine öffentliche IP gemacht werden.

 

[Unify-TK]

Vielen Dank für die Antwort.

Werden uns dann mal diese SIP User in der Anlage einrichten lassen und sehen, ob es in Verbindung mit PhonerLite eine Lösung für uns darstellt.

Mit freundlichem Gruß

....

Update

Hallo hier ein Update zum Problem.

Wir haben nun mit PhonerLite den SIP Client am laufen. Im internen Netz läuft es genauso unproblematisch wie mit dem myportal client.
Über VPN ist die Signalisierung wie immer ok, die Sprache wird aber nur einseitig übertragen. In unserem Fall vom Handy zum SIP Client.
Die gleiche Problematik besteht bei Anrufen vom Homeoffice ins interne Telefonnetz.

Sind bislang also noch nicht entscheidend weiter gekommen.

Hier dazu der SIP Flow





Gerade noch etwas mit Wireshark gesehen.
Ich kann meine Tonspur (im HomeOffice am Laptop) in Wireshark hören, sie bricht aber in diesem Falle nach 4,84 Sekunden einfach ab. Beim nächsten Versuch bricht die Tonspur nach 4,86 Sekunden ab.
Diese Tonspur die ich höre kommt jedoch nicht am Telefon in der Firma an...



Erfolgt der Anruf vom internen Netz ins HomeOffice (VPN) ist die Kommunikation beidseitig in Ordnung.

Habe mit Wireshark nochmal den Datenverkehr ausgewertet.

Dabei ist mir folgendes aufgefallen.



Bild 1. Kommunikationaufbau vom internen Telefonnetz zum VPN Ziel und Quellport sind bei den Verbindungen indentisch. 29100 und 5066



Bild 2. Kommunikationsaufbau vom VPN zum internen Telefonnetz Ziel und Quellport sind bei den Verbindungen unterschiedlich. 29100/ 5070 und 29100/2885

Hier stimmt meines erachtens was mit der Portabstimmung nicht. Daher ist klar das man eine Seite nicht hört…

Habe die Anrufe jeweils mit dem PhonerLite Client gemacht.


Lösung gefunden.

In der Firewall Policy war noch NAT gesetzt. Habe für den Datenverkehr zum VPN eine neue Policy hinzugefügt welche NAT deaktiviert hat, seitdem läuft es mit PhonerLite und myportal@work.

Hoffe das hilft den ein oder anderen beim Fehler suchen.