15
Externer Zugriff über VPN - Telefonie mit Fritzbox funktionert nicht - kein Ton (Synology, OpenVPN)
Hallo zusammen,
ich hätte mal wieder ein Problem, ich hoffe man kann mir hier helfen
Folgendes Szenario:
- Fritzbox 7390 (IP 192.168.11.1) DnyDNS eingerichtet
Telefoniegerät ist eingerichtet
- Synology DS213+ (IP 192.168.11.26)
OpenVPN-Server, Dynamische IP 10.8.0.0
- Android-Phone
mit OpenVPN-Client, Verbindung steht (IP 10.8.0.6)
Zoiper SIP-Client, Verbindung zu Fritzbox steht auch
Das Problem ist, ich kann zwar wählen und der Anruf wird auch aufgebaut, aber es ist kein Ton zu hören.
Wenn ich nun in der Fritzbox in den Detailinformation für die Sprachübertragung nachschaue, steht bei dem getätigten Telefonat bei der Gegenstelle, also ein Android-Phone, die IP 10.8.0.6.
Nutze ich integrierte VPN-Funktion der Fritzbox, funktioniert die Telefonie ohne Probleme von extern.
Ich vermute das es irgendwas mit der IP-Bereich von OpenVPN zu tun hat. Kann mir da jemand auf die Sprünge helfen umd das Problem zu lösen?
Ich hoffe ich hab nix vergessen und es ist verständlich wie ich es geschieben habe, falls ihr noch Info´s brauch einfach melden
Vielen Dank.
Mfg Pretre
ich hätte mal wieder ein Problem, ich hoffe man kann mir hier helfen
Folgendes Szenario:
- Fritzbox 7390 (IP 192.168.11.1) DnyDNS eingerichtet
Telefoniegerät ist eingerichtet
- Synology DS213+ (IP 192.168.11.26)
OpenVPN-Server, Dynamische IP 10.8.0.0
- Android-Phone
mit OpenVPN-Client, Verbindung steht (IP 10.8.0.6)
Zoiper SIP-Client, Verbindung zu Fritzbox steht auch
Das Problem ist, ich kann zwar wählen und der Anruf wird auch aufgebaut, aber es ist kein Ton zu hören.
Wenn ich nun in der Fritzbox in den Detailinformation für die Sprachübertragung nachschaue, steht bei dem getätigten Telefonat bei der Gegenstelle, also ein Android-Phone, die IP 10.8.0.6.
Nutze ich integrierte VPN-Funktion der Fritzbox, funktioniert die Telefonie ohne Probleme von extern.
Ich vermute das es irgendwas mit der IP-Bereich von OpenVPN zu tun hat. Kann mir da jemand auf die Sprünge helfen umd das Problem zu lösen?
Ich hoffe ich hab nix vergessen und es ist verständlich wie ich es geschieben habe, falls ihr noch Info´s brauch einfach melden
Vielen Dank.
Mfg Pretre
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: 234436
Url: https://administrator.de/contentid/234436
Printed on: April 19, 2024 at 06:04 o'clock
15 Comments
Latest comment
Du betreibst das OpenVPN Gateway hinter einem NAT Router (Fritzbox). Alle deine Endgeräte im Netz haben aber die Fritzbox als Default Gateway nicht aber der VPN Client.
Die Fritzbox weiss also ohne eine statische Route nicht WO sich dein 10.8.0.0er VPN Netz befindet. Folglich kann auch die Voice RTP Session nicht direkt zwischen den Endgeräten aufgebaut werden weil die FB nicht weiss das sie das 10er Netz über deinen OVPN Gateway erreichen muss.
Sie routet Pakete ohne statische Route fürs VPN dann ins Internet wo sie im Nirwana verschwinden mit dem Ergebnis...kein Ton ! Müsstest du auch sehen wenn du vom VPN Client versuchst andere Clients im 192.168.11.0er LAN zu pingen, was ohne diese statische Route fehlschlägt. Logisch...wenn man nachdenkt.
Das hiesige OVPN Tutorial OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router beschreibt annähernd dein Szenario im Kapitel "...hinter NAT Router" nur das das bei dir eben nur mit einem Port gemacht ist statt mit 2 wie im Tutorial.
Fazit um das Problem schnell zu lösen:
Trage eine zusätzliche statische IP Route in deiner Fritzbox ein ala:
Zielnetz: 10.8.0.0, Maske: 255.255.255.0, Gateway: 192.168.11.26 (Achtung: Geht davon aus das dein 10er VPN Netz eine 24 Bit Maske hat !!)
Fertig.
Das sollte dein Problem sofort lösen.
Die Fritzbox weiss also ohne eine statische Route nicht WO sich dein 10.8.0.0er VPN Netz befindet. Folglich kann auch die Voice RTP Session nicht direkt zwischen den Endgeräten aufgebaut werden weil die FB nicht weiss das sie das 10er Netz über deinen OVPN Gateway erreichen muss.
Sie routet Pakete ohne statische Route fürs VPN dann ins Internet wo sie im Nirwana verschwinden mit dem Ergebnis...kein Ton ! Müsstest du auch sehen wenn du vom VPN Client versuchst andere Clients im 192.168.11.0er LAN zu pingen, was ohne diese statische Route fehlschlägt. Logisch...wenn man nachdenkt.
Das hiesige OVPN Tutorial OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router beschreibt annähernd dein Szenario im Kapitel "...hinter NAT Router" nur das das bei dir eben nur mit einem Port gemacht ist statt mit 2 wie im Tutorial.
Fazit um das Problem schnell zu lösen:
Trage eine zusätzliche statische IP Route in deiner Fritzbox ein ala:
Zielnetz: 10.8.0.0, Maske: 255.255.255.0, Gateway: 192.168.11.26 (Achtung: Geht davon aus das dein 10er VPN Netz eine 24 Bit Maske hat !!)
Fertig.
Das sollte dein Problem sofort lösen.
Zitat von @aqui:
Trage ein zusätzliche statische IP Route in deiner Fritzbox ein ala:
Zielnetz: 10.8.0.0, Maske: 255.255.255.0, Gateway: 192.168.11.26 (Achtung: Geht davon aus das dein 10er VPN Netz eine 24 Bit
Maske hat !!)
Trage ein zusätzliche statische IP Route in deiner Fritzbox ein ala:
Zielnetz: 10.8.0.0, Maske: 255.255.255.0, Gateway: 192.168.11.26 (Achtung: Geht davon aus das dein 10er VPN Netz eine 24 Bit
Maske hat !!)
Hallo Aqui,
Vielen Dank für deine, wie schon so oft, schnelle kompetente Hilfe - Es funktioniert.
DANKE!
MfG
Pretre
Hört sich gut an....
Ist auch ein Wink das o.a. Tutorial mal in der NAT Rubrik um dieses "one armed" VPN Szenario zu erweitern
(Was mit diesem Bild dann erledigt ist )
Das zeigt das Prinzip:
Der interne VPN Server egal ob auf einem extra Rechner, Raspberry oder auf einem NAS und die zwingend erforderliche statische Route auf dem Internet Router für das interne VPN Netzwerk !
Ist auch ein Wink das o.a. Tutorial mal in der NAT Rubrik um dieses "one armed" VPN Szenario zu erweitern
(Was mit diesem Bild dann erledigt ist
)Das zeigt das Prinzip:
Der interne VPN Server egal ob auf einem extra Rechner, Raspberry oder auf einem NAS und die zwingend erforderliche statische Route auf dem Internet Router für das interne VPN Netzwerk !
Hi aqui,
habe mich gerade angemeldet um einfach Danke zu sagen. Deine Antwort hat auch mein Problem gelöst!
Nutze zwar nicht OVPN sonder L2TP der DiskStation, aber das mein Fehler durch die fehlende Route entsteht, auf die Idee bin ich einfach nicht gekommen.
Liebe Grüße und nur das beste für solch nette Menschen wie dich!
habe mich gerade angemeldet um einfach Danke zu sagen. Deine Antwort hat auch mein Problem gelöst!
Nutze zwar nicht OVPN sonder L2TP der DiskStation, aber das mein Fehler durch die fehlende Route entsteht, auf die Idee bin ich einfach nicht gekommen.
Liebe Grüße und nur das beste für solch nette Menschen wie dich!
Danke für die Blumen ! Immer gerne wieder
Ich habe – glaube ich – ein ganz ähnliches Problem... VOIP läuft auf der Fritzbox, OpenVPN Server auf einer Synology. Jetzt möchte ich mich per VPN mit dem LAN verbinden (Tunnelblick am Mac) und VOIP nutzen mit einer Softphone App. Mit den folgenden Routen funktioniert das einwandfrei:
Allerdings möchte ich nicht den gesamten Traffic durch das VPN routen. Wenn ich die entsprechenden Routen rausnehme funktioniert VOIP aber leider nicht mehr. Ich kann mich dann zwar registrieren, auch einen Anruf absetzen, aber hören tu ich nix. In keine Richtung. Unten nochmal die Routing Tabelle mit der dieses Szenario auftritt. Wo könnte das Problem sein?
Internet:
Destination Gateway Flags Netif Expire
0/1 192.168.30.5 UGSc utun3
default 172.20.10.1 UGSc en6
33.201.46.101/32 172.20.10.1 UGSc en6 <----- Öffentliche IP Adresse des VPN Server (geändert)
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
128.0/1 192.168.30.5 UGSc utun3
169.254 link#16 UCS en6 !
172.20.10/28 link#16 UCS en6 !
172.20.10.1/32 link#16 UCS en6 !
172.20.10.1 1a:65:90:c2:2a:64 UHLWIir en6 1010
172.20.10.5/32 link#16 UCS en6 !
172.20.10.5 1a:65:90:2c:53:1f UHLWI lo0
172.20.10.15 ff:ff:ff:ff:ff:ff UHLWbI en6 !
192.168.30 192.168.30.5 UGSc utun3
192.168.30.1/32 192.168.30.5 UGSc utun3
192.168.30.5 192.168.30.6 UHr utun3
192.168.32 192.168.30.5 UGSc utun3
224.0.0/4 link#16 UmCS en6 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI en6
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en6
255.255.255.255/32 link#16 UCS en6 !
255.255.255.255 ff:ff:ff:ff:ff:ff UHLWbI en6 !Allerdings möchte ich nicht den gesamten Traffic durch das VPN routen. Wenn ich die entsprechenden Routen rausnehme funktioniert VOIP aber leider nicht mehr. Ich kann mich dann zwar registrieren, auch einen Anruf absetzen, aber hören tu ich nix. In keine Richtung. Unten nochmal die Routing Tabelle mit der dieses Szenario auftritt. Wo könnte das Problem sein?
Internet:
Destination Gateway Flags Netif Expire
default 172.20.10.1 UGSc en6
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
169.254 link#16 UCS en6 !
172.20.10/28 link#16 UCS en6 !
172.20.10.1/32 link#16 UCS en6 !
172.20.10.1 1a:65:90:c2:2a:64 UHLWIir en6 1052
172.20.10.5/32 link#16 UCS en6 !
172.20.10.5 1a:65:90:2c:53:1f UHLWI lo0
172.20.10.15 ff:ff:ff:ff:ff:ff UHLWbI en6 !
192.168.30 192.168.30.5 UGSc utun3
192.168.30.1/32 192.168.30.5 UGSc utun3
192.168.30.5 192.168.30.6 UH utun3
192.168.32 192.168.30.5 UGSc utun3
224.0.0/4 link#16 UmCS en6 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI en6
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en6
255.255.255.255/32 link#16 UCS en6 !
255.255.255.255 ff:ff:ff:ff:ff:ff UHLWbI en6 !
Vielleicht hilft das:
OpenVPN - Erreiche Netzwerk hinter Client nicht
OpenVPN - Erreiche Netzwerk hinter Client nicht
Bei mir ging das Telefonieren auch nicht habe jetzt das auch eingetragen (Zielnetz: 10.8.0.0, Maske: 255.255.255.0, Gateway: 192.168.178.36). Ich kann jetzt zumindest in die eine Richtung sprechen nur in die andere nicht. Woran kann das liegen?
Ist meist NAT und/oder falsche Firewall Regeln. Die Voice Daten werden in RTP Frames eingepackt. RTP nutzt dynamische UDP Ports die dann ohne entsprechendes ALG auf dem NAT Device häufig in der Firewall hängen bleiben.
Du musst also, sofern du kein ALG hast, die entsprechende RTP UDP Portrange im NAT freischalten die dein Provider nutzt damit solche Frames durchgehen.
Einfacher ist immer ein STUN Gateway zu nutzen sofern der Voice Provider das anbietet, was aber die meisten tun. Damit erledigt sich dann die NAT Problematik.
Wenn sich dein o.a. Problem auf dein OpenVPN_Umfeld bezieht kannst du unten an deinen falschen iptables Einstellungen sehen wo das Problem bei dir ist ! Du machst unsinnigerweise NAT im VPN Tunnel. Das ist natürlich Blödsinn, denn das kostet nicht nur Performance sondern schafft dir auch diese RTP problematiken bei Voice. Logischerweise NATet man niemals seine lokalen Netze die man über VPN koppelt. Mit NAT ist ein transparentes Routing beider Seiten durch die dann aktive NAT Firewall unmöglich.
Schalte das aus, dann klappt das auch sofort.
Du musst also, sofern du kein ALG hast, die entsprechende RTP UDP Portrange im NAT freischalten die dein Provider nutzt damit solche Frames durchgehen.
Einfacher ist immer ein STUN Gateway zu nutzen sofern der Voice Provider das anbietet, was aber die meisten tun. Damit erledigt sich dann die NAT Problematik.
Wenn sich dein o.a. Problem auf dein OpenVPN_Umfeld bezieht kannst du unten an deinen falschen iptables Einstellungen sehen wo das Problem bei dir ist ! Du machst unsinnigerweise NAT im VPN Tunnel. Das ist natürlich Blödsinn, denn das kostet nicht nur Performance sondern schafft dir auch diese RTP problematiken bei Voice. Logischerweise NATet man niemals seine lokalen Netze die man über VPN koppelt. Mit NAT ist ein transparentes Routing beider Seiten durch die dann aktive NAT Firewall unmöglich.
Schalte das aus, dann klappt das auch sofort.
Ich verstehe nur Bahnhof leider und ja es geht um die Konfiguration hier
Ja, genau. Und dort machst du ja sinnloserweise NAT im VPN Tunnel (sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE)
Genau dieser überflüssige Unsinn triggert dein RTP Problem. Es ist doch völlig unsinnig bei eigenen internen LANs im Tunnel selber noch eine IP Adress Translation zu machen. Was sollte der tiefere Sinn davon sein ?
Vergiss also den ganzen Unsinn mit den iptables.
Genau dieser überflüssige Unsinn triggert dein RTP Problem. Es ist doch völlig unsinnig bei eigenen internen LANs im Tunnel selber noch eine IP Adress Translation zu machen. Was sollte der tiefere Sinn davon sein ?
Vergiss also den ganzen Unsinn mit den iptables.
Ich hatte das eingetragen um den Raspberry als Gateway zu verwenden. Ich habe in den Wlan Einstellungen die IP-Adresse des Gateways vom Raspberry eingetragen und hatte dann immer zugriff auf beide Netze. Ich habe die NAT Zeile entfernt und jetzt geht das telefonieren in beide Richtungen, wenn ich eine vpn Verbindung auf dem Handy direkt aufbaue. Wäre es auch möglich ohne vpn nur über das Gateway? Die Verbindung steht in der app aber man hört wieder auf beiden Seiten nichts wäre ja wieder ein fehler von route. Ich weiß nur nicht welche ich eintragen muss im 10.1.1.X Netzwerk habe paar versucht ohne erfolg.
Das ist aber richtig ?
# VPN Gateway
sudo iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
#test
# NAT the VPN client traffic to the internet
#sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEDas ist aber richtig ?
# VPN Gateway
sudo iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPTWäre es auch möglich ohne vpn nur über das Gateway?
Ja natürlich, das klappt auch. Es ist nur wichtig das der VoIP Client den SIP Server erreichen kann IP technisch.Installiere dir die HE Tools
https://apps.apple.com/de/app/he-net-network-tools/id858241710
https://play.google.com/store/apps/details?id=net.he.networktools&hl ...
Damit kannst du die IP Connectivity vom Smartphone zum Gateway wasserdicht testen.
Das ist aber richtig ?
Wenn das ein interner VPN Server ist, dann kannst du die iptables Einstellungen ganz vergessen. Bei internen Netzen benötigst du die gar nicht.Siehe auch hier.
Ich habe jetzt die Routingtabelle in der Frtiz!Box angepasst und kann Telefonieren ohne vpn auf dem Handy. Danke noch mal für deine Hilfe.
👍
Case closed !
Case closed !
