11
Wie Voice-Pakete durchs VPN bekommen?
Hallo zusammen,
wir haben seit kurzem eine VPN-Telefonie im Einsatz von Swyx. Intern wird über eine Software auf dem Rechner miteinander kommuniziert, also Voice-over-IP. Wenn wir raustelefonieren läuft aber alles über ein physisches Gateway. Funktioniert auch alles soweit.
Nun soll es für Kollegen auch möglich sein, wenn Sie nicht im Büro sind damit zu telefonieren über VPN, aber hier scheitert es. Der Client der Software kann zwar eine Verbindung mit dem Voice-over-IP Server aufbauen und sogar jemanden anrufen, aber auf beiden Seiten hört man nichts, die Sprachpakete kommen nicht durch.
Die von Swyx konnten mir da nichts sagen, außer dass man die VPN-Einstellungen ändern müsste...
Für die VPN-Verbindung nutzen wir Windows Server 2003R2 64 Bit (Routing &RAS) mit folgenden Einstellungen:
PPTP
Allgemein:
Aktiviert als Router (LAN und bei Bedarf wählendes Routing
RAS-Server (aktiviert)
Sicherheit
Windows Authentifizierung
Authentifizierungsmethoden:
EAP
MS-CHAP v2
MS-CHAP
IP:
IP Routing (ist aktiviert)
IP-basierte RAS- und Verbindungen für Wählen bei Bedarf zulassen (ist aktiviert)
Broadcastnamensauflösung (ist aktiviert)
PPP:
Mehrfachverbindungen (aktiviert)
Dynamische Brandbreitensteuerung mit BAP oder BACP (ist aktiviert)
Link Control-Protokoll (LCP) Erweiterung (aktiviert)
Softwarekomprimierung (aktiviert)
Protokollierung:
Fehler und Warnungen
Jemand ne Idee was ich umstellen muss, damit die Voice Pakete durchkommen? Muss ich in der Firewall noch zusätzlich was freischalten??
wir haben seit kurzem eine VPN-Telefonie im Einsatz von Swyx. Intern wird über eine Software auf dem Rechner miteinander kommuniziert, also Voice-over-IP. Wenn wir raustelefonieren läuft aber alles über ein physisches Gateway. Funktioniert auch alles soweit.
Nun soll es für Kollegen auch möglich sein, wenn Sie nicht im Büro sind damit zu telefonieren über VPN, aber hier scheitert es. Der Client der Software kann zwar eine Verbindung mit dem Voice-over-IP Server aufbauen und sogar jemanden anrufen, aber auf beiden Seiten hört man nichts, die Sprachpakete kommen nicht durch.
Die von Swyx konnten mir da nichts sagen, außer dass man die VPN-Einstellungen ändern müsste...
Für die VPN-Verbindung nutzen wir Windows Server 2003R2 64 Bit (Routing &RAS) mit folgenden Einstellungen:
PPTP
Allgemein:
Aktiviert als Router (LAN und bei Bedarf wählendes Routing
RAS-Server (aktiviert)
Sicherheit
Windows Authentifizierung
Authentifizierungsmethoden:
EAP
MS-CHAP v2
MS-CHAP
IP:
IP Routing (ist aktiviert)
IP-basierte RAS- und Verbindungen für Wählen bei Bedarf zulassen (ist aktiviert)
Broadcastnamensauflösung (ist aktiviert)
PPP:
Mehrfachverbindungen (aktiviert)
Dynamische Brandbreitensteuerung mit BAP oder BACP (ist aktiviert)
Link Control-Protokoll (LCP) Erweiterung (aktiviert)
Softwarekomprimierung (aktiviert)
Protokollierung:
Fehler und Warnungen
Jemand ne Idee was ich umstellen muss, damit die Voice Pakete durchkommen? Muss ich in der Firewall noch zusätzlich was freischalten??
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 192524
Url: https://administrator.de/contentid/192524
Printed on: April 18, 2024 at 13:04 o'clock
11 Comments
Latest comment
Hi Andreas,
An der Firewall kann es kaum liegen, da der VPN mit einem einzelnen Port durchkommt und die Firwall nicht in die PPTP-VPN Pakete schauen kann.
Aber du musst nachsehen, wo dein VPN endet:
Wenn er am Router endet, dann sollte es möglichst transparent laufen.
An einem Server ist nicht mehr gesichert, welchen Weg die Sprachpakete nehmen. Normalerweise gehen die bei der Swyx über den Swyx Server, der ja auch als Gateway dient.
Bei Swyx ist auch die gesammte Infrastruktur inkl. AD eingebunden.
Hier musst du mit Wireshark oder TCP-Dump sehen, ob neben dem Verbindungsaufbau von den bekannten IP-Adressen der VPN Teilnehemr auch weitere Pakete unverschlüsselt an der Swyx ankommen. Bei Standard-SIP kann man den Verbindungsaufbau lesen. Beim Swyx Protokoll ist der Verbindungsaufbau nochmals getunnelt und nicht weiter dokumentiert. Die VoIP UDP Pakete sind aber zu sehen.
Hilfreich ist bestimmt auch eine Aufzeichnung am VPN Endgerät (Außendienst-PC) ob der Swyx Client wirklich nur mit der Swyx spricht.
Gruß
Netman
An der Firewall kann es kaum liegen, da der VPN mit einem einzelnen Port durchkommt und die Firwall nicht in die PPTP-VPN Pakete schauen kann.
Aber du musst nachsehen, wo dein VPN endet:
Wenn er am Router endet, dann sollte es möglichst transparent laufen.
An einem Server ist nicht mehr gesichert, welchen Weg die Sprachpakete nehmen. Normalerweise gehen die bei der Swyx über den Swyx Server, der ja auch als Gateway dient.
Bei Swyx ist auch die gesammte Infrastruktur inkl. AD eingebunden.
Hier musst du mit Wireshark oder TCP-Dump sehen, ob neben dem Verbindungsaufbau von den bekannten IP-Adressen der VPN Teilnehemr auch weitere Pakete unverschlüsselt an der Swyx ankommen. Bei Standard-SIP kann man den Verbindungsaufbau lesen. Beim Swyx Protokoll ist der Verbindungsaufbau nochmals getunnelt und nicht weiter dokumentiert. Die VoIP UDP Pakete sind aber zu sehen.
Hilfreich ist bestimmt auch eine Aufzeichnung am VPN Endgerät (Außendienst-PC) ob der Swyx Client wirklich nur mit der Swyx spricht.
Gruß
Netman
Der Swyx-Server (schimpft sich NetPhone Octupus von der Telekom) liegt auf einer VM im gleichen LAN. Wahrscheinlich kommen die Pakete da wohl nicht durch...
In wiefern kann ich denn mein VPN transparent einstellen??
In wiefern kann ich denn mein VPN transparent einstellen??
Hallo,
auch wenn es Dir vllt nicht hilft, trotzdem haben wir eine ähnlich Konstellation:
SBS2003 VPN-Server PPTP
Win2003 R2: Netphone Server
Einwahl von extern auf SBS2003 und Verbindung von NetphoneClient mit Netphone Server klappen problemlos, sowie natürlich die Telefonie
Gruß
auch wenn es Dir vllt nicht hilft, trotzdem haben wir eine ähnlich Konstellation:
SBS2003 VPN-Server PPTP
Win2003 R2: Netphone Server
Einwahl von extern auf SBS2003 und Verbindung von NetphoneClient mit Netphone Server klappen problemlos, sowie natürlich die Telefonie
Gruß
Hallo,
lass doch mal einen Wireshark mit laufen und schau mal wo deine Voice Pakete hängen bleiben.
brammer
lass doch mal einen Wireshark mit laufen und schau mal wo deine Voice Pakete hängen bleiben.
brammer
ich verstehe nicht, warum man immer solch einen Windowsserver für alles nimmt und sich nicht mal einen vernünftigen Router beschafft. Gerade die Lancom-Router funktionieren in Zusammenarbeit mit der Netphone hervorragend.
Gruß, Arch Stanton
Gruß, Arch Stanton
ok danke, ich lade mir dann mal fix wireshark und lass es mal laufen und meld mich dann wieder
so habe das Programm mal laufen lassen, leider sehe ich da erst so kein Problem.
Es wird eine Verbindung zwischen VPN-Client (192.168.248.61) und Telefon im Büro (192.168.248.126) aufgebaut:
192.168.248.126 (Source) 192.168.248.61 (destination) RTP (Protokoll) 214 (Length) PT=ITU-T G. 711 PCMA, SSRC=0x1C1E273E, Seq= 107 Time= 1444557828 (info)
RTP ist ja das Voice Paket, also ist das doch korrekt oder?
Bei dem Ereignis unter dem RTP Protokoll steht folgendes:
Real-Time Transport Protocol
[Stream setup by SDP (frame 3219)
Setup frame :3219
Setup Method SDP
10.. .... = Version RFC 1889 Version (2)
..0. .... = Padding False
...0 .... = Extension: False
0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: ITU-T G.711 PCMA (8)
Sequence number: 107
[Extended sequence number: 65643]
Timestamp: 1444557828
Synchronization Source identifier: 0x1c1e273 (471738174)
Payload: 55545.... usw..
Es wird eine Verbindung zwischen VPN-Client (192.168.248.61) und Telefon im Büro (192.168.248.126) aufgebaut:
192.168.248.126 (Source) 192.168.248.61 (destination) RTP (Protokoll) 214 (Length) PT=ITU-T G. 711 PCMA, SSRC=0x1C1E273E, Seq= 107 Time= 1444557828 (info)
RTP ist ja das Voice Paket, also ist das doch korrekt oder?
Bei dem Ereignis unter dem RTP Protokoll steht folgendes:
Real-Time Transport Protocol
[Stream setup by SDP (frame 3219)
Setup frame :3219
Setup Method SDP
10.. .... = Version RFC 1889 Version (2)
..0. .... = Padding False
...0 .... = Extension: False
0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: ITU-T G.711 PCMA (8)
Sequence number: 107
[Extended sequence number: 65643]
Timestamp: 1444557828
Synchronization Source identifier: 0x1c1e273 (471738174)
Payload: 55545.... usw..
RTP ist das Voice Paket. G711 ist das Standard ISDN Protokoll mit MOS4.2 und unkomprimiert.
Aber die Verbindung wird nicht über das RTP Paket aufgebaut.
Dafür sind ander Pakete zuständig.
Wo wurde aufgezeichnet?
Hat der VPN Client sich auch aus dem Netz raus gewählt und in das andere Netz rein? Er ist ja immer noch lokal. Ein VPN hat ein lokales Netz und geht dann in ein Transportnetz umd dann wieder in einem anderen lokalen Netz anzukommen.
Gruß
Netman
Aber die Verbindung wird nicht über das RTP Paket aufgebaut.
Dafür sind ander Pakete zuständig.
Wo wurde aufgezeichnet?
Hat der VPN Client sich auch aus dem Netz raus gewählt und in das andere Netz rein? Er ist ja immer noch lokal. Ein VPN hat ein lokales Netz und geht dann in ein Transportnetz umd dann wieder in einem anderen lokalen Netz anzukommen.
Gruß
Netman
Zitat von @MrNetman:
RTP ist das Voice Paket. G711 ist das Standard ISDN Protokoll mit MOS4.2 und unkomprimiert.
Aber die Verbindung wird nicht über das RTP Paket aufgebaut.
Dafür sind ander Pakete zuständig.
Wo wurde aufgezeichnet?
Hat der VPN Client sich auch aus dem Netz raus gewählt und in das andere Netz rein? Er ist ja immer noch lokal. Ein VPN hat
ein lokales Netz und geht dann in ein Transportnetz umd dann wieder in einem anderen lokalen Netz anzukommen.
Gruß
Netman
RTP ist das Voice Paket. G711 ist das Standard ISDN Protokoll mit MOS4.2 und unkomprimiert.
Aber die Verbindung wird nicht über das RTP Paket aufgebaut.
Dafür sind ander Pakete zuständig.
Wo wurde aufgezeichnet?
Hat der VPN Client sich auch aus dem Netz raus gewählt und in das andere Netz rein? Er ist ja immer noch lokal. Ein VPN hat
ein lokales Netz und geht dann in ein Transportnetz umd dann wieder in einem anderen lokalen Netz anzukommen.
Gruß
Netman
das wurde auf dem VPN-Server aufgenommen (192.168.248.220)
ich habe mich aus einem anderen Netz, außerhalb unserer Firma eingewählt, danach war ich in unserm 248er Netz.
Danke für die Infos! War auch neu für mich.
Hier noch ein Blog, der euch interessieren dürfte http://www.internetanschluss-ohne-telefon.net
Hier noch ein Blog, der euch interessieren dürfte http://www.internetanschluss-ohne-telefon.net
Der Verbindungsaufbau wird mit SIP gemacht und die Voice Daten werden mit RTP (was UDP benutzt) transportiert.
Generell kann RTP prtoblemlos über ein VPN übertragen werden, das ist kein Hinterungsgrund wie ein identisch funktionierendes Voice Netzwerk bei marinux oben ja eindeutig zeigt.
Dadurch das SIP funktioniert also der Verbindungsaufbau (Klingeln usw.) aber kein TON durchkommt kann es also nur am RTP Transport liegen.
Klassische Fehler bei RTP ist oft das das über NAT geschickt wird was RTP wegen seiner dynmaischen Port Aushandlung nicht supportet es sei denn der Voice Server supportet STUN (Simple Traverse of UDP via NAT).
Du solltest also tunlichst mal checken ob irgendwo im VPN NAT gemacht wird.
Ein 2ter Fehler ist die lokale Firewall die ggf. IPs aus Fremdnetzen blockt also hier auch mal genau die Firewall Einstellungen der lokalen FW checken !
Übrugens...
Was das Thema PPTP VPN anbetrift solltest du besser das hier mal genau lesen:
http://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.h ...
Eigentlich viel schlimmer als das Voice Problem.
Um das zu fixen solltest du mal den sehr berechtigten Einwand vom Kollegen ArchStanton beachten.
Ein VPN gehört auf eine Firewall oder Router. Vielleicht eine Anregung sofern du das PPTP mal in IPsec oder SSL umwandelst.
Generell kann RTP prtoblemlos über ein VPN übertragen werden, das ist kein Hinterungsgrund wie ein identisch funktionierendes Voice Netzwerk bei marinux oben ja eindeutig zeigt.
Dadurch das SIP funktioniert also der Verbindungsaufbau (Klingeln usw.) aber kein TON durchkommt kann es also nur am RTP Transport liegen.
Klassische Fehler bei RTP ist oft das das über NAT geschickt wird was RTP wegen seiner dynmaischen Port Aushandlung nicht supportet es sei denn der Voice Server supportet STUN (Simple Traverse of UDP via NAT).
Du solltest also tunlichst mal checken ob irgendwo im VPN NAT gemacht wird.
Ein 2ter Fehler ist die lokale Firewall die ggf. IPs aus Fremdnetzen blockt also hier auch mal genau die Firewall Einstellungen der lokalen FW checken !
Übrugens...
Was das Thema PPTP VPN anbetrift solltest du besser das hier mal genau lesen:
http://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.h ...
Eigentlich viel schlimmer als das Voice Problem.
Um das zu fixen solltest du mal den sehr berechtigten Einwand vom Kollegen ArchStanton beachten.
Ein VPN gehört auf eine Firewall oder Router. Vielleicht eine Anregung sofern du das PPTP mal in IPsec oder SSL umwandelst.
