12
OpenVPN Point-to-Point - VoIP Probleme
Hallo zusammen,
melde mich hier, weil ich aktuell nicht ganz verstehe was da passiert. Vielleicht kann mir jemand helfen
Folgender Aufbau:
Netzwerk 1:
1&1 VDSL
Fritzbox 7362 SL aktuelles OS
OpenVPN Server: Igel Thin Client direkt an FB
Netzwerkadressen:
192.168.3.0
255.255.255.0
Netzwerk 2:
Telekom Magenta S (Hybrid)
Speedport Hybrid -> FritzBox 7390 OS phone aus Labor
Im Speedport sind die Telefonnummern deaktiviert und werden über die FritzBox als VoIP geführt. Funktioniert, ab und an kommt Fehler 503, der aber kurz darauf verschwindet.
Die fritzBox ist an LAN 1 angeschlossen und fubgiert als eigenständiger Router.
An der Fritz ist der baugleiche Igel angeschlossen, auch mit OpenVPN. Das Netzwerk hinter der fritzBox:
192.168.188.0
255.255.255.0
Die Verbindung der Server funktioniert tadellos, nach dem im Speedport die nötigen tcp Ports auf die Fritz weitergeleitet wurden und von der Fritz auf den Igel. In jeder fritzBox die nötigen Routen konfiguriert und schon konnte man auf Geräte im entfernten Netzwerk zugreifen.
Ist jetzt die VPN Verbindung hergestellt, gibt es im Telekom Netzwerk Probleme mit dem Festnetz, bzw. mit der VoIP. Die Telefonie nach außen geht, eingehende Telefonate nicht.
Kennt jemand das Problem oder könnte sich denken woran es liegt?
Danke,
Erik
P.s.: auf beiden Igeln läuft Debian
melde mich hier, weil ich aktuell nicht ganz verstehe was da passiert. Vielleicht kann mir jemand helfen
Folgender Aufbau:
Netzwerk 1:
1&1 VDSL
Fritzbox 7362 SL aktuelles OS
OpenVPN Server: Igel Thin Client direkt an FB
Netzwerkadressen:
192.168.3.0
255.255.255.0
Netzwerk 2:
Telekom Magenta S (Hybrid)
Speedport Hybrid -> FritzBox 7390 OS phone aus Labor
Im Speedport sind die Telefonnummern deaktiviert und werden über die FritzBox als VoIP geführt. Funktioniert, ab und an kommt Fehler 503, der aber kurz darauf verschwindet.
Die fritzBox ist an LAN 1 angeschlossen und fubgiert als eigenständiger Router.
An der Fritz ist der baugleiche Igel angeschlossen, auch mit OpenVPN. Das Netzwerk hinter der fritzBox:
192.168.188.0
255.255.255.0
Die Verbindung der Server funktioniert tadellos, nach dem im Speedport die nötigen tcp Ports auf die Fritz weitergeleitet wurden und von der Fritz auf den Igel. In jeder fritzBox die nötigen Routen konfiguriert und schon konnte man auf Geräte im entfernten Netzwerk zugreifen.
Ist jetzt die VPN Verbindung hergestellt, gibt es im Telekom Netzwerk Probleme mit dem Festnetz, bzw. mit der VoIP. Die Telefonie nach außen geht, eingehende Telefonate nicht.
Kennt jemand das Problem oder könnte sich denken woran es liegt?
Danke,
Erik
P.s.: auf beiden Igeln läuft Debian
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: 268468
Url: https://administrator.de/contentid/268468
Printed on: April 16, 2024 at 22:04 o'clock
12 Comments
Latest comment
Vielleicht kann mir jemand helfen
Dann versuchen wir das mal....Vorab: Das entsprechende Tutorial was die Details zum OVPN Setup beschreibt hier im Forum hast du genau gelesen ??
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die fritzBox ist an LAN 1 angeschlossen und fubgiert als eigenständiger Router.
Dazu noch einen genau Frage:Du betreibst hier also eine Routerkaskade aus zwei hintereinander kaskadierten NAT (IP Translation) Routern ? Ist das richtig ?
Das ist das gleiche Design wie es hier in der Alternative 2 beschrieben ist ?
Kopplung von 2 Routern am DSL Port
Die Telefonie nach außen geht, eingehende Telefonate nicht.
Das zeigt das dein Port Forwarding mit SIP bzw. RTP nicht richtig eingetragen ist. Das passiert an einem der NAT Übergange und ist ein typisches Zeichen dafür. Man kann auch nur hoffen das du auf dem OVPN Tunnel selber kein NAT eingerichtet hast.Die Problematik ist vermutlich der SP, denn auf dem ist VoIP nicht richtig deaktiviert. Er hat vermutlich keinerlei Nummernuordnung (SIP) konfiguriert, "hört" aber weiterhin auf eingehende SIP Pakete und leitet diese nicht an die FB weiter und das auch trotz Port Forwarding.
Ist jetzt mal geraten weil detailierteres Troubleshooting fehlt bei dir
Das müsstest du mal kontrollieren und ggf. einen anderen SIP Port nehmen wie TCP 5061 oder höher.
Ums genau zu sehen solltest du mal einen Wireshark Sniffer nehmen und checken WO deine eingehenden SIP Pakete bleiben in der Kaskade ?!
Damit wüsste man dann sofort was passiert und wo es kneift.
Zitat von @aqui:
Dazu noch einen genau Frage:
Du betreibst hier also eine Routerkaskade aus zwei hintereinander kaskadierten NAT (IP Translation) Routern ? Ist das richtig ?
Das ist das gleiche Design wie es hier in der Alternative 2 beschrieben ist ?
Kopplung von 2 Routern am DSL Port
Dazu noch einen genau Frage:
Du betreibst hier also eine Routerkaskade aus zwei hintereinander kaskadierten NAT (IP Translation) Routern ? Ist das richtig ?
Das ist das gleiche Design wie es hier in der Alternative 2 beschrieben ist ?
Kopplung von 2 Routern am DSL Port
QUASI fast genauso, außer dass die FB über LAN1 <-> LAN 1 SP und nicht am WAN-Port angeschlossen ist. Ich habe die Fritzbox im Internetanbieter so eingestellt, dass sie nicht als IP-Client eingerichtet ist, sondern ihren Internetzugang über LAN 1 (EInstellung FB: Internetzugang über LAN 1/ nicht die Methode anderer Internetanbieter, Externes Mdem). Ich habe es so gewählt, damit ich an der FB portforwarding einstellen kann. Also erst vom SP an die FB den Port freigeben und dann von der FB weiter an das nötige Gerät. DynDNS ist im SP eingetragen und klappt alles in dieser Konstellation, außer das Telefon.
Ich habe um einige Fehlerquellen auszuschließen, die VPN Verbindung gekappt und siehe da, VoIP klappt trotzdem nicht, ausgehende Telefonate gehen einwandfrei, eingehende hört nur mich der Gesprächspartner, aber nicht ich ihn.
ich habe hier im Forum eine Hilfestellung gelesen, welches sich mit den Ports beschäftigte und es wurde auf:
http://hilfe.telekom.de/hsp/cms/content/HSP/de/3378/faq-350884716
verwiesen.
Hier stellt sich die Frage, was ist der Unterschied zwischen UDP out und in? Kann ich das irgendwie regeln? Ich habe auch mehrere EInstellungen versucht, komischerweise wird in der FB die RUfnummern mit jeder konstellation als "grün" angezeigt. ICh hatte ein DECT Telefon an der FB angeschlossen, dann die Rufnummern gelöscht und ich konnte trotzdem nach außen telefonieren :-O
Alternativ habe ich es auch getestet, als ich die Rufnummern im SP deaktivierte und in der FB eingetragen und im SP aktivierte und in der FB eingetragen, immer das selbe Ergenis
Ports freigeben sind:
UDP (out): Ports 5060, 30000-31000, 40000-41000, 3478, 3479
TCP (out): Port 80, 443
UDP (in): kann ich nicht eingeben, da die in Out schon eingetragen sind....
Liegt es hierdran?
Danke
Erik
Ich habe es so gewählt, damit ich an der FB portforwarding einstellen kann. Also erst vom SP an die FB den Port freigeben und dann von der FB weiter an das nötige Gerät.
Das hat aber rein gar nichts mit dieser Einstellung zu tun. Port Forwarding kann man auch im Modem Betrieb machen. Hier irrst du also !Nur du musst den Modem Betreib ja bypassen, da du eine Router Kaskade betreibst und durch den davorliegenden SP Router ja dann ein Ethernet Interface benötigst. Der Modemport ist ja nicht nutzbar logischerweise...aber egal.
eingehende hört nur mich der Gesprächspartner, aber nicht ich ihn.
Das ist ein ganz klares Zeichen das dein SIP bzw. RTP Port Forwarding nicht stimmt bzw. in der NAT Firewall hängen bleibt. Ein typischer Fehler bei VoIP.Hier stellt sich die Frage, was ist der Unterschied zwischen UDP out und in?
Na, das ist doch ganz logisch... Das sind UDP Pakete die einem IN den Router reingehen (in) und welche die AUS dem Router rausgehen (out)..eigentlich ganz einfach und logisch !komischerweise wird in der FB die RUfnummern mit jeder konstellation als "grün" angezeigt.
Was bitte ist daran komisch ??Die FB macht einen SIP Authentication mit dem SIP Gateway und wenn die erfolgreich ist wird die Lampe grün. Die spätere Vermittlung durch SIP eröffnet aber einen RTP Datenstrom direkt zw. den beiden Endpartnenr mit dynamischer UDP Portaushandlung und genau DA liegt dein Problem ! Der eingehende UDP Port liegt ganz sicher außerhalb deiner Port Forwarding Range und bleibt so in der NAT Firewall hängen. Dein eigener UDP Stream geht aber raus. Deshalb hört dich dein Gesrächspartner du aber nicht ihn weil sein UDP Port geblockt wird. Lässt sich alles logisch erklären wenn man sich mal über die verwendeten Protokolle bei VoIP (SIP, RTP) und deren Sessionaufbau informiert.
Ob du da Telefone mit DECT oder Draht anschliesst ist vollkommen belanglos und hat mit der eigentlichen Ursache nix zu tun, denn die liegt klar im VoIP Verbindungsaufbau.
Entspr. Port Ranges auch hier:
http://www.3cx.com/blog/voip-howto/pfsense-firewall/
Hallo,
danke für deine Mühen. Langsam kommt Licht ins Dunkel
ich habe jetzt die Ports ala
http://hilfe.telekom.de/hsp/cms/content/HSP/de/3378/FAQ/theme-133631783 ...
freigegeben, doch es bleibt lautlos. Ich kann den Port 5060 auch nicht an die FB weiterleiten, gesperrt für interne Zwecke des SP.
Kann ich da noch etwas machen?
danke für deine Mühen. Langsam kommt Licht ins Dunkel
ich habe jetzt die Ports ala
http://hilfe.telekom.de/hsp/cms/content/HSP/de/3378/FAQ/theme-133631783 ...
freigegeben, doch es bleibt lautlos
. Ich kann den Port 5060 auch nicht an die FB weiterleiten, gesperrt für interne Zwecke des SP.Kann ich da noch etwas machen?
Bevor wir uns hier weiter endlos im Kreis drehen: Nimm einen Wireshark Sniffer und sieh dir genau an mit welchen dynamischen Ports der RTP Request zurückkommt. Dann weisst du das doch im Handumdrehen.
Testweise kannst du ja mal einen "exposed Host" konfigurieren, sprich ALLE Ports forwarden !
Das ist zwar sicherheitstechnischer GAU aber für einen kurzen Test ob Voice dann generell funktioniert kann man das problemlos mal machen !
Wenn ALLE Ports geforwardet werden solltest du auch sofort bidirektional telefonieren können !
Nach dem Test dann schnell wieder "dichtmachen"
Testweise kannst du ja mal einen "exposed Host" konfigurieren, sprich ALLE Ports forwarden !
Das ist zwar sicherheitstechnischer GAU aber für einen kurzen Test ob Voice dann generell funktioniert kann man das problemlos mal machen !
Wenn ALLE Ports geforwardet werden solltest du auch sofort bidirektional telefonieren können !
Nach dem Test dann schnell wieder "dichtmachen"
Hallo aqui,
du wirst es nicht glauben, aber den Wireshark habe ich gestern bentutzt
Darf ich das Logfile hier posten oder wurde das den Thread sprengen, oder ist es besser, den irgendwo hochzuladen?
Die dortigen Ports habe ich gefunden und geforwarded... bis auf den 5060, den ich ja nicht forwarden kann Vielleicht kannst du ja "mehr" daraus lesen
Beim Wireshark habe ich folgendes gemacht:
1. In der FB die logs vom Internet und eth0 mitgeschnitten
2. Den Mitschnitt in Wireshark importiert
3. VoIP gesucht bzw. nach den Protokollen
4. Die gefundenen Ports geforwarded.
Reicht ein Screenshot vom Logfile bzw. der Auswertung von Wireshark? Oder Wie kann ich es bereitstellen? :-O
Danke
Erik
du wirst es nicht glauben, aber den Wireshark habe ich gestern bentutzt
Darf ich das Logfile hier posten oder wurde das den Thread sprengen, oder ist es besser, den irgendwo hochzuladen?
Die dortigen Ports habe ich gefunden und geforwarded... bis auf den 5060, den ich ja nicht forwarden kann
Vielleicht kannst du ja "mehr" daraus lesen Beim Wireshark habe ich folgendes gemacht:
1. In der FB die logs vom Internet und eth0 mitgeschnitten
2. Den Mitschnitt in Wireshark importiert
3. VoIP gesucht bzw. nach den Protokollen
4. Die gefundenen Ports geforwarded.
Reicht ein Screenshot vom Logfile bzw. der Auswertung von Wireshark? Oder Wie kann ich es bereitstellen? :-O
Danke
Erik
Darf ich das Logfile hier posten oder wurde das den Thread sprengen, oder ist es besser, den irgendwo hochzuladen?
Wenn du VORHER nur die relevanten Frames rausgefiltert hast mit der Filteroption und das nicht mehr als 2 Seiten ist (eigentlich reichen max. 5 Pakete !) kannst du das machen. Sonst sendspace.com oder sowas...bis auf den 5060, den ich ja nicht forwarden kann
Das ist schlecht, denn das ist der SIP Port !Aber egal, die Voice Daten sind RTP basierend und wenn du eine Richtung nicht hörst ist das immer RTP und nicht SIP, denn SIP wird nur einzig für den Verbindungsaufbau benutzt.
Hätte SIP ein Problem kannst du nicht wählen.
Wichtig sind einzig die eingehenden RTP Pakete direkt nach dem SIP Verbindungsaufbau, denn dort nutzt RTP dynmaische Ports. Sind die im PFW nicht eingtragen blockt die NAT Firewall diese und dann ists aus mit der Sprache.
Das allein zeigt schon was du für eine schrottige HW hast, leider. Moderne Router lassen ein Application Gateway für Voice laufen was automatisch diese Ports erkennt und dann pro Session öffnet in der FW.
Bei dir ist das mit PFW dann statisch also permanent. Das stellt ein gewaltiges Sicherheitsrisiko dar, denn diese Ports sind nach außen egal ob sie benutzt werden oder nicht immer offen.
Schlechte HW eben....
lesbar mit Notepad++
Das ist blöd mit Notepad in Textform ! Außerdem WAS machen da Mac OS-X user wie aqui die haben keinen komischen "Notepad" !
Wenn, dann lade schon bitte den originalen .pcap File da hoch !
Wenn, dann lade schon bitte den originalen .pcap File da hoch !
das war ein bespielt, mit was du es öffnen kannst
ist eine ETH-Datei, also im Wireshark importierbar
*edit*
hier die export datei aus wireshark
ist eine ETH-Datei, also im Wireshark importierbar
*edit*
hier die export datei aus wireshark
"bespielt" ???
.pcap Dateien kann man nicht mit einem ASCI Editor öffnen !
Aber egal...sehen wir uns das Drama mal an.
.pcap Dateien kann man nicht mit einem ASCI Editor öffnen !
Aber egal...sehen wir uns das Drama mal an.
1
Bespielt
Sollte Beispiel werden
Sollte Beispiel werden
