aktuell versuche ich über einen VOIP-Softclient, welcher über VPN an das Netzwerk und damit an die Telefonanlage angebunden ist, Gespräche entgegenzunehmen oder zu führen, leider ohne Erfolg. Obwohl die VPN-Strecke einwandfrei arbeitet, die Einwahl (Registrierung) des Clients an der Telefon ganz ohne Probleme von statten geht und sogar die Anrufe richtig signalisiert bzw. iniziiert werden, kann man bei zustandekommen der Verbindung die Gegenseite nicht hören und man selber wird auch nicht gehört. Meine Vermutung geht dahin, dass es Schwierigkeiten bei der Umsetzung der RTP-Ports in Bezug auf die NAT-Firewall kommt aber wer weiß das schon so genau
Hier mal ein paar Daten
Softclient: Bria 3, Counterpath
VPN-Router: D-Link 804hv
VPN-Strecke: IPsec via Client aus entferntem Netzwerk
Telefonanlage: 5010 Voip oder wahlweise 3000 Voip
Im lokalen Netz funktioniert der Softclient ivm. den beiden Anlagen einwandfrei und, wie oben bereits erwähnt, klappt selbst die Registierung der/des Accounts über die VPN-Verbindung ohne weitere Probleme. Lediglich der Ton fehlt, wenn eine Gespräch begonnen wurde. Leider haben die Auerswald-Beschreibungen zu diesem Thema nicht weitergeholfen…
[quote=dietschei]Hallo zusammen,
…
Im lokalen Netz funktioniert der Softclient ivm. den beiden Anlagen einwandfrei und, wie oben bereits erwähnt, klappt selbst die Registierung der/des Accounts über die VPN-Verbindung ohne weitere Probleme. Lediglich der Ton fehlt, wenn eine Gespräch begonnen wurde. Leider haben die Auerswald-Beschreibungen zu diesem Thema nicht weitergeholfen…
[/quote]
Ich nutze Phonerlite http://www.phonerlite.de/index_de.htm der funktioniert prima über VPN. Das die Registrierung funktioniert aber kein Ton kommt klingt seltsam, ich würde auch auf ein Firewall Problem tippen? NAT sollte eigentlich kein Problem sein, wenn Du über VPN eine IP-Adresse aus dem gleichen Netzwerk erhältst wie die Telefonanlage.
hast Du evtl. unter
Administration->Server-Konfiguration->STUN-Server für Anbindung außen liegender VoIP-Teilnehmer
einen STUN-Server eingetragen und aktiviert? Wenn dem so ist, dann findet Deine Anlage und Dein Telefon jeweils die öffentliche IP des (DSL-)Anschlusses heraus und versucht die RTP-Pakete direkt dorthin zu schicken - blöderweise sollen die aber DURCH den VPN-Tunnel.
Ist nur eine Vermutung, aber trotzdem ein gern gemachter Fehler
Den STUN-Server an dieser Stelle benötigt man nur, wenn man eine abgesetzte Nebenstelle ohne VPN betreibt.
danke für die Antworten. @Dauerbesetzt: An dem STUN-Server liegt es leider nicht. War mir diesem potenziellen Fallstrick bewusst aber da mir diese Methode ohnehin etwas offenherzig erscheint, habe ich mich für die VPN-Verbindung entschieden…
Kennen und haben ja, viel Benutzt bzw. so richtig damit auskennen nein. Denke aber das es im Rahmen des Machbaren liegt sich da reinzufrickeln. Mal schauen… Wenn jemanden in der Zwischenzeit noch was einfällt einfach schreiben.
Beinahe richtig, der Router ist gleichzeitig VPN Host.
TK -> VPN-Router->Internet<-beliebiges Netzwerk<-VPNClient mit Softphone. Neben der routereigenen Firewall ist auf dem Client noch Norton installiert, dass war es eigentlich (Ist der etwas einfachere Testfall, wo die 3000 voip angebunden ist)
Bei der 5010 sieht es so aus: TK-> VPN Router->LoadBalancingRouter->2x Internet <- beliebiges Netzwerk<-VPNClient mit Softphone.
Nur kurz, OutboundProxy an welcher Stelle eintragen?
Da die zurückliegenden Tage etwas stressig waren, bin ich erst jetzt wieder dazu gekommen mich dem Thema zu widmen. Folgendes konnte ich zwischenzeitig testen:
1.) Im Softphone (Bria 3) habe ich die Telefonanlage als Proxy eingetragen, leider ohne Erfolg.
2.) Installation von Wireshark und Überwachung der Kommunikation des Clients mit der Telefonanlage über den VPN Host. Zur näheren Erläuterung hier noch einmal die Netzbereiche, in denen ich mich bewege: Lokales Netz (Client) 192.168.3., VPN-Server (Client-IP im entfernten Netz) 192.168.254., Entferntes Netz: 192.168.0.. Obwohl die Kommunikation - zuerst TCP, ab Beginn des Klingelns RTP - einwandfrei adressiert ist (Kommunikation 254. <-> 0.*) gibt es doch zwei Zeilen die mir nicht so recht gefallen. Bevor ich näher auf diese eingehe sei vorab gesagt, dass nach der Abnahme des Hörers kein signifikanter Unterschied - im Vergleich zum Klingeln - im Protokollverkehr festzustellen ist (RTP).
Zeile 1: Kommunikation: Telefonanlage -> Client, Protokoll: ICMP, Info: Destination unreachable (Port unreachable)
//** Ausgabe erfolgt alle 50 Zeilen ein mal, Fehlergrund: Die Telefonanlage Adressiert das Paket an die Lokale IP des Clients (3.) nicht aber wie den anderen Verkehr an die VPN-IP (254.)**//
Zeile 2: Kommunikation: Client -> Telefonanlage, Protokoll: TCP, Info: 50343 (vermutlich der Port) afs-3.callback [PSH-ACK]…
//** Diese Zeile wird Blockweise (ca. 10 mal hintereinander) alle 100 - 200 Zeilen ausgegeben **//
Zwischen diesen Zeilen läuft eine reibungslose Übertragung auf RTP-Protokollbasis vom Client zur Telefonanlage ab.
Die Protokolle, sowohl das des Routers als auch der NIS-Firewall, zeigen nicht an, dass irgendetwas auf dem Weg hin oder zurück geblockt wird.
Weiß jemand einen Rat, warum es trotzdem nicht funktioniert?
[quote]Fehlergrund: Die Telefonanlage Adressiert das Paket an die Lokale IP des Clients (3.) nicht aber wie den anderen Verkehr an die VPN-IP (254.)**//[/quote]kann es evtl. sein, daß Du keine saubere Netz-zu-Netz-Kopplung zwischen Deinen zwei Netzwerken hast?
Das sieht mir so aus, als würde Dein Client-Netz NAT in das Hauptnetz machen. Sprich im Hauptnetz tauchen alle Anfragen aus dem Clientnetz als Anfragen vom VPN-Gateway auf.
Kannst Du denn aus dem Hauptnetz (also das, wo die Anlage steht) einen Ping auf ein Gerät im Clientnetz machen? In die andere Richtung scheint es ja zu gehen. Evtl. ist das ja der Grund.
In diesem Fall müsstest Du sowas wie ein Portforwarding im VPN-Tunnel einrichten - oder halt ein vollständig geroutetes Netz-zu-Netz-VPN ohne NAT dazwischen.
Was auch noch geht ist einen STUN-Server in das Netz der Anlage zu stellen. Dieser wird dann in das Telefon eingetragen. Damit ist es dem Telefon dann möglich die IP-Adresse herauszubekommen, mit der es im Netz der Anlage - nach dem NAT - zu sehen ist.
also der Ping geht. Ich kann auch aus dem Hauptnetz heraus auf das Notebook zugreifen, welches die Verbindung aufbaut.
Meine Vermutung, dass der Fehler der Zeile 1 an der falschen Adressierung liegt, scheint nicht ganz richtig zu sein. In diesem Zuge kann man glaube ich auch sagen, dass alle Anfragen des Clients nicht als solche des VPN-Gateways ausgewiesen werden, denn…
VPN-Gateway-Adresse: 192.168.254.1
Client-IP im VPN Netz: 192.168.254.2
Pingt man aus dem Hauptnetz die 254.2, dann kommt nichts an. Pingt man aber die Client IP des lokalen Netzes 192.168.3., dann geht sowohl der Ping durch als auch der Zugiff auf Dateien etc. Wahrscheinlich wird die Adressierung der RTP-Pakete in Wireshark mit der 192.168.254. ausgewiesen, weil er den rest nicht sehen kann (irgendwie so…). Fragt sich nur, warum dann die augenscheinlich richtige Adressierung (Zeile 1) nicht durch geht.
hmm… ich hab irgendwie immer noch kein klares Bild, wie Deine Topologie aussieht, welche IP wo sitzt, wer gegen wen routet und welche NIS-Firewall wo im Netz welche Logs in welcher Weise auf welche Ereignisse hin schreibt. Die größte Unsicherheit dürfte schon in den Begrifflichkeiten stecken, wer Client von welchem Master auf welcher Netzwerkebene ist.
Kurz: Das ist sicherlich ein spezielles Problem Deines VPN-Konstrukts und weniger eines der Telefon-/Anlagenkonstellation.
Mach Dir am besten erstmal die Topologie klar, die hier vorliegt und schaue im Wiresharkprotokoll nach wer wann welche Pakete mit welcher Ziel-/Empfängeradresse schicken müsste, und wohin er sie tatsächlich schickt…
Gruß Dauerbesetzt
PS: mitunter meinen einige “schlaue” Firewalls schon Angriffe zu erkennen, wenn per UDP unmengen RTP-Pakete in kurzer Zeit auf sie einregnen…
Ersteinmal mein herzlichen Dank an Dauerbesetzt, der sich noch eine Weile mit meinem Problem auseinandergesetzt und mir ein ganzes Stück weitergeholfen hat!
Nachdem wir alle Topologiefragen klären konnten, haben wir bei der Analyse der Paketdaten feststellen müssen, dass das Programm (Bria 3) den falschen Adapter und damit die falsche IP als Empfangsadresse im SDP angibt. Hier wird die Adresse des VPN-Tunneladapters angegeben und nicht - wie eigentlich nötig - die lokale Netzwerk-IP. Leider musste ich im Counterpath-Forum lesen, dass Bria keine manuelle Adapter- oder IP-Bindung forcieren kann. Bria bindet sich immer an den primären Netzwerkadapter. In den Einstellungen besteht die Möglichkeit einen Domänenproxy anzugeben oder die Topologieeinstellungen (STUN, TURN, lokale IP unter Angabe der Serveradresse) zu verändern, that’s it…
Abgesehen davon, dass es ein paar Mark gekostet hat, mag ich keine zwei Programme einsetzen. Hat von euch noch jemand eine Idee, wie man dem Problem Herr werden könnte? Rport-Abschaltung hat leider nichts gebracht. Macht vielleicht ein SIP-Proxy als kleines Zusatzprogramm Sinn?
gern geschehen
Nur als vlt. etwas kruden Workaround. Kannst Du Bria starten, bevor der VPN-Client gestartet wird? Wenn der VPN-Netzwerkadapter dann noch nicht existiert, sollte Bria ja das lokale Interface an sich reißen - hat somit gar keine Chance sich primär an das VPN zu binden. U.U. hilft das schon. Dass Bria den Adapter dann nach dem Start des VPN-Clients nochmal wechselt, würde ich eher nicht vermuten…
Leider haben die sich bei der Programmierung von der Software richtig Gedanken gemacht! Scheinbar ist es so, dass die Bindung erst dann erfolgt, wenn die Konten sich in der Anlage registrieren und das geht natürlich erst dann, wenn die VPN-Einwahl erfolgreich war… Die Antwort ist jedenfalls: Funktioniert nicht.
Scheinbar ist es so, dass die Bindung erst dann erfolgt, wenn die Konten sich in der Anlage registrieren und das geht natürlich erst dann, wenn die VPN-Einwahl erfolgreich war… Die Antwort ist jedenfalls: Funktioniert nicht.