13
VoIP RTP Packages durch VPN
Hallo Forum, ich bin nun seit 2 Tagen auf der Suche nach einer Lösung für mein Problem und bin aber auch in diversen Beiträgen hier im Forum nicht fündig geworden.
Folgendes Setup:
Die pfSense ist aktuell noch auf dem LAN Interface als Netzwerkclient hinter der FritzBox 7590 angeschlossen. Die pfSense dient aktuell nur als OpenVPN Server.
Auf der anderen Seite gibt es einen Router (TP-LINK) mit OpenWRT. Dieser baut eine Verbindung zum OpenVPN Server auf. Als Serveradresse hat der TP-Link die öffentliche IPv4 (Fest) der FrtizBox eingetragen. Über das Forwarding klappt die VPN Verbindung.
Ebenfalls am Switch auf der TP-Link Seite ist ein IP-Telefon und ein Client. Vom Client aus kann ich auf alle Ressourcen des 172.16.0.0/16 Netz zugreifen. Kein Problem.
Das Telefon ist so konfiguriert, dass als Gateway die 172.16.4.1 eingetragen ist. Somit findet das Telefon über den VPN Tunnel seine Analge. Das klappt.
Leider habe ich nun das typische Problem, dass die RTP-Pakete unterwegs verloren gehen.
Ich habe mit tcpdump auf der TP-Link Seite bereits einen trace gemacht. Hier sehe ich, dass die 192.168.1.226 (Telefon) mit der Anlage 172.16.4.1 spricht. Die SIP Kommunikation klappt auch. Das Telefon klingelt bei Anruf und ich kann raus rufen. Das funktioniert. Nur nach dem Abnehmen höre ich nichts.
Ich bin leider kein VoIP Experte und hoffe auf die ein oder andere Idee, wie ich das ganze Problem lösen kann. Kann es sein, dass die TKA das Telefon im entfernten Netz (192.168.1.226/24) erreichen muss? Fehlt evtl. eine Route?
Mein Telefon auf der TP-Link Seite ist ein Unify OpenStage 40.
Jede Hilfe kann ich gerade wirklich gut gebrauchen! DANKE!
Folgendes Setup:
Die pfSense ist aktuell noch auf dem LAN Interface als Netzwerkclient hinter der FritzBox 7590 angeschlossen. Die pfSense dient aktuell nur als OpenVPN Server.
Auf der anderen Seite gibt es einen Router (TP-LINK) mit OpenWRT. Dieser baut eine Verbindung zum OpenVPN Server auf. Als Serveradresse hat der TP-Link die öffentliche IPv4 (Fest) der FrtizBox eingetragen. Über das Forwarding klappt die VPN Verbindung.
Ebenfalls am Switch auf der TP-Link Seite ist ein IP-Telefon und ein Client. Vom Client aus kann ich auf alle Ressourcen des 172.16.0.0/16 Netz zugreifen. Kein Problem.
Das Telefon ist so konfiguriert, dass als Gateway die 172.16.4.1 eingetragen ist. Somit findet das Telefon über den VPN Tunnel seine Analge. Das klappt.
Leider habe ich nun das typische Problem, dass die RTP-Pakete unterwegs verloren gehen.
Ich habe mit tcpdump auf der TP-Link Seite bereits einen trace gemacht. Hier sehe ich, dass die 192.168.1.226 (Telefon) mit der Anlage 172.16.4.1 spricht. Die SIP Kommunikation klappt auch. Das Telefon klingelt bei Anruf und ich kann raus rufen. Das funktioniert. Nur nach dem Abnehmen höre ich nichts.
Ich bin leider kein VoIP Experte und hoffe auf die ein oder andere Idee, wie ich das ganze Problem lösen kann. Kann es sein, dass die TKA das Telefon im entfernten Netz (192.168.1.226/24) erreichen muss? Fehlt evtl. eine Route?
Mein Telefon auf der TP-Link Seite ist ein Unify OpenStage 40.
Jede Hilfe kann ich gerade wirklich gut gebrauchen! DANKE!
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: 650202
Url: https://administrator.de/contentid/650202
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
13 Kommentare
Neuester Kommentar
Kann es sein, dass die TKA das Telefon im entfernten Netz (192.168.1.226/24) erreichen muss?
Ja, muss es. Also einmal den kompletten Weg von der TK zum Telefon prüfen.Wenn es eine OSBiz ist, kannst du dir auch mal Device@Home mit SPE anschauen, erspart dir den VPN-Tunnel und den Overhead durch die Einkapselung.
Danke dir. Dann muss ich auf der pfSense mal schauen wo ich die Route vom Tunnel-Network ins entfernte Netz rein bekomme... Wenn das so überhaupt klappt. Aber sowas dachte ich mir schon. Heißt aber am Ende des Tages muss ich von der TKA (172.16.4.1) auf das Telefon Zugreifen können?
_Ja_
Ausserdem solltest Du noch prüfen, ob Du NAT im Tunnel machst. Das funktioniert nämlich nicht mit VoIP.
Ja das befürchte ich auch. Der pfSense OpenVPN Wizzard legt auf jeden Fall NAT rules an. Ich habe bei OpenVPN eine gute Doku gefunden: https://openvpn.net/community-resources/how-to/#scope
Das werden ich mal in Angriff nehmen um dem VPN Subnet zu erklären, wie es wieder zurück ins "Client" Subnet kommt.
Das werden ich mal in Angriff nehmen um dem VPN Subnet zu erklären, wie es wieder zurück ins "Client" Subnet kommt.
Leider habe ich nun das typische Problem, dass die RTP-Pakete unterwegs verloren gehen.
Sehr verwunderlich das du da 2 Tage suchen musst. Das ist völlig normal, denn im Default macht OpenWRT NAT (IP Adress Translation) im OpenVPN Tunnel. Das NAT Gateway ist dann, wie oben schon richtig vermutet, der Tod der RTP Pakete, da diese dynamische UDP Ports benutzen die dann folglich das NAT Gateway nicht mehr oder nur einseitig passieren können. Das resultiert dann nach einen erfolgreichen SIP Verbindungsaufbau aber dann immer mit nachfolgender Stille oder einseitiger Stille das die Sprache mit RTP transportiert wird.NAT im internen Netz (und dazu gehört auch das Tunnel IP Netz) ist so oder so Unsinn denn wozu sollte es gut sein ? Deshalb solltest du es am OpenWRT am Tunnel Interface auch immer abschalten im Firewall Setup !
Zu beachten ist das das Ganze auch nur klappen kann wenn die pfSense mit dem LAN Port mit der FB verbunden ist. Am WAN Port wird es wegen des dort gemachten NAT und auch wegen des strikten Firewall Regelwerkes niemals klappen.
Fragt sich auch warum man dafür eine pfSense so "vergewaltigt" wenn man davor eh einen aktiven VPN Router betreibt wie die FritzBox. Es wäre doch zielführender und einfacher gewesen mit dem StrongSwan IPsec Package im OpenWRT eine IPsec Verbundung direkt auf die FritzBox aufzumachen statt dieser unglücklichen Frickelei mit einer vollkommen falsch designten (und eigentlich an der Stelle überflüssigen) Firewall. Ein simpler Raspberry Pi hätte bei_OVPN da alternativ allemal auch gereicht. Der hätte dann auch keinerlei Problematiken mit NAT oder Firewalling gemacht an der Stelle.
Aber nungut...warum einfach machen wenn es umständlich mit zig Hürden auch geht....
Als Anmerkung zum Design: Keep it simple. Nach dem Hasen mit der Sonnenbrrille bleibt meist eh nicht viel zu sagen...
Ich habe die quasi gleiche Anforderung mit ner FB auf der Telefonseite und ner PfSense auf der Office-Seite (ohne geNATte) gelöst und das rennt seit 3 Jahren stabil. und das obwohl die Fritte als IP-Client hinter Providerrouter klemmt.
Vorschlag für dein Setting: Mit openWRT zur Fritte VPN oder gleich ne Fritte hinsetzen. Erspart einem das Gefrickel mit dem Schwan und FB.
VG
Buc
Ich habe die quasi gleiche Anforderung mit ner FB auf der Telefonseite und ner PfSense auf der Office-Seite (ohne geNATte) gelöst und das rennt seit 3 Jahren stabil. und das obwohl die Fritte als IP-Client hinter Providerrouter klemmt.
Vorschlag für dein Setting: Mit openWRT zur Fritte VPN oder gleich ne Fritte hinsetzen. Erspart einem das Gefrickel mit dem Schwan und FB.
VG
Buc
Hallo aqui, danke für die ausführliche Beschreibung.
Der Grund warum wir nicht einfach das IPSec der FB benutzen können bzw. warum wir eben nicht einfach einen RaspberryPI ins Rack legen können ist, dass wir dieses Setup- wenn es mit dem Testaufbau tut - für mehr als 35 Mitarbeiter brauchen und noch zwei weitere Standorte an die TKA analog dem Arbeitsplatz daheim anbinden wollen.
Die pfSense wird dann die Rolle des Routers übernehmen und hinter zwei draytek vigor 165 sitzen. Dann liegt das WAN gebridged direkt an der pfSense an.
Ich weiß, dass es aktuell im Client-Modus wenig Sinn macht. Da gebe ich dir auch vollkommen recht. Ich bin gerade dabei die Einstellungen vorzunehmen. Ich habe am OpenWRT jetzt die neue Zone für das VPN erstellt. Anbei meine Einstellungen für die neue Zone.
Ich habe für die Zone den tun0 unter covered devices ausgewählt. Soweit ich weiß braucht man hierfür kein dummy interface mehr anlegen, da das Interface vom OpenVPN gemanaget wird.
Das ein NAT für internen LAN Traffic keinen Sinn macht, stimme ich dir auch zu.
Ich habe auf der pfSense jetzt in den NAT-Einstellungen noch folgendes stehen:
Deaktiviere ich diese beiden Regelen, kann ich die Clients im 172.16.0.0/16er nicht mehr erreichen. Wrs. wegen einer dann fehlenden Route. Das prüfe ich gleich noch einmal.
Das LAN Interface ist folgendermaßen Konfiguriert:
Bei einem vollständigen ausschalten des NAT erreiche ich dir Endpunkte im LAN (172.16.0.0/16) über das VPN nicht mehr. Ich nehme an, hier fehlt dann eine entsprechende Route.
Hier hast du mir den Link zu einem anderen Beitrag geschickt. Der Hilft. Ich werden versuchen die Route entsprechend deinem Bsp. einzurichten. Das der OVPN Client im openWRT sitzt spielt ja hier keine Rolle. Danke schon mal dafür.
Vielen Dank fürs drüber schauen und dir wertvollen Ratschläge.
Der Grund warum wir nicht einfach das IPSec der FB benutzen können bzw. warum wir eben nicht einfach einen RaspberryPI ins Rack legen können ist, dass wir dieses Setup- wenn es mit dem Testaufbau tut - für mehr als 35 Mitarbeiter brauchen und noch zwei weitere Standorte an die TKA analog dem Arbeitsplatz daheim anbinden wollen.
Die pfSense wird dann die Rolle des Routers übernehmen und hinter zwei draytek vigor 165 sitzen. Dann liegt das WAN gebridged direkt an der pfSense an.
Ich weiß, dass es aktuell im Client-Modus wenig Sinn macht. Da gebe ich dir auch vollkommen recht. Ich bin gerade dabei die Einstellungen vorzunehmen. Ich habe am OpenWRT jetzt die neue Zone für das VPN erstellt. Anbei meine Einstellungen für die neue Zone.
Ich habe für die Zone den tun0 unter covered devices ausgewählt. Soweit ich weiß braucht man hierfür kein dummy interface mehr anlegen, da das Interface vom OpenVPN gemanaget wird.
Das ein NAT für internen LAN Traffic keinen Sinn macht, stimme ich dir auch zu.
Ich habe auf der pfSense jetzt in den NAT-Einstellungen noch folgendes stehen:
Deaktiviere ich diese beiden Regelen, kann ich die Clients im 172.16.0.0/16er nicht mehr erreichen. Wrs. wegen einer dann fehlenden Route. Das prüfe ich gleich noch einmal.
Das LAN Interface ist folgendermaßen Konfiguriert:
Bei einem vollständigen ausschalten des NAT erreiche ich dir Endpunkte im LAN (172.16.0.0/16) über das VPN nicht mehr. Ich nehme an, hier fehlt dann eine entsprechende Route.
Hier hast du mir den Link zu einem anderen Beitrag geschickt. Der Hilft. Ich werden versuchen die Route entsprechend deinem Bsp. einzurichten. Das der OVPN Client im openWRT sitzt spielt ja hier keine Rolle. Danke schon mal dafür.
Vielen Dank fürs drüber schauen und dir wertvollen Ratschläge.
warum wir eben nicht einfach einen RaspberryPI ins Rack legen können ist
Dann stellt man eben einen Intel NUC ins Regal. 
Die pfSense wird dann die Rolle des Routers übernehmen
Warum baust du dann nicht dieses Test Setup auch so auf. Kann ja erstmal nur mit einem WAN Port sein aber die pfSense dann nur one armed einzuklinken ist ja etwas Äpel mit Birnen...De facto rennt Voice aber fehlerlos mit der pfSense über einen OpenVPN Link. Kannst du mit einem Softphone wie Phoner oder Phoner Lite auf einem Rechner mit einem Wireshark der dir die SIP und RTP Kommunikatrion anzeigt auch immer selber sehen.
Warum benutzt du einen /16er Prefix ? Hat das historische Gründe oder musst du wirklich 65534 Geräte adressieren dort ?
Ich schaue es mir jetzt mal mit dem Phoner Lite an. Danke für den Tipp. Dann sehe ich wenigstens einma was für Packete wo die Seite wechseln.
Ja das könnte ich tatsächlich einmal so machen. An der jetzigen Fritzbox könnte ich das GAST LAN ohne Policy als WAN Eingang in die pfSense nehmen. Das hätte dann 192.168.179.0/24 anliegen. Das LAN bleibt bei 172.16.0.0/16. Aber das sollte für das aktuelle Problem nichts ändern? Oder liege ich hier falsch?
Das 16er Präfix ist aktuell noch etwas zu groß gedacht. Es wird ein Teil davon als eigenes Subnetz für die Produktion abgehen. Aktuell sind es noch die 16. Wird aber nach dem Umbau Schritt für Schritt angepasst. Es geht eben nur nicht alles auf einmal. Daher eins nach dem anderen
Ich teste jetzt noch einmal mit dem Softphoner und melde mich wenn ich Neuigkeiten haben bzw. wenn es was Neues gibt.
Warum baust du dann nicht dieses Test Setup auch so auf. Kann ja erstmal nur mit einem WAN Port sein aber die pfSense dann nur one armed einzuklinken ist ja etwas Äpel mit Birnen...
Ja das könnte ich tatsächlich einmal so machen. An der jetzigen Fritzbox könnte ich das GAST LAN ohne Policy als WAN Eingang in die pfSense nehmen. Das hätte dann 192.168.179.0/24 anliegen. Das LAN bleibt bei 172.16.0.0/16. Aber das sollte für das aktuelle Problem nichts ändern? Oder liege ich hier falsch?
Warum benutzt du einen /16er Prefix ? Hat das historische Gründe oder musst du wirklich 65534 Geräte adressieren dort ?
Das 16er Präfix ist aktuell noch etwas zu groß gedacht. Es wird ein Teil davon als eigenes Subnetz für die Produktion abgehen. Aktuell sind es noch die 16. Wird aber nach dem Umbau Schritt für Schritt angepasst. Es geht eben nur nicht alles auf einmal. Daher eins nach dem anderen
Ich teste jetzt noch einmal mit dem Softphoner und melde mich wenn ich Neuigkeiten haben bzw. wenn es was Neues gibt.
Wir sind gespannt... 😉
Also der Trace bringt es ans Licht.
Ich habe auf dem Laptop ein Softphone laufen (https://jami.net/download-jami-linux/), welches sich mit einen Test SIP Account auf der TKA verbindet. Der Laptop hängt in dem TP-Link Netz mit der 192.168.1.0/24 mit der IP 192.168.1.122/24 und hat jetzt - dank deines Links weiter oben - auch ohne NAT auf der pfSense mit einer statischen Route auf der FB im CorpLAN eine funktionierende Verbindung durch den Tunnel.
ABER: Gehe ich richtig in der Annahme, dass die 192.168.10.2/24 (VPN Tunnel Network) in diesen tcpdumps nicht auftauchen sollte? Genau diese IP Sehe ich auf den Servern, TKA, etc. im CorpLAN. Das heißt aber doch, dass auf der OpenWRT VPN Ausgangsseite im Tunnel noch ein NAT aktiv ist?
Das OpenWRT habe ich so eingestellt, wie oben beschrieben. Woran könnte es noch liegen, dass anstelle der 192.168.1.122 das Gateway des VPN Tunnel-Netzwerks gezogen wird?
Ich habe auf dem Laptop ein Softphone laufen (https://jami.net/download-jami-linux/), welches sich mit einen Test SIP Account auf der TKA verbindet. Der Laptop hängt in dem TP-Link Netz mit der 192.168.1.0/24 mit der IP 192.168.1.122/24 und hat jetzt - dank deines Links weiter oben - auch ohne NAT auf der pfSense mit einer statischen Route auf der FB im CorpLAN eine funktionierende Verbindung durch den Tunnel.
ABER: Gehe ich richtig in der Annahme, dass die 192.168.10.2/24 (VPN Tunnel Network) in diesen tcpdumps nicht auftauchen sollte? Genau diese IP Sehe ich auf den Servern, TKA, etc. im CorpLAN. Das heißt aber doch, dass auf der OpenWRT VPN Ausgangsseite im Tunnel noch ein NAT aktiv ist?
Das OpenWRT habe ich so eingestellt, wie oben beschrieben. Woran könnte es noch liegen, dass anstelle der 192.168.1.122 das Gateway des VPN Tunnel-Netzwerks gezogen wird?
Gehe ich richtig in der Annahme, dass die 192.168.10.2/24 (VPN Tunnel Network) in diesen tcpdumps nicht auftauchen sollte?
Ja, das siehst du ganz genau richtig ! Sofern du diese IP siehst hast du entweder direkte Clients am werkeln also Endgeräte die sich als Clients einwählen und im Netz arbeiten.Sollten die nicht vorkommen und du rein ein Site to Site VPN machen ist das ein gesichertes Indiz dafür das dort NAT gemacht wird.
Wenn du z.B. ein Softphone im remoten .1.0er Netz hast und eine SIP Connection aufmachst und die taucht am Voice Server mit einer .10.x IP auf ist das eindeutig.
Das kannst du ja eindeutig an den SIP Credentials erkennen wer das ist.
Noch fataler wäre es das .10.0er Netz wird noch im Restnetz irgendwo aktiv genutzt. Die Wahl dieses Netzes für das Tunnelnetz ist nicht besonders vorteilhaft. Eine etwas "exotischere" IP wäre ggf. sinnvoller um Überschneiodungen sicher zu verhindern.
Aber das NAT ist definitiv dein Voice Killer.
