15
Openvpn-O.K, Sip-O.K, ausgehende Gespräche laufen aber
Hallo zusammen.
Ich habe im Heimnetz einen OpenvpnServer nach folgender Anleitung eingerichtet:
https://www.kuketz-blog.de/pivpn-raspberry-pi-mit-openvpn-raspberry-pi-t ...
Perfekt! Eigentlich läuft alles.
Nur jetzt wollte ich mir für den nächsten Urlaub ein Telefon einrichten mit dem ich jederzeit erreichbar bin über die Telefonnummer Zuhause.
Auf dem Telefon (Auerswald D-210) ist die .openvpn config des Raspberry hinterlegt und der Sipaccount der Fritzbox.
VPN Verbindung steht. Sipaccount ist registriert. Rufe ich nun meine Festnetznummer an (Telefon befindet sich nun in einem anderen Netzwerk - Beim Nachbarn)
Funktioniert alles PERFEKT ! ! ! Sprachqualität ist TOP
Versuche ich nun aber ein Gespräch ausgehend von diesem Telefon, funktioniert der Rufaufbau ganz normal und der Anruf kommt an, allerdings kann weder ich noch der andere irgendwas hören. Legt die Gegenstelle auf oder ich,, wird das Gespräch auch direkt beendet am anderen Gerät. Also Grundsätzlich läuft es ja aber man kann halt nix hören.
Gibt es dafür eine logische Erklärung?
Ich habe mal am Pi ein route -n gemacht:
pi@raspberry:~ $ route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 202 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.2.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
die Serverconfig vom PiVPN sieht wie folgt aus:
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/raspberryxxx.crt
key /etc/openvpn/easy-rsa/pki/private/raspberryxxx.key
dh none
ecdh-curve secp521r1
topology subnet
server 10.8.0.0 255.255.255.0
push "dhcp-option DNS 8.8.8.8"
#push "block-outside-dns"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
Grundsätzlich sollten Gespräche doch in alle Richtungen funktionieren?
Wäre das Routing falsch, dann würde das Gespräche ja erst überhaupt nicht aufgebaut.
Eine Firewall ist nicht vorhanden. Daran sollte es also schon einmal nicht liegen.
Ich bin leider kein Profi, weder im Netzwerk noch bei Voip. Von daher würde ich mich sehr über Informationen freuen, wie sowas sein kann?!
(Ohne VPN Verbindung funktioniert das Telefon bei mir Zuhause problemlos in beide Richtungen)
Vielen Dank im Voraus
Mike
Ich habe im Heimnetz einen OpenvpnServer nach folgender Anleitung eingerichtet:
https://www.kuketz-blog.de/pivpn-raspberry-pi-mit-openvpn-raspberry-pi-t ...
Perfekt! Eigentlich läuft alles.
Nur jetzt wollte ich mir für den nächsten Urlaub ein Telefon einrichten mit dem ich jederzeit erreichbar bin über die Telefonnummer Zuhause.
Auf dem Telefon (Auerswald D-210) ist die .openvpn config des Raspberry hinterlegt und der Sipaccount der Fritzbox.
VPN Verbindung steht. Sipaccount ist registriert. Rufe ich nun meine Festnetznummer an (Telefon befindet sich nun in einem anderen Netzwerk - Beim Nachbarn)
Funktioniert alles PERFEKT ! ! ! Sprachqualität ist TOP
Versuche ich nun aber ein Gespräch ausgehend von diesem Telefon, funktioniert der Rufaufbau ganz normal und der Anruf kommt an, allerdings kann weder ich noch der andere irgendwas hören. Legt die Gegenstelle auf oder ich,, wird das Gespräch auch direkt beendet am anderen Gerät. Also Grundsätzlich läuft es ja aber man kann halt nix hören.
Gibt es dafür eine logische Erklärung?
Ich habe mal am Pi ein route -n gemacht:
pi@raspberry:~ $ route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 202 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.2.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
die Serverconfig vom PiVPN sieht wie folgt aus:
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/raspberryxxx.crt
key /etc/openvpn/easy-rsa/pki/private/raspberryxxx.key
dh none
ecdh-curve secp521r1
topology subnet
server 10.8.0.0 255.255.255.0
- Set your primary domain name server address for clients
push "dhcp-option DNS 8.8.8.8"
#push "block-outside-dns"
- Override the Client default gateway by using 0.0.0.0/1 and
- 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
- overriding but not wiping out the original default gateway.
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
Grundsätzlich sollten Gespräche doch in alle Richtungen funktionieren?
Wäre das Routing falsch, dann würde das Gespräche ja erst überhaupt nicht aufgebaut.
Eine Firewall ist nicht vorhanden. Daran sollte es also schon einmal nicht liegen.
Ich bin leider kein Profi, weder im Netzwerk noch bei Voip. Von daher würde ich mich sehr über Informationen freuen, wie sowas sein kann?!
(Ohne VPN Verbindung funktioniert das Telefon bei mir Zuhause problemlos in beide Richtungen)
Vielen Dank im Voraus
Mike
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: 2066508392
Url: https://administrator.de/contentid/2066508392
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
15 Kommentare
Neuester Kommentar
Hi,
welchen Router setzt Du ein und warum nutzt Du nicht das VPN im Router?
Gruß Looser
welchen Router setzt Du ein und warum nutzt Du nicht das VPN im Router?
Gruß Looser
Hi,
in diesem Fall eine Fritzbox 7490.
Es wäre zwar auch möglich über IPsec Xauth PSK zu realisieren..... Aber ich möchte jetzt nicht noch weitere VPN´s im Netzwerk realisieren. Also wenn ich es überhaupt nicht hin bekomme bleibt mir wohl nichts anderes über.... Aber das ist für mich soooooo unverständlich das ich heute n8 nicht schlafen werde. Ich finde OpenVPN so genial und es ärgert mich einfach zu tode wenn ich etwas überhaupt nicht nachvollziehen kann.
in diesem Fall eine Fritzbox 7490.
Es wäre zwar auch möglich über IPsec Xauth PSK zu realisieren..... Aber ich möchte jetzt nicht noch weitere VPN´s im Netzwerk realisieren. Also wenn ich es überhaupt nicht hin bekomme bleibt mir wohl nichts anderes über.... Aber das ist für mich soooooo unverständlich das ich heute n8 nicht schlafen werde. Ich finde OpenVPN so genial und es ärgert mich einfach zu tode wenn ich etwas überhaupt nicht nachvollziehen kann.
Hast Du es mal mit der FritzApp als SIP Client probiert?
Damit geht es.
Ich wollte allerdings ein Tischgerät verwenden.
Wenn ich wollte könnte ich das Problem mit einer anderen Lösung ganz einfach schaffen.
Mich Interessiert aber die Technik bzw. wie es sein kann das etwas in eine Richtung geht aber in die andere nicht bzw. warum genau. Mir geht es weniger darum eine andere Lösung zu finden als das ganze Sip / Voip / Routing zu verstehen und dann somit das Problem zu lösen
Ich wollte allerdings ein Tischgerät verwenden.
Wenn ich wollte könnte ich das Problem mit einer anderen Lösung ganz einfach schaffen.
Mich Interessiert aber die Technik bzw. wie es sein kann das etwas in eine Richtung geht aber in die andere nicht bzw. warum genau. Mir geht es weniger darum eine andere Lösung zu finden als das ganze Sip / Voip / Routing zu verstehen und dann somit das Problem zu lösen
Das wird dann so nicht klappen, denn die Fritzbox nimmt sich den Port 5060 für sich selbst. Und du müsstest das Telefon als Client an der Fritzbox anmelden. Nicht die SIP Daten des Providers.
Bei VoIP Problemen immer Wireshark anschmeißen und den Verbindungsaufbau verfolgen. Insbesondere ob überall die richtigen IP-Adressen mitgegeben werden...
2
Du hast vermutlich wie so oft bei diesen Anleitungen fälschlicherweise NAT (IP Adress Translation, Masquerading) im VPN Tunnel aktiviert.
Damit scheitert dann das RTP Protokoll was die Sprachdaten transportiert und dynamische Ports nutzt.
NAT im Tunnel ist unsinnig und sollte immer deaktiviert sein.
Das hiesige OpenVPN Tutorial hat alle Details zu der Thematik und daran solltest du dich halten !
Alternativ (oder generell) nutzt du symetrisches RTP wie es der Kollege @LordGurke in einem Thread HIER beschrieben hat.
Beides löst deine Problematik im Handumdrehen.
Nebenbei:
Heutzutage solltest du besser das effizientere WireGuard VPN nutzen statt OpenVPN. Einfacheres Setup und deutlich höhere Performance.
Merkzettel: VPN Installation mit Wireguard
Damit scheitert dann das RTP Protokoll was die Sprachdaten transportiert und dynamische Ports nutzt.
NAT im Tunnel ist unsinnig und sollte immer deaktiviert sein.
Das hiesige OpenVPN Tutorial hat alle Details zu der Thematik und daran solltest du dich halten !
Alternativ (oder generell) nutzt du symetrisches RTP wie es der Kollege @LordGurke in einem Thread HIER beschrieben hat.
Beides löst deine Problematik im Handumdrehen.
Nebenbei:
Heutzutage solltest du besser das effizientere WireGuard VPN nutzen statt OpenVPN. Einfacheres Setup und deutlich höhere Performance.
Merkzettel: VPN Installation mit Wireguard
1
Hi, sorry gerade erst die Info bekommen das geantwortet wurde. Vielen Dank! ich werde mir das heute abend direkt mal anschauen und Rückmeldung geben.
Hi, ich noch einmal,
ich habe mir die links oben komplett durchgelesen und musste feststellen, das ich eigentlich alles so gemacht habe wie es dort steht.
Ich habe das ganze dann noch einmal nachgestellt. Allerdings befindet sich die Fritzbox hinter einem Lancomrouter.
(Über den Lancomrouter habe ich dann eine IPsec Xauth psk Verbindung gemacht.
jetzt konnte ich ohne Probleme in beide Richtungen telefonieren.
Dann habe ich an noch einem anderen Standort ebenfalls eine Fritzbox hinter einem Lancomrouter. Dort habe ich aber auch noch ein openvpn. Dort kann ich über den Router auch direkt telefonieren. Nutze ich allerdings das Openvpn funktioniert es genau so wenig wie bei mir. Es muss also an der Konfiguration des
openvpn-Servers liegen.
(Bin gerade mobil unterwegs... von daher die ganzen fehler sorry)
ich habe mir die links oben komplett durchgelesen und musste feststellen, das ich eigentlich alles so gemacht habe wie es dort steht.
Ich habe das ganze dann noch einmal nachgestellt. Allerdings befindet sich die Fritzbox hinter einem Lancomrouter.
(Über den Lancomrouter habe ich dann eine IPsec Xauth psk Verbindung gemacht.
jetzt konnte ich ohne Probleme in beide Richtungen telefonieren.
Dann habe ich an noch einem anderen Standort ebenfalls eine Fritzbox hinter einem Lancomrouter. Dort habe ich aber auch noch ein openvpn. Dort kann ich über den Router auch direkt telefonieren. Nutze ich allerdings das Openvpn funktioniert es genau so wenig wie bei mir. Es muss also an der Konfiguration des
openvpn-Servers liegen.
(Bin gerade mobil unterwegs... von daher die ganzen fehler sorry)
Es muss also an der Konfiguration des openvpn-Servers liegen.
Vermutlich machst du dort fälschlicherweise NAT/Masquerade im Tunnel selber. Durch die dann aktive NAT Firewall können dann dynamischen RTP Pakete nicht passieren sofern man kein symetrisches RTP bei Voice nutzt und es kommt zu diesen Fehlern.Das ist ein typischer Fehler weil ein Gros der OpenVPN Anleitungen Szenarien beschreiben die zum Umgehen von GeoIP Blockings dienen mit NAT im Tunnel nicht aber für eine sauber konfigurierte VPN Umgebung. Damit wird dann oft diese falsche Tunnel NAT Konfig übernommen.
Das hiesige OpenVPN Tutorial weist explizit darauf hin.
Du hast es oben leider unterlassen Code Tags zu verwenden wie es hier empfohlen wird.
Folglich ist die VPN Config übersät mit falschen Formatierungen und schwer zu lesen. Sieht aber einigermaßen ok zumindestens das was man das aus dem vermüllten Code Text entnehmen kann.Wichtig wäre aber noch zu erfahren ob ggf. auch NAT/Masquerading im Tunnel fälschlicherweise aktiv ist (iptables) denn das führt zu diesem typischen Fehlerbild bei dir.
Alternativ kannst du auch mal ein anderes SSL basiertes VPN probieren wie Wireguard:
Merkzettel: VPN Installation mit Wireguard
Letztlich deutlich performanter als OpenVPN und erheblich einfacher zu konfigurieren.
Hi, noch einmal vielen Dank für deine Antwort.
Ich poste einfach nochmal alle configs (diesmal mit codetags.....)
Nach gefühlten 1000 Änderungen ist der VPN-Server immer noch unter Windows voll funktionsfähig und sieht aktuell wie folgt aus:
Mein Client sieht so aus:
Ein route -n auf dem Pi zeigt folgenden Inhalt: ( und wenn ich das jetzt richtig verstehe, meinst du das hier der Fehler liegt????
Ich poste einfach nochmal alle configs (diesmal mit codetags.....)
Nach gefühlten 1000 Änderungen ist der VPN-Server immer noch unter Windows voll funktionsfähig und sieht aktuell wie folgt aus:
dev tun
proto udp
port 1195
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/xxxxx.crt
key /etc/openvpn/easy-rsa/pki/private/xxxxxxx.key
dh none
ecdh-curve secp521r1
topology subnet
server 10.8.0.0 255.255.255.0
# Set your primary domain name server address for clients
#push "dhcp-option DNS 192.168.2.254"
#push "dhcp-option DNS 8.8.8.8"
#push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
#push "redirect-gateway def1"
push "route 192.168.2.0 255.255.255.0"
push "topology subnet"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
#duplicate-cn
# Generated for use by PiVPN.ioMein Client sieht so aus:
client
dev tun
proto udp
remote xx.xx.xx.xx 1195
resolv-retry infinite
nobind
remote-cert-tls server
tls-version-min 1.2
verify-x509-name raspberryxxxx name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
<ca>
-----BEGIN CERTIFICATE-----
Mxxx
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
Mxxx
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
Mxxx
-----END ENCRYPTED PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
bxxx
-----END OpenVPN Static key V1-----
</tls-crypt>Ein route -n auf dem Pi zeigt folgenden Inhalt: ( und wenn ich das jetzt richtig verstehe, meinst du das hier der Fehler liegt????
pi@raspberry:~ $ route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.254 0.0.0.0 UG 202 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.2.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
pi@raspberry:~ $
Wie sieht die Routing Tabelle auf dem Client aus wenn der Tunnel aktiv ist ??
Wenn das ein Winblows Client ist zeigt route print die Client Routing Tabelle.
Bei Linux ein ip route.
Wenn das ein Winblows Client ist zeigt route print die Client Routing Tabelle.
Bei Linux ein ip route.
Guten morgen! Hier kommt ein Windows Client.
Bin mir nicht sicher ob hier für dich Fragen aufkommen? Falls ja, folgende Infos:
192.168.0.10 ist der router Clientseitig.
192.168.0.149 ist die lokale IP Adresse Clientseitig
192.168.0.195 ist der Rechner meine Tochter, warum der hier drin steht??? K.A.
folgende Zeile zeigt die Server-Seite:
192.168.2.0 255.255.255.0 10.8.0.1 10.8.0.3 281
192.168.2.0 ist das Netzwerk am Sever
10.8.0.1 ist die von Server selbst vergebene IP
10.8.0.3 ist die IP-Adresse die mein Windows Client vom vpn-Server bekommt....
Bin mir nicht sicher ob hier für dich Fragen aufkommen? Falls ja, folgende Infos:
192.168.0.10 ist der router Clientseitig.
192.168.0.149 ist die lokale IP Adresse Clientseitig
192.168.0.195 ist der Rechner meine Tochter, warum der hier drin steht??? K.A.
folgende Zeile zeigt die Server-Seite:
192.168.2.0 255.255.255.0 10.8.0.1 10.8.0.3 281
192.168.2.0 ist das Netzwerk am Sever
10.8.0.1 ist die von Server selbst vergebene IP
10.8.0.3 ist die IP-Adresse die mein Windows Client vom vpn-Server bekommt....
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.10 192.168.0.149 281
10.8.0.0 255.255.255.0 Auf Verbindung 10.8.0.3 281
10.8.0.3 255.255.255.255 Auf Verbindung 10.8.0.3 281
10.8.0.255 255.255.255.255 Auf Verbindung 10.8.0.3 281
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
169.254.0.0 255.255.0.0 192.168.0.195 192.168.0.149 26
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.149 281
192.168.0.149 255.255.255.255 Auf Verbindung 192.168.0.149 281
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.149 281
192.168.2.0 255.255.255.0 10.8.0.1 10.8.0.3 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 10.8.0.3 281
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.149 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 10.8.0.3 281
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.149 281
@aqui
kannst du denn da irgendwo einen Fehler sehen?
kannst du denn da irgendwo einen Fehler sehen?
Nope ! Sieht alles sauber und richtig aus
Ist das ein Winblows Client ? Wenn ja ggf. die lokale Windows Firewall wenn das virtuelle OpenVPN Netzwerk Interface ein öffentliches Profil hat. Das sollte auf Privat oder Firma stehen.
- Default Route geht an 192.168.0.149
- 10.8.0.0 /24 ist vermutlich das interne OpenVPN IP Netz (geraten) und 10.8.0.3 die IP dieses OpenVPN Clients
- 192.168.2.0 /24 wird in den Tunnel geroutet
Ist das ein Winblows Client ? Wenn ja ggf. die lokale Windows Firewall wenn das virtuelle OpenVPN Netzwerk Interface ein öffentliches Profil hat. Das sollte auf Privat oder Firma stehen.
