24
Wie bringe ich VoIP über VPN Verbindung (Site-to-Site) zum laufen?
Hallo zusammen,
ich hoffe Ihr könnt mir helfen und zwar meine Konstelation ist die folgende:
Standort A = 172.16.19.0/24
Standort A = VoIP Anlange 10.10.100.0/24 Siemens Hipath 4000
Standort B = 192.168.10.0/24
Standort A und B sind mittels Site-to-Site VPN verbunden
Zugrffe auf die Netzwerke sind alle vorhanden
Jetzt installiere ich ein VoIP Telefon vom Standort A an den Standort B.
Das Telefon findet die Telefonanlage von Standort A und kann mit den Internen Nummern wählen und auch angerufen werden.
Super dachte ich aber dann:
Nun das Problem was ich habe ist folgendes; jeder der mich anruft oder jeden den ich anrufe kann ich hören, jedoch kann man mich nicht hören
und ich weis nicht an was das liegt.
Vielleicht habt ihr einen Tipp für mich.
Gruß
wuggale
ich hoffe Ihr könnt mir helfen und zwar meine Konstelation ist die folgende:
Standort A = 172.16.19.0/24
Standort A = VoIP Anlange 10.10.100.0/24 Siemens Hipath 4000
Standort B = 192.168.10.0/24
Standort A und B sind mittels Site-to-Site VPN verbunden
Zugrffe auf die Netzwerke sind alle vorhanden
Jetzt installiere ich ein VoIP Telefon vom Standort A an den Standort B.
Das Telefon findet die Telefonanlage von Standort A und kann mit den Internen Nummern wählen und auch angerufen werden.
Super dachte ich aber dann:
Nun das Problem was ich habe ist folgendes; jeder der mich anruft oder jeden den ich anrufe kann ich hören, jedoch kann man mich nicht hören
und ich weis nicht an was das liegt.
Vielleicht habt ihr einen Tipp für mich.
Gruß
wuggale
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 175563
Url: https://administrator.de/forum/wie-bringe-ich-voip-ueber-vpn-verbindung-site-to-site-zum-laufen-175563.html
Ausgedruckt am: 24.12.2024 um 02:12 Uhr
24 Kommentare
Neuester Kommentar
Die Infos sind recht oberflächlich. Das Wie des Site 2 Site VPNs wäre schon wichtig zu wissen für eine zielführende Hilfe.. 
Wenn du sicherstellen kannst das der Hörer nicht defekt ist oder einen Wackler hat wird vermutlich einseiting das RTP Protokoll (UDP) geblockt in der VPN Verbindung.
Da du dazu aber keinerlei Infos lieferst kann man nur im freien Fall raten...
Am besten also mal einen Wireshark Sniffer nehmen und nachmessen..dann siehst du es sofort !
Wenn du sicherstellen kannst das der Hörer nicht defekt ist oder einen Wackler hat wird vermutlich einseiting das RTP Protokoll (UDP) geblockt in der VPN Verbindung.
Da du dazu aber keinerlei Infos lieferst kann man nur im freien Fall raten...
Am besten also mal einen Wireshark Sniffer nehmen und nachmessen..dann siehst du es sofort !
Das wie ist recht einfach
Die 2 Site Verbundung ist mittels BOVPN via SystemManager per Watchguard erstellt
Standort A = Watchguard x1250e - 10Mbit Standleitung
Standort B = Watchguard x10eW - DSL 6000
Telefon funktioniert zu 100% kann ich ausschliesen.
An beiden Firewalls sind keine Blocks oder Deny Messages im Log zu lesen
Werde Wireshark Log am Mittwoch mal posten vielleicht kann man hierbei mehr sehen
Bis dahin stehe ich gerne für weiter Fragen offen
Die 2 Site Verbundung ist mittels BOVPN via SystemManager per Watchguard erstellt
Standort A = Watchguard x1250e - 10Mbit Standleitung
Standort B = Watchguard x10eW - DSL 6000
Telefon funktioniert zu 100% kann ich ausschliesen.
An beiden Firewalls sind keine Blocks oder Deny Messages im Log zu lesen
Werde Wireshark Log am Mittwoch mal posten vielleicht kann man hierbei mehr sehen
Bis dahin stehe ich gerne für weiter Fragen offen
Dann sieht das aber doch wirklich nach Firewall aus. Schliesse sicher aus das die FW NAT macht oder sowas. In den Absender und Ziel IPs sollten die nativen Netze zu sehen sein !
Sniffer mal einen "normalen" Verbindungsaufbau und dann zum Vergleich einen über das VPN.
Besonderes Augenmerk auf das RTP Protokoll. Das wird vermutlich nur einseitig gesendet.
Am SIP kanns ja nicht liegen, denn sonst wäre schon der Verbindungsaufbau gescheitert...
Machst du irgendeine Art von QoS Bei Voice ?
Sniffer mal einen "normalen" Verbindungsaufbau und dann zum Vergleich einen über das VPN.
Besonderes Augenmerk auf das RTP Protokoll. Das wird vermutlich nur einseitig gesendet.
Am SIP kanns ja nicht liegen, denn sonst wäre schon der Verbindungsaufbau gescheitert...
Machst du irgendeine Art von QoS Bei Voice ?
Moin, für mich sieht das nach nem Codec Problem aus.
Die Codecs der Anlage und des IP-Fones müssen gleich sein ansonsten gibt es nur Probleme.
Es sei denn das ist ein Systemapparat.... dann sollte es ohne Probleme laufen...
Zum Testen kann ich nur Phoner empfehlen...
(Allerdings ist mein Anlagengebiet Alcatel Lucent OXO, bei den Siemens Büchsen kenn ich nur die 3000er ohne IP einigermaßen.)
LGLC
Die Codecs der Anlage und des IP-Fones müssen gleich sein ansonsten gibt es nur Probleme.
Es sei denn das ist ein Systemapparat.... dann sollte es ohne Probleme laufen...
Zum Testen kann ich nur Phoner empfehlen...
(Allerdings ist mein Anlagengebiet Alcatel Lucent OXO, bei den Siemens Büchsen kenn ich nur die 3000er ohne IP einigermaßen.)
LGLC
Direkt funktioniert es ja problemlos mit dem Equipment...der Verdacht ist also vermutlich falsch !
Ja genau direkt mit dem telfon funktioniert es einwandfrei das Telfon ist ein Optipoint Standard das wir am Standort A komplett verwenden.
Ich werde dass mal mitsniffen und stelle das Log mal morgen hier rein falls ich es nicht selber entziffern kann ;)
Könnte es vielleicht daran liegen dass ich eine FritzBox als DSL Modem konfiguriert habe?
Sprich so:
Standort B:
DSL -> FritzBox (DSL Modem) --> WG X10eW --> Telefon
Ich werde dass mal mitsniffen und stelle das Log mal morgen hier rein falls ich es nicht selber entziffern kann ;)
Könnte es vielleicht daran liegen dass ich eine FritzBox als DSL Modem konfiguriert habe?
Sprich so:
Standort B:
DSL -> FritzBox (DSL Modem) --> WG X10eW --> Telefon
Dreh mal das Logging der FB hoch, sind die ANY Policies eingerichtet oder Routest du das ganze durch seperate Policies (Denk daran das die Policies immer von oben nach unten abgearbeitet werden.) aktuelle Firmware IMHO 11.3.4 wenn ich mich nicht irre. Stimmt das GW im Optipoint. Mit der Fritzbox solange diese als reines Modem konfiguriert ist hat das nix zu tun.
Da wir Watchguard vertreiben und Spupporten kann ich nur sagen das wir bei VoIP noch nie Probleme hatten (solange das BO richtig konfiguriert ist.)
LGLC
Da wir Watchguard vertreiben und Spupporten kann ich nur sagen das wir bei VoIP noch nie Probleme hatten (solange das BO richtig konfiguriert ist.)
LGLC
Ich habe die Konstelation nachmals hergestellt und ich kann in der Firebox folgendes auslesen soblad ich das Telefon bediene:
Nov 2 10:41:11 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:11 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:08 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:08 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:08 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:08 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:08 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
wobei 10.10.100.4 die Telefonanlage ist und die 192.168.10.18 das Telfon ist
Nov 2 10:41:11 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:11 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:08 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:08 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:08 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:08 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
Nov 2 10:41:08 kernel ip_conntrack: max number of expected connections 2 of H.225 reached for 10.10.100.4->192.168.10.18, reusing
wobei 10.10.100.4 die Telefonanlage ist und die 192.168.10.18 das Telfon ist
Und was loggt die box während des Gesprächs?
Filter mal nach RTP und sip oder läuft das ganze über h323?
LGLC
Filter mal nach RTP und sip oder läuft das ganze über h323?
LGLC
Firebox-Technisch wars das ich werde gleich mal den Wireshark anschmeisen und poste dann wieder...
Mit Wireshark bekomme ich nur raus dass das telefon eine ARP macht und das wars
Vielleicht bin ich auch zu blöde das richtig anzuschliessen wie muss ich denn das verbinden um das zu sehen was das Telefon treibt
Vielleicht bin ich auch zu blöde das richtig anzuschliessen wie muss ich denn das verbinden um das zu sehen was das Telefon treibt
Du musst den Rechner wo Wireshark drauf läuft über einen Hub mit der TK-Anlage verbinden. Alternativ über ein Port mirroring den Port der TK-Anlage auf den Port des Rechners Spiegeln damit du Ergebnisse erzielst.
Switche Brüllen ihre Infos nicht auf allen Ports raus sondern wenden sich direkt an den betreffenden Rechner für den die Pakete bestimmt sind.
Filter bei wireshark auf "SIP or RTP or T38" setzen
Wurde das Logging in der Firewall auf Diagnose gesetzt?
Wie sind die Policies für die Sipverbindung konfiguriert?
Oder wird H323 verwendet?
Ist dort das Logging aktiviert?
Ist eine ANY Policy für den BOVPN konfiguriert?
Hattest du Filter beim Logging eingestellt?
Wenn ja wie?
LGLC
Switche Brüllen ihre Infos nicht auf allen Ports raus sondern wenden sich direkt an den betreffenden Rechner für den die Pakete bestimmt sind.
Filter bei wireshark auf "SIP or RTP or T38" setzen
Wurde das Logging in der Firewall auf Diagnose gesetzt?
Wie sind die Policies für die Sipverbindung konfiguriert?
Oder wird H323 verwendet?
Ist dort das Logging aktiviert?
Ist eine ANY Policy für den BOVPN konfiguriert?
Hattest du Filter beim Logging eingestellt?
Wenn ja wie?
LGLC
So nach langen hin und her haben ich jetzt diese sch.... zum laufen gebracht
Ich habe jetzt eine Manuele IPSEC Verbindung mit einer FritzBox 7170 hergestellt und es funktioniert einwandfrei *happy*
Über die WG BOVPN habe ich es nicht zumlaufen gebraucht abwohl eine ANY Regel vorhanden war.
Ich weis nicht was das dumme Teil geblockt hat und vor allem wo *ggrrrrrr*
Naja es geht halt nichts über eine guta alte FritzBox
))
Gruß
wuggale aber vielen vielen Dank für die Infos
Ich habe jetzt eine Manuele IPSEC Verbindung mit einer FritzBox 7170 hergestellt und es funktioniert einwandfrei *happy*
Über die WG BOVPN habe ich es nicht zumlaufen gebraucht abwohl eine ANY Regel vorhanden war.
Ich weis nicht was das dumme Teil geblockt hat und vor allem wo *ggrrrrrr*
Naja es geht halt nichts über eine guta alte FritzBox
))Gruß
wuggale aber vielen vielen Dank für die Infos
Kein Thema... Aber rein aus neugier würde ich trotz allem versuchen rauszubekommen woran es liegt.. Schon alleine aus dem grund um zukünftige Probleme zu vermeiden... LGLC
Das is ja mal ein hammer ...
Ich habe exakt das gleiche Phänomen ...
- Tunnel zw. A und B steht einwandfrei.
- NAT is aus
- Telefone an beiden Standorten Identisch (snom300)
ruft man intern von B nach A an ist genau das beschriebene Verständigungsproblem vorhanden.
aber auch nur, wenn man die interne kurzwahl verwendet!
wählt man die komplette nummer, klappt alles einwandfrei ...
wähle ich von B aus die interne 99 an, kommt das Verständigungsproblem
wähle ich von B aus die externe Nummer 471199, ist alles OK
weiterhin gibt es an B das problem, dass die Gespräche teilweise aussetzer haben und/oder das Gespräch irgendwann das Verständigungsproblem bekommt
@wuggale
wie hast du das mit der 7170 in den griff bekommen?
interessiert mich brennend, da ich dem Fehler einfach nicht auf die Schliche komme ...
Ich habe exakt das gleiche Phänomen ...
- Tunnel zw. A und B steht einwandfrei.
- NAT is aus
- Telefone an beiden Standorten Identisch (snom300)
ruft man intern von B nach A an ist genau das beschriebene Verständigungsproblem vorhanden.
aber auch nur, wenn man die interne kurzwahl verwendet!
wählt man die komplette nummer, klappt alles einwandfrei ...
wähle ich von B aus die interne 99 an, kommt das Verständigungsproblem
wähle ich von B aus die externe Nummer 471199, ist alles OK
weiterhin gibt es an B das problem, dass die Gespräche teilweise aussetzer haben und/oder das Gespräch irgendwann das Verständigungsproblem bekommt
@wuggale
wie hast du das mit der 7170 in den griff bekommen?
interessiert mich brennend, da ich dem Fehler einfach nicht auf die Schliche komme ...
Das freut mich dass es auch andere so geht wie mir,
Der Fehler war bei mir immer da sowohl bei extern als auch interner Nummernwahl
das mit der FB7170 und WG war recht einfach, habe mir eine DYNDNS registriert und habe dann mit dieser ein MANUEL IPSEC VPN Verbindung hergestellt mit der FB
1) DYNDNS registrieren
2) DYNDNS bei FritzBox eingeben
3) VPN Config File an der FritzBox einspielen
4) Gegenseite Firewall konfigurieren (Gateway und Tunnel)
5) warten bis Tunnel aufgebaut ist
6) freuen darüber dass es funktioniert
Wenn du das Config File der Fritzbox brauchst dass kann ich dir gerne zukommen lassen bzw. hier Posten.
Gruss wuggale
Der Fehler war bei mir immer da sowohl bei extern als auch interner Nummernwahl
das mit der FB7170 und WG war recht einfach, habe mir eine DYNDNS registriert und habe dann mit dieser ein MANUEL IPSEC VPN Verbindung hergestellt mit der FB
1) DYNDNS registrieren
2) DYNDNS bei FritzBox eingeben
3) VPN Config File an der FritzBox einspielen
4) Gegenseite Firewall konfigurieren (Gateway und Tunnel)
5) warten bis Tunnel aufgebaut ist
6) freuen darüber dass es funktioniert
Wenn du das Config File der Fritzbox brauchst dass kann ich dir gerne zukommen lassen bzw. hier Posten.
Gruss wuggale
danke danke ...
... wenn du sagst, mit der FB 7170 geht das ganze, dann überlege ich ernsthaft, ob ich nicht einfach zwei FBs besorge und die Standortkopplung über diese abwickle ...
Damit sollte das Problem ja in den Griff zu kriegen sein ... oder ?
... wenn du sagst, mit der FB 7170 geht das ganze, dann überlege ich ernsthaft, ob ich nicht einfach zwei FBs besorge und die Standortkopplung über diese abwickle ...
Damit sollte das Problem ja in den Griff zu kriegen sein ... oder ?
bei mir hat es einwandfrei funktioniert, ich werde am kommenden Montag das nochmals versuchen und geben dann nochmals bescheid
bis dahin schönes WE
gruß wuggale
bis dahin schönes WE
gruß wuggale
na top ...
habe schon zwei 7170'er geordert ...
wenn das klappt, habe ich für EUR 160,- 'ne funzende Lösung gefunden für dieses nervige Problem ...
melde mich auch wieder hier im Thread, wenn die Geräte integriert sind ...
c ya
habe schon zwei 7170'er geordert ...
wenn das klappt, habe ich für EUR 160,- 'ne funzende Lösung gefunden für dieses nervige Problem ...
melde mich auch wieder hier im Thread, wenn die Geräte integriert sind ...
c ya
2 Draytek, 2 Linksys usw. hättens auch gemacht. Ist egal...Hauptsache die Router können VPN. Das wird das Problem lösen...
dann klappt's bei mir wohl nich ...
weil derzeit wird der Tunnel über zwei LinkSys BEFVP41 hergestellt ...
Mit denen kommt es bei mir zu dem Problem ...
weil derzeit wird der Tunnel über zwei LinkSys BEFVP41 hergestellt ...
Mit denen kommt es bei mir zu dem Problem ...
Hallo
so habe jetzt nochmal einen neukonfiguration angeschlossen und funktioniert einwandfrei *happy*
VPN Config: WG1250e und Fritzbox7170
Endgeräte: Siemens OptiPoint
TK-Anlage: Hipath 5000
Und läuft super )
so habe jetzt nochmal einen neukonfiguration angeschlossen und funktioniert einwandfrei *happy*
VPN Config: WG1250e und Fritzbox7170
Endgeräte: Siemens OptiPoint
TK-Anlage: Hipath 5000
Und läuft super
)
Aloha zusammen ...
... nach langer Zeit bin ich nun doch noch mal da ;)
Wir haben an Standort A eine Panasonic TK (voip-fähig).
Intern verwenden wir dort snom300 und zwei SysTel an der Anmeldung.
Nun kam Standort B dazu.
Die Telefone dort wurden über einen IPSEC-Tunnel an die TK in Standort A angebunden.
Der Tunnel läuft stabil über zwei FB7170.
Die Verbindung zur TK ist vorhanden und externe Gespräche sind sowohl ausgehend als auch ankommend durchführbar.
Was allerdings noch immer vorhanden ist, ist das Problem, dass eine interne VOIP-Telefonie durch den Tunnel nicht klappt.
Ruft man von B (voip) aus eine Nr in A (voip) an, so ist in A alles OK. In B allerdings ist die Stimmer von A nicht zu hören.
Ruft man von B (voip) aus eine Nr in A (voip) nicht über die interne Nr sondern über Amt an, so ist die beidseitige Verständigung OK.
Ruft man von B (voip) aus eines der beiden Systemtelefone in A an, so ist beidseitige Verständigung OK.
Hoffe, es hat noch jemand eine Idee, wo das Sprachproblem liegen kann ...
... nach langer Zeit bin ich nun doch noch mal da ;)
Wir haben an Standort A eine Panasonic TK (voip-fähig).
Intern verwenden wir dort snom300 und zwei SysTel an der Anmeldung.
Nun kam Standort B dazu.
Die Telefone dort wurden über einen IPSEC-Tunnel an die TK in Standort A angebunden.
Der Tunnel läuft stabil über zwei FB7170.
Die Verbindung zur TK ist vorhanden und externe Gespräche sind sowohl ausgehend als auch ankommend durchführbar.
Was allerdings noch immer vorhanden ist, ist das Problem, dass eine interne VOIP-Telefonie durch den Tunnel nicht klappt.
Ruft man von B (voip) aus eine Nr in A (voip) an, so ist in A alles OK. In B allerdings ist die Stimmer von A nicht zu hören.
Ruft man von B (voip) aus eine Nr in A (voip) nicht über die interne Nr sondern über Amt an, so ist die beidseitige Verständigung OK.
Ruft man von B (voip) aus eines der beiden Systemtelefone in A an, so ist beidseitige Verständigung OK.
Hoffe, es hat noch jemand eine Idee, wo das Sprachproblem liegen kann ...
Ja, vermutlich machst du irgendwo im Tunnel NAT (Adress Translation) Dadurch kann einseitig das RTP Protokoll (dort werden die Sprachdaten übertragen) keine Verbindung aufbauen da das dynamische Ports benutzt. Ein klassisches Problem wenn du an einem Ende NAT machst.
Prüfe also die VPN Tunnelkonfiguration ob dort NAT enabled ist und schalte das ab damit du transparent routen kannst im VPN Tunnel !
Die gegenseite IP Erreichbarkeit auch checken. Die VoIP Telefone müssen von beiden Standorten vom VoIP Gateway aus problemlos pingbar sein !
Damit ist das Problem dann im Handumdrehen gefixt !
Prüfe also die VPN Tunnelkonfiguration ob dort NAT enabled ist und schalte das ab damit du transparent routen kannst im VPN Tunnel !
Die gegenseite IP Erreichbarkeit auch checken. Die VoIP Telefone müssen von beiden Standorten vom VoIP Gateway aus problemlos pingbar sein !
Damit ist das Problem dann im Handumdrehen gefixt !
