Feste-IP mit Raspberry Pi und OpenVPN. Keine Telefonie durch den Tunnel. Fritzbox
Hallo Zusammen,
ich stehe leider vor dem Problem, dass meine Telefonie von der Fritzbox nicht durch den Tunnel geht.
Ich habe über meinen Provider Zuhause eine IPv6 Adresse.
Per "Feste-IP.net" habe ich einen Zugang von IPv4 auf IPv6 bei mir Zuhause. Das ganze läuft über OpenVPN.
Ich komme vom Mobilfunknetz oder von beliebigen andern IPv4 Adressen auf mein IPv6 OpenVPN Netz.
Ich habe bisher keine Problem beim Verbinden.
Ich bin im Mobilfunknetz, logge mich per OpenVPN ein und bin komplett im Netzwerk.
Rufe ich die Fritz!App Fon auf, leuchten auch beide Anzeigen grün.
Allerdings, wenn ich versuche zu Telefoniere, klingelt es zwar bei dem angerufenem, aber ich bekomme kein Klingeln und auch wenn der andere den Ruf annimmt, ist kein Gespräch zu hören.
Ich habe natürlich auch schon im Internet recherchiert und bin auf diesen Beitrag gestoßen:
Externer Zugriff über VPN - Telefonie mit Fritzbox funktionert nicht - kein Ton (Synology, OpenVPN)
Habe natürlich gleich das Routing versucht, was leider zur folge hatte, dass mein OpenVPN Client keine Verbindung mehr aufbauen konnte.
Folgendes Equipment ist vorhanden:
- IPv6 Zugang über den Provider
- Raspberry Pi mit OpenVPN (IP 192.168.77.50, Standardport von OpenVPN geändert)
- "Übersetzer" von Feste-IP.net. Auch mit dem geändertem Port für OpenVPN. (Verbindung funktioniert!)
- Fritz!Box mit MyFritz!Freigabe und mit IPv6 Freigabe zum Raspberry Pi (ist nötig wegen IPv6 und IPv4)
Ich weiß nun nicht, ob es Probleme bezüglich des Routing gibt, da mein Raspberry mit der ganzen Sache zu tun hat, oder ob es an eimen komplett andern Problem liegt.
Vielleicht hatte schon mal jemand so einen Fall und kann mir hier weiterhelfen.
Vielen Dank
ich stehe leider vor dem Problem, dass meine Telefonie von der Fritzbox nicht durch den Tunnel geht.
Ich habe über meinen Provider Zuhause eine IPv6 Adresse.
Per "Feste-IP.net" habe ich einen Zugang von IPv4 auf IPv6 bei mir Zuhause. Das ganze läuft über OpenVPN.
Ich komme vom Mobilfunknetz oder von beliebigen andern IPv4 Adressen auf mein IPv6 OpenVPN Netz.
Ich habe bisher keine Problem beim Verbinden.
Ich bin im Mobilfunknetz, logge mich per OpenVPN ein und bin komplett im Netzwerk.
Rufe ich die Fritz!App Fon auf, leuchten auch beide Anzeigen grün.
Allerdings, wenn ich versuche zu Telefoniere, klingelt es zwar bei dem angerufenem, aber ich bekomme kein Klingeln und auch wenn der andere den Ruf annimmt, ist kein Gespräch zu hören.
Ich habe natürlich auch schon im Internet recherchiert und bin auf diesen Beitrag gestoßen:
Externer Zugriff über VPN - Telefonie mit Fritzbox funktionert nicht - kein Ton (Synology, OpenVPN)
Habe natürlich gleich das Routing versucht, was leider zur folge hatte, dass mein OpenVPN Client keine Verbindung mehr aufbauen konnte.
Folgendes Equipment ist vorhanden:
- IPv6 Zugang über den Provider
- Raspberry Pi mit OpenVPN (IP 192.168.77.50, Standardport von OpenVPN geändert)
- "Übersetzer" von Feste-IP.net. Auch mit dem geändertem Port für OpenVPN. (Verbindung funktioniert!)
- Fritz!Box mit MyFritz!Freigabe und mit IPv6 Freigabe zum Raspberry Pi (ist nötig wegen IPv6 und IPv4)
Ich weiß nun nicht, ob es Probleme bezüglich des Routing gibt, da mein Raspberry mit der ganzen Sache zu tun hat, oder ob es an eimen komplett andern Problem liegt.
Vielleicht hatte schon mal jemand so einen Fall und kann mir hier weiterhelfen.
Vielen Dank
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 302561
Url: https://administrator.de/forum/feste-ip-mit-raspberry-pi-und-openvpn-keine-telefonie-durch-den-tunnel-fritzbox-302561.html
Ausgedruckt am: 02.04.2025 um 02:04 Uhr
10 Kommentare
Neuester Kommentar
aber ich bekomme kein Klingeln und auch wenn der andere den Ruf annimmt, ist kein Gespräch zu hören.
Das deutet immer darauf hin das SIP oder RTP (SIP=Verbindungsaufbau, RTP=Voice Daten) irgendwo in einer Firewall hängen bleiben.SIP nutzt dynamische Ports und das muss die Firewall berücksichtigen.
Hier findest du Hinweise wie das SIP Port Forwarding richtig zu customizen ist:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
(Kapitel: VoIP bzw. Telefonie mit FritzBox oder Anlage hinter Firewall )
Nimm im Zweifel einen Wireshark Sniffer und sieh dir den VoIP Flow an !
Wie ist dein OVPN Server konfiguriert ?? Machst du Split Tunneling also das du nur einzig dein remotes Netzwerk über den Tunnel routetst oder redirectes du allen Traffic dann in den Tunnel ?
Das wäre noch wichtig zu wissen.
Das VPN selber wird es sicher nicht sein, denn sonst würdest du im remoten LAN nichts erreichen können.
Zu 98% lokale Firewall am Client, die SIP oder RTP Traffic vom Fremdnetz (VPN) blockt.
Habe natürlich gleich das Routing versucht,
Bahnhof ??? OpenVPN ist immer Routing !! Guckst du hier:OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Ich weiß nun nicht, ob es Probleme bezüglich des Routing gibt, da mein Raspberry mit der ganzen Sache zu tun hat,
Nein, natürlich nicht wenn man es richtig konfiguriert:Siehe Tutorial oben oder auch hier:
http://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ... usw.

Ich schätze mal das er den Traffic der OpenVPN-Clients am Raspberry NATet, das wäre für mich jetzt auf den ersten Blick ohne Schaubild des Netzes der Grund das die Pakete dort hängen bleiben, wenn dem so ist, würde ich statt NAT stattdessen eine statische Route in der Fritte auf den Raspberry zeigen lassen.
Also mehr detaillierte Infos zur Config auf den Geräten und man kann dir auch zielgerichtet helfen.
Gruß jodel32
Also mehr detaillierte Infos zur Config auf den Geräten und man kann dir auch zielgerichtet helfen.
Gruß jodel32
Ich schätze mal das er den Traffic der OpenVPN-Clients am Raspberry NATet
Das wäre ein Grund und natürlich tödlich. Zudem ist es unsinnig den Tunnel internen Traffic zu NATen.Aber was Kollege jodel32 sagt ist richtig, ohne weitere Details dazu (z.B. OVPN Server config File) kommen wir nicht weiter...
Macht es einen Sinn das du dich freiwillig ausschnüffeln lässt von Google weil du deren DNS verwendest ? Für intelligente Netzwerker ein NoGo.
Das ist kontraproduktiv sowohl aus persönlicher Sicherheit als auch Performance. Sinnvoller ist es den lokalen DNS zu pushen.
Das hat aber ursächlich mit dem Voice Problem nichts zu tun sondern ist nur ein guter Rat.
Das interne 10.8.0.0er Netz ist doch direkt dran am RasPi als virtuelles Interface. Somit "kennt" der RasPi also dieses Netz und auch alle Interfaces und damit auch IP Netze die direkt an ihm angeschlossen sind !
Es ist also völlig unsinnig bzw. überflüssig ihm das nochmals mit einer Route bekannt zu machen. Was soll das bringen...?
Ein netstat -r am RasPi zeigt dir das auch sofort. Identisch das Kommando beim aktiven Client (unixoides OS), da kannst du dann alle Routen sehen die durch den Tunnel gehen (route print bei Winblows)
Allerdings ist das bei dir mit deiner Server Konfig auf deinen Clients überflüssig, denn mit push "redirect-gateway def1 bypass-dhcp" biegst du ja eh das Default Gateway bei den Clients zwangsweise komplett auf den Tunnel, so das sämtlicher Client Traffic über den Tunnel geroutet wird.
In sofern spielen dann einzelne Routen eh keinerlei Rolle mehr.
Voice Traffic (SIP und RTP) müsste also vom Client immer und unter jeden Umständen in den Tunnel geroutet werden.
ACHTUNG:
Essentiell wichtig ist das du natürlich eine statische Route auf deiner FritzBox in das 10er Netz via RasPi LAN IP eingetragen hast !!
Die muss das 10er Netz natürlich kennen.
Dort muss im Setup unter Routing stehen: Zielnetz: 10.8.0.0, Maske: 255.255.255.0, Gateway: 192.168.77.50
(Wobei wir hier jetzt annehmen das die 192.168.77.0 /24 dein lokales Netz ist in dem sich FB .1 und RasPi .50 befinden ?!)
Es wäre mal wichtig zu wissen ob der Voice Traffic wenigstens im lokalen Netzwerk ankommt.
Installiere dir mal tcpdump auf dem RasPi mit apt-get install tcpdump und sniffer mal ob du SIP Traffic dort sehen kannst: tcpdump port 5060
Das zeigt dir SIP Traffic beim Voice Verbindungsaufbau an. Ggf. kannst du mit dem -i Parameter noch den Port mitgeben.
Sprache wird mit RTP übertragen. Ggf. solltest du also mal allen Voice Traffic der zur FritzBox geht mitsniffern um zu sehen was da passiert intern.
tcpdump src 2.3.4.5 oder tcpdump dst 2.3.4.5 Wobei 2.3.4.5 die lokale LAN IP deiner FB hier ist.
Das ist kontraproduktiv sowohl aus persönlicher Sicherheit als auch Performance. Sinnvoller ist es den lokalen DNS zu pushen.
Das hat aber ursächlich mit dem Voice Problem nichts zu tun sondern ist nur ein guter Rat.
Ich habe versucht, die 10.8.0.0 bzw. die 10.8.0.6 die am Client ankommt auf die interne IP/Gateway von dem Raspberry zu Routen.
Sory aber das ist routingtechnischer Quatsch !Das interne 10.8.0.0er Netz ist doch direkt dran am RasPi als virtuelles Interface. Somit "kennt" der RasPi also dieses Netz und auch alle Interfaces und damit auch IP Netze die direkt an ihm angeschlossen sind !
Es ist also völlig unsinnig bzw. überflüssig ihm das nochmals mit einer Route bekannt zu machen. Was soll das bringen...?
Ein netstat -r am RasPi zeigt dir das auch sofort. Identisch das Kommando beim aktiven Client (unixoides OS), da kannst du dann alle Routen sehen die durch den Tunnel gehen (route print bei Winblows)
Allerdings ist das bei dir mit deiner Server Konfig auf deinen Clients überflüssig, denn mit push "redirect-gateway def1 bypass-dhcp" biegst du ja eh das Default Gateway bei den Clients zwangsweise komplett auf den Tunnel, so das sämtlicher Client Traffic über den Tunnel geroutet wird.
In sofern spielen dann einzelne Routen eh keinerlei Rolle mehr.
Voice Traffic (SIP und RTP) müsste also vom Client immer und unter jeden Umständen in den Tunnel geroutet werden.
ACHTUNG:
Essentiell wichtig ist das du natürlich eine statische Route auf deiner FritzBox in das 10er Netz via RasPi LAN IP eingetragen hast !!
Die muss das 10er Netz natürlich kennen.
Dort muss im Setup unter Routing stehen: Zielnetz: 10.8.0.0, Maske: 255.255.255.0, Gateway: 192.168.77.50
(Wobei wir hier jetzt annehmen das die 192.168.77.0 /24 dein lokales Netz ist in dem sich FB .1 und RasPi .50 befinden ?!)
Es wäre mal wichtig zu wissen ob der Voice Traffic wenigstens im lokalen Netzwerk ankommt.
Installiere dir mal tcpdump auf dem RasPi mit apt-get install tcpdump und sniffer mal ob du SIP Traffic dort sehen kannst: tcpdump port 5060
Das zeigt dir SIP Traffic beim Voice Verbindungsaufbau an. Ggf. kannst du mit dem -i Parameter noch den Port mitgeben.
Sprache wird mit RTP übertragen. Ggf. solltest du also mal allen Voice Traffic der zur FritzBox geht mitsniffern um zu sehen was da passiert intern.
tcpdump src 2.3.4.5 oder tcpdump dst 2.3.4.5 Wobei 2.3.4.5 die lokale LAN IP deiner FB hier ist.
Sobald ich das eintrage und versuche die Verbindung neu aufzubauen, scheitert die Verbindung bzw. der Verbindungsaufbau.
Technisch kann das niemals sein !Wie soll die FB denn sonst wissen wie sie die 10er IP Adressen routen soll ??
Ohne diese statische Route hat die FB einzig nur ihre Default Route die zum Provider zeigt. Ohne diese statische Route ins 10er OVPN Netz muss die FB somit dann die 10er IPs zum ISP senden wo sie auf Nimmerwiedersehen im Nirwana veschwinden, denn das 10er Netz ist ein privates RFC 1918 IP Netz was im Internet nicht geroutet wird. ISP filtern das gnadenlos in den Datenmülleimer.
Es hört sich an als ob generell bei dir was faul ist im Netz...?!
Logisch und technisch ist es nicht zu erklären warum es ohne Route klappt mit syntaktisch richtiger Route aber nicht ? Es sollte genau andersrum sein !!
Was bei dir falsch ist ist die Tatsache das du 2 IP netzwerke am RasPi auf dem eth0 Interface hast !!! 172.16.254.0 und 192.168.77.0
Das darf so niemals sein !
Ferner sieht es so aus als ob der RasPi seine Hostadresse per DHCP bezieht. Bei einem Server ist das ein NoGo !
Einzige Ausnahme du konfigurierst die IP Adresse im DHCP Server der FB fest bezogen auf die Mac Adresse des RasPi so das der immer auf Basis seiner Mac Adresse eine feste IP bekommt.
Die 2 IP Netze sind aber definitiv fehlerhaft dort !
Hier kann ich es mir nur vorstellen, dass der RasPi in diesem Fall alles regelt
Nein, das ist Blödsinn. Du musst ihm schon sagen WAS er regeln soll. Von allein macht er das nicht !Warum das so ist, lässt sich mir nicht erklären.
Das solltest du aber ganz schnell klären !!Der rasPi bläst ja ein DHCP Broadcast ins Netz und irgendwas antwortet mit dem 172er Netz. Das 192er Netz ist vermutlich die FB, richtig ??
Nimm dir einen Wireshark Sniffer (oder tcpdump) und trace den DHCP Traffic des RasPi mit, dann weisst du woher das kommt.
Zeigt aber das etwas grundsätzlich oberfaul ist in deinem Netz und besonders im IP Adressing und das solltest du de facto erstmal fixen bevor wir hier weitermachen.
Der RasPi darf niemals 2 IPs haben am eth0 Port.
Um ganz sicher zu gehen das der Network Manager da keinen Mist macht editiere die /etc/dhcpcd.conf Datei mit dem nano Editor und füge am Ende das Kommando denyinterfaces eth0
dort ein.
Dann rebootest du den RasPi mit reboot oder sudo shutdown -r now und machst nach dem Reboot dann mal ein ifconfig
Dann dürfte dort nur noch eine einzige IP Adresse auftauchen, nämlich die die er von der FB bekommt !!