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
Please also mark the comments that contributed to the solution of the article
Content-Key: 268468
Url: https://administrator.de/contentid/268468
Printed on: April 23, 2024 at 06: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.
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/
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"
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....