Joerg Posted November 24, 2015 #1 Share Posted November 24, 2015 Guten Tag Zusammen, wir nutzen die aktuellste Serverversion 2015 R3.1 und ich habe auf einem separaten Server den Swyx RemoteConnect Dienst ausgelagert. Wenn ich mit einem Windows SwyxIt! mich von extern verbinde, funktioniert alles einwandfrei. Nun habe ich aus dem AppStore die aktuelle Swyx App installiert und auch die gleichen Daten eingegeben, welche auch in der SwyxIt! Windows Version benötigt werden. In der Firewall sehe ich auch, dass die Verbindung korrekt geroutet wird. Und unter Windows funktioniert es ja auch einwandfrei. Bloß in der OSX Version kommt keine Verbindung über extern zustande. Wenn ich im gleichen Netz bin, ist alles in Ordnung! Hat da jemand schon Erfahrungen mit gemacht? Viele Grüße, Jörg Link to comment Share on other sites More sharing options...
Most Valued User SvenS Posted November 24, 2015 Most Valued User #2 Share Posted November 24, 2015 Hast du das Zertifikat akzeptiert ? Link to comment Share on other sites More sharing options...
Joerg Posted November 24, 2015 Author #3 Share Posted November 24, 2015 Hallo Sven, ja die Zertifikatsabfrage ist gekommen und ich habe diese auch bestätigt. Wie gesagt, sehe ich auch in der Firewall das er sich versucht zu connecten. Müsste im IpPbxSrv Log der Login versuch stehen, oder sollte ich auf dem abgesetzen Gateway schauen? Gruß, Link to comment Share on other sites More sharing options...
Joerg Posted November 24, 2015 Author #4 Share Posted November 24, 2015 Hier noch eine Ergänzung: Wenn ich mich mit einem Windows SwyxIt! Client verbinde, funktioniert dies einwandfrei. In der Firewall sehe ich wie der Client sich über Port 16203 verbindet. Wenn ich nun dies mit dem Mac Client mache, ist die erste Anfrage über Port 9101, nach Dokumentation ist dies auch die Authentifizierungsverbindung. Jemand noch eine Idee? Wer hat das denn schon erfolgreich getestet? Gruß, Link to comment Share on other sites More sharing options...
Most Valued User SvenS Posted November 25, 2015 Most Valued User #5 Share Posted November 25, 2015 Wirklich helfen kann ich dir nicht. Bei mir funktioniert es, allerdings auch erst nach einigen Versuchen und zwischenzeitlichem löschen (Komplett mit Hilfe des Tools AppCleaner 2) des SwyxIt Clients und des Zertifikats. Nachdem ich dann alles neuinstalliert hatte und die externe Adresse ohne Portangabe eingetragen hatte funktionierte es. Bei mir ist der Dienst allerdings auch nicht ausgelagert. Im Zweifel mal in den Logs schauen IpPbxsrv und ich glaube IpPbxConnectSrv ist für den RemoteConnector. Link to comment Share on other sites More sharing options...
Joerg Posted November 25, 2015 Author #6 Share Posted November 25, 2015 Hallo Sven, danke für deine Rückmeldung. Ich habe auch schon mit dem Programm AppCleaner alles rausgeschmissen. Das Zertifikat wird auch dann wieder erneut angefragt. Sehr komisch, unter Windows macht er alles tadellos. In den Logs sehe ich leider gar keine Informationen bzgl. der Verbindungsversuchen. Noch in dem IpPbxsrv noch IpPbxConnectSrv. Ich denke ich muss das mal hier auf dem Client suchen... Wer sonst noch eine Info hat, bitte gerne her damit ;-) Link to comment Share on other sites More sharing options...
Most Valued User Virikas Posted November 27, 2015 Most Valued User #7 Share Posted November 27, 2015 Der Windows Client verhält sich hier auch anders als z.B. der Beta IOS Client (der tendenziell dem MAC Client sehr ähnlich sein dürfte). Ersterer verbindet sich auch dann sauber, wenn nur Port 16203 genattet wird, letzterer nur wenn auch der Auth Port 9101 genattet wird. Die Doku ist hier leider seeeeehr unpräzise Link to comment Share on other sites More sharing options...
Joerg Posted December 15, 2015 Author #8 Share Posted December 15, 2015 Danke für die Info. Habe nun den mac Client und den IOS Client, jedoch verbinden sich beide Geräte nicht über SwyxRC. Ich sehe nur in der Firewall, dass 9101 und 16203 weitergeleitet werden. Interessant ist jedoch, dass ich auf dem IOS Gerät im Protokoll lesen kann, dass er ein Problem hat dass er keine sichere Verbindung über SSL aufbauen kann. Hm... Komisch selbst unsere russischen Mitarbeiter können mit einem Windows Rechner Swyx via SwyxRC nutzen. Nur OSX bzw. IOS zickt herum.... 015/12/15 15:20:55 [Info] [pipeToLog] [:0] stdout > CloudConnectorWrapper: Stopping... 2015/12/15 15:20:55 [Error] [main] [SupervisorManager.swift:111] supervisorErrorHandler > Supervisor failed to start: Error Domain=DefaultSupervisor Code=2 "(null)" UserInfo={FailedService=CloudConnector, NSUnderlyingError=0x15dd9a0b0 {Error Domain=NSURLErrorDomain Code=-1200 "Es ist ein SSL-Fehler aufgetreten. Eine sichere Verbindung zum Server kann nicht hergestellt werden." UserInfo={_kCFStreamErrorCodeKey=-9806, NSLocalizedRecoverySuggestion=Möchten Sie die Verbindung zum Server trotzdem herstellen?, NSUnderlyingError=0x15f213e20 {Error Domain=kCFErrorDomainCFNetwork Code=-1200 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, _kCFNetworkCFStreamSSLErrorOriginalValue=-9806, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9806}}, NSLocalizedDescription=Es ist ein SSL-Fehler aufgetreten. Eine sichere Verbindung zum Server kann nicht hergestellt werden., NSErrorFailingURLKey=https://XXXXXXXXX:9101//ippbx/client/v1.0/login/acquiretoken, NSErrorFailingURLStringKey=https://XXXXXXXXX:9101//ippbx/client/v1.0/login/acquiretoken, _kCFStreamErrorDomainKey=3}}} 2015/12/15 15:20:55 [Debug] [main] [DefaultSupervisor.swift:320] startNextConfiguration() > Configuration swyxWarePublicHostName failed to start. Start next configuration 2015/12/15 15:20:55 [Debug] [main] [DefaultSupervisor.swift:187] stopConfiguration() > Stopping service ChangePasswordService... 2015/12/15 15:20:55 [Debug] [main] [DefaultSupervisor.swift:190] stopConfiguration() > Service ChangePasswordService stopped. 2015/12/15 15:20:55 [Debug] [main] [DefaultSupervisor.swift:197] stopConfiguration() > Configuration swyxWarePublicHostName successfully stopped. 2015/12/15 15:20:55 [Debug] [main] [DefaultSupervisor.swift:333] startNextConfiguration() > All configurations failed. 2015/12/15 15:20:55 [Error] [main] [SupervisorManager.swift:111] supervisorErrorHandler > Supervisor failed to start: Error Domain=DefaultSupervisor Code=1 "(null)" 2015/12/15 15:20:55 [Debug] [main] [SupervisorManager.swift:133] supervisorErrorHandler > Max retries reached -> ask user to retry 2015/12/15 15:20:56 [Info] [pipeToLog] [:0] stdout > 2015-12-15 15:20:56.172 Swyx-Mobile[2504:936687] PromiseKit: Unhandled Error: Error Domain=com.swyx.Swyx-Desktop Code=4000 "CallManager not running. No internet connection?" UserInfo={NSLocalizedDescription=CallManager not running. No internet connection?} Link to comment Share on other sites More sharing options...
Joerg Posted December 22, 2015 Author #9 Share Posted December 22, 2015 Guten Tag Community, ich kann mich nun mit dem Mac OSX Client und dem IOS Client verbinden ;-) Ich habe das Problem "gelöst", indem ich den Authentifizierungsdienst (Port 9101) bzw. das NAT nicht auf den SwyxRemoteConnector weiter geleitet habe, sondern direkt zum Swyx-Server. Ist das so vorgesehen, oder kann man auch den Authentifizierungsdienst auslagern?! Viele Grüße, Link to comment Share on other sites More sharing options...
LarsS Posted April 2, 2016 #10 Share Posted April 2, 2016 On 21. Dezember 2015 at 8:57 AM, Joerg said: Guten Tag Community, ich kann mich nun mit dem Mac OSX Client und dem IOS Client verbinden ;-) Ich habe das Problem "gelöst", indem ich den Authentifizierungsdienst (Port 9101) bzw. das NAT nicht auf den SwyxRemoteConnector weiter geleitet habe, sondern direkt zum Swyx-Server. Ist das so vorgesehen, oder kann man auch den Authentifizierungsdienst auslagern?! Viele Grüße, Das würde mich auch interessieren. Denn bei uns im Unternehmen scheitert die Einführung der SwyxRemoteConnection im Moment daran, dass man einen direkte Verbindung vom Internet zum Swyx Server freigeben muss. Es würde ein go geben wenn man die SwyxRemoteConnection und den Authentifizierungsdienst in die DMZ auslagern könnte. Ist das so möglich und wenn ja wie ? Danke und Gruß Link to comment Share on other sites More sharing options...
Most Valued User srom Posted April 2, 2016 Most Valued User #11 Share Posted April 2, 2016 Da ich das auch realisieren wollte, wurde mir gesagt das dies nicht geht. Auth ist immer über den Swyx Server Link to comment Share on other sites More sharing options...
LarsS Posted April 5, 2016 #12 Share Posted April 5, 2016 danke für die Info ... Link to comment Share on other sites More sharing options...
Most Valued User Pete Posted April 5, 2016 Most Valued User #13 Share Posted April 5, 2016 Wir haben es so realisiert, daß wir erst eine VPN Verbindung aufbauen und dann die Swyx Mobile App starten - geht prima. Vielleicht ist das ja auch ein Ansatz für Euch? Sorry nicht genau genug gelesen. Ich dachte, daß es um die Mobile App geht. Link to comment Share on other sites More sharing options...
Most Valued User Virikas Posted April 6, 2016 Most Valued User #14 Share Posted April 6, 2016 Einfach mal so in den Raum gemutmasst ohne das getestet zu haben: Die Verbindung zum Auth Service ist AFAIK eine Standard HTTPS Verbindung. Wenn dem so ist, dann könnte man natürlich einfach einen Reverseproxy davor setzen. Damit das Zertifikattechnisch passt, müsste man dem Reverseproxy natürlich das Zertifikat des Auth unterjubeln. Also erstmal mit netsh show sslcert rausfinden, welches da verwendet wird: C:\>netsh http show sslcert SSL Certificate bindings: ------------------------- IP:port : 0.0.0.0:9100 Certificate Hash : <HASH> Application ID : {ccd69edc-a2bc-4a64-84fd-537cef49c424} Certificate Store Name : (null) Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled IP:port : 0.0.0.0:9101 Certificate Hash : <HASH> Application ID : {c401a165-87da-4c96-b28e-6fe1aab50e76} Certificate Store Name : (null) Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled Danach die MMC starten und das Certificate Snapin für "Computer Account" hinzufügen. Unter Eigene Zertifikate sollte nun ein Zertifikat mit dem FQDN des Swyxservers liegen, dessen Thumbprint mit dem oben herausgefunden Hash korreliert. Der Rest ist dann easy going.. Zertifikat exportieren (mit Private Key logischerweise) und dem Reverse Proxy hinzufügen. Prinzipiell sollte das so funktionieren, ich habe es aber nie getestet. Selbstredend handelt es sich dabei auch nicht um einen offiziell supporteten oder empfohlenen Weg Link to comment Share on other sites More sharing options...
Ole86 Posted April 10, 2018 #15 Share Posted April 10, 2018 Hi zusammen, ich versuche ebenfalls den Swyx Client auf MacOS zu betreiben. Dieses funktioniert dezeit ein wenig eingeschränkt. Ich kann Anrufe tätigen und habe vollen Zugriff auf das Telefonbuch etc.. Allerdings brechen zum einen die Anrufe nach 1-2 Minuten ab, zum anderen kann ich eingehende Anrufe nicht über die App entgegen nehmen, da diese nicht angezeigt werden. Erst nach dem Beenden des Gesprächs oder wenn der eingehende Anrufer auflegt, sehe ich den Anruf unter "Ereignisse". Hat da jemand eine Idee? Muss ich evtl. in den Systemeinstellungen noch etwas freigeben? Bin für jede Idee dankbar. Besten Gruß, Ole Brüns. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.