Raspberry Pi VPN – Teil 6: VPN-Server unter IPv6

Raspberry Pi VPN

Dieser Artikel beschreibt, wie wir einen VPN-Tunnel auf Basis von IPv6 einrichten. Das geht nur, wenn am eigenen Internet Router auch eine öffentliche IPv6 Adresse anliegt, das dürfte aber heute eigentlich immer der Fall sein. Wer Zweifel hat, der lese bitte nochmal den Artikel IPv4 versus IPv6. Wessen Router vom Internet Service Provider auch eine IPv4 Adresse als Dual-Stack Anschluss zugewiesen bekommt, der kann sein VPN auch unter IPv4 aufsetzen, was zur Zeit sicher die bessere Variante ist. Also nochmal ganz deutlich: Hier bauen wir mit Hilfe eines Raspberry Pi einen VPN-Server auf, der IPv4 Daten durch einen IPv6 Tunnel transportiert. Warum man das zur Verbesserung der Datensicherheit seines Smartphones machen sollte und wie ein Virtual Private Network funktioniert, kann man in den ersten beiden Artikeln dieser Serie nachlesen.

Vorarbeiten

Bevor es an die Installation von PiVPN geht, sind einige Vorarbeiten zu erledigen, die ich in einem eigenen Artikel zusammengefasst habe. Erst wenn diese Vorarbeiten erfolgreich abgeschlossen sind, sollte man hierher zurückkehren und mit der Softwareinstallation am Raspberry Pi fortfahren, so wie ich es nachfolgend beschreibe.

PiVPN Server installieren

PiVPN ist eine Scriptsammlung, die es wesentlich vereinfacht, OpenVPN auf einem Raspberry Pi zu installieren. Und OpenVPN ist die Software, die unseren Raspberry Pi zum VPN-Server macht. Die schlechte Nachricht gleich zu Beginn, PiVPN unterstützt zur Zeit kein IPv6 – aber OpenVPN kann es und für PiVPN gibt es einen Workaround. Wir werden PiVPN zuerst wie für IPv4 installieren und dann ein paar Konfigurationsdateien editieren.

Vorab noch ein Hinweis: In der nachfolgenden Anleitung werden auch IPv4 Adressen zu sehen sein. Das liegt weniger daran, dass PiVPN zuerst für IPv4 installiert wird, wie eben erwähnt. Es liegt vor allem daran, dass wir im VPN-Tunnel ausschließlich IPv4 übertragen werden und die Daten dann auch per IPv4 ins Internet gehen. IPv6 ist lediglich das Transportnetz, auf dem das VPN selbst aufsetzt. Klingt kompliziert – ist es auch (ein wenig).

Los geht es mit einer SSH-Verbindung zum Raspberry Pi und der Aktualisierung der vorhandenen Installation:

sudo apt update
sudo apt upgrade

Dann wird mit folgendem Kommando PiVPN heruntergeladen und die Installation gestartet.

curl -L https://install.pivpn.io | bash

Die Bildergalerie zeigt die einzelnen Abfragen im Installationsvorgang. Die meisten davon können wir einfach mit Ok bestätigen, die Besonderheiten spreche ich nochmal explizit an:

PiVPN übernimmt die aktuellen Netzwerkeinstellungen und macht aus der IPv4 Adresse, auch wenn diese per DHCP zugeordnet wurde, eine statische Adresse. Das können wir einfach so bestätigen. In den Einstellungen am DHCP-Server (unser Internet Router) müssen wir nur Vorsorge tragen, dass der diese Adresse nicht einem anderen Gerät zusätzlich zuordnen möchte. Das können wir auf zwei Arten erreichen: einmal, in dem DHCP diese IP-Adresse fest dem Raspberry Pi zuordnet oder alternativ, in dem diese IP-Adresse aus dem Pool der zu vergebenden Adressen ausgenommen wird. Ich bevorzuge die erste Variante, alle meine Raspberry Pis bekommen per DHCP eine feste IPv4-Adresse.

Beim Netzwerkprotokoll bleiben wir bei UDP und der Port bleibt auf 1194. Das entspricht auch unseren Einstellungen am Router. Auch den Verschlüsselungsgrad können wir übernehmen. Interessant wird es bei der folgenden Abfrage:

Hier geht es um die öffentliche IP-Adresse. Die ändert sich bekanntlich täglich, deshalb können wir hier keine feste IP-Adresse eintragen, sondern nehmen die untere Variante, einen öffentlichen DNS-Eintrag zu nutzen. Darüber wird dann die jeweils aktuelle IPv6 Adresse aufgelöst.

Den Namen geben wir dann auf der nächsten Seite ein und das ist natürlich die Subdomäne, die wir von unserem DDNS-Anbieter vergeben bekommen haben. Als nächstes wird abgefragt, welchen DNS Provider (Server) der VPN-Server verwenden soll. Das hat nichts mit der DDNS-Geschichte von eben zu tun, sondern bestimmt wie der VPN-Server selbst seine Namensauflösung betreiben wird.

Hier ist es wichtig, nicht die Vorgabe Google zu nehmen. Wir wollen ja durch die Verwendung eines VPN-Tunnels ein Tracking durch Datenkraken wie Google erschweren. Da wäre es absolut kontraproduktiv, wenn wir Google alle unsere DNS Abfragen mitteilen. Hier also Custom auswählen!

Und auf der nächsten Seite können wir dann einen oder mehrere DNS-Server von Hand eintragen. Zu dieser Auswahlmöglichkeit muss ich ein bisschen was erklären: Wir könnten theoretisch alternative freie DNS-Server verwenden, wie zum Beispiel:

  • 146.185.167.43 für SecureDNS und
  • 194.150.168.168 für den Chaos Computer Club

Im Internet findet man noch weitere DNS-Server, die nicht mittracken. Aber das ist nicht die optimale Konfiguration, denn diese externen DNS-Server kennen nicht die Namen unserer internen Geräte im heimischen LAN. Wer also per VPN-Tunnel später auf seinen eigenen Fileserver oder einen anderen Raspberry Pi im Heimnetz zugreifen möchte, der trägt hier seinen eigenen Router als DNS-Server ein. Der versorgt sich dann seinerseits für externe Domänennamen bei DNS-Servern im Internet. (Hoffentlich nicht bei Google, sondern bei DNS-Servern des Internet Providers. Am besten mal kontrollieren!)

All diejenigen, die zusätzlich zu PiVPN auch noch Pi-Hole installieren werden, was sehr sinnvoll ist, die müssen nochmal umdenken. Pi-Hole – jetzt greife ich etwas vor – soll ja Trackingdienste blockieren und Pi-Hole macht das, in dem es sich in die Namensauflösung des Raspberry Pi einschleift. Also eigentlich müssten wir hier für Pi-Hole die IP-Adresse des Pi-Hole Servers – also die eigene IP-Adresse des Raspberry Pi eintragen. Das werden wir später auch tun, aber damit der VPN-Tunnel bereits vor der Installation von Pi-Hole getestet werden kann, bleiben wir einstweilen dabei, jetzt die interne IPv4 Adresse des Routers einzutragen. Wer die interne IP-Adresse seines Routers nicht kennt, der kann sie abfragen mit:

ip route
default via 192.168.0.1 dev wlan0 src 192.168.0.167 metric 303 
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.167 metric 303

Die IP-Adresse des eigenen Routers steht dann hinter default via.

Damit ist die Installation von PiVPN auch schon abgeschlossen und wir sollten den Raspberry Pi einmal durchbooten.

VPN Client anlegen

Die Installation des eigentlichen OpenVPN Clients erfolgt natürlich als App am Smartphone, die Konfiguration nehmen wir aber in weiten Teilen bereits hier am Server vor. Das hat den Vorteil, dass wir danach eine einzige Konfigurationsdatei auf das Smartphone übertragen und dort keine ellenlangen Schlüssel eintippen müssen.
Für jeden VPN-Client, also jedes Smartphone, legen wir wie folgt mit pivpn add eine VPN-Client-Konfiguration an:

$ pivpn add
Enter a Name for the Client:  SamsungS7
Enter the password for the client: ******* 
Enter the password again to verify: *******
spawn ./easyrsa build-client-full SamsungS7

Note: using Easy-RSA configuration from: ./vars
Generating an EC private key
writing new private key to '/etc/openvpn/easy-rsa/pki/private/SamsungS7.key.PNlzNH3SEk'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
Using configuration from /etc/openvpn/easy-rsa/openssl-easyrsa.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'SamsungS7'
Certificate is to be certified until Jan 18 15:43:04 2029 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated
Client's cert found: SamsungS7.crt
Client's Private Key found: SamsungS7.key
CA public Key found: ca.crt
tls-auth Private Key found: ta.key


========================================================
Done! SamsungS7.ovpn successfully created! 
SamsungS7.ovpn was copied to:
  /home/pi/ovpns
for easy transfer. Please use this profile only on one
device and create additional profiles for other devices.
========================================================

Wir brauchen lediglich einen Namen und ein Passwort zu vergeben und PiVPN generiert ein entsprechendes Client-Profil. Die vorhandenen Profile können wir auflisten mit:

$ pivpn list

: NOTE : The first entry should always be your valid server!

::: Certificate Status List :::
 ::  Status  ||   Name   :: 
     Valid   ::   server_75rZ9EcQAbEYDuvV
     Valid   ::   SamsungS7

Neben dem Server gibt es hier im Beispiel einen einzigen Client mit dem Namen SamsungS7 und für den hat PiVPN eine Konfigurationsdatei im Verzeichnis /home/pi/ovpns abgelegt.

$ ls ovpns
SamsungS7.ovpn

Konfigurationsdateien anpassen

Oben hatte ich es bereits erwähnt, PiVPN erlaubt es (noch) nicht den OpenVPN-Tunnel für IPv6 zu konfigurieren. Also müssen wir jetzt noch ein wenig Hand anlegen und zwei Konfigurationsdateien anpassen.

Server-Konfiguration editieren

sudo nano /etc/openvpn/server.conf

In dieser Datei ändern wir den Eintrag proto von udp auf udp6, dann sieht die Datei in etwa so aus:

dev tun
proto udp6
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/server_75rZ9EcQAbEYDuvV.crt
key /etc/openvpn/easy-rsa/pki/private/server_75rZ9EcQAbEYDuvV.key
dh none
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.0.1"
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"
client-to-client
keepalive 1800 3600
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 nobody
group nogroup
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.io

Client-Konfiguration editieren

Das gleiche passiert jetzt mit der Client-Konfiguration. Wir erinnern uns – das ist die Datei, die wir mit pivpn add angelegt hatten. Sie liegt im Verzeichnis ~/ovpns und hat als Dateinamen den Clientnamen, den wir vergeben hatten mit der Erweiterung .ovpn. Hier also beispielhaft:

nano ovpns/SamsungS7.ovpn

Auch hier ändern wir den Eintrag proto von udp auf udp6, dann sieht die Datei in etwa so aus:

client
dev tun
proto udp6
remote jsonp.dedyn.io 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
tls-version-min 1.2
verify-x509-name server_75rZ9EcQAbEYDuvV name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
# ... gekürzt ...

Client-Konfiguration aufs Smartphone übertragen

Jetzt müssen wir die geänderte Client-Konfigurationsdatei noch auf unser Smartphone bekommen. Dafür ist es vielleicht erst mal sinnvoll, sie vom Raspberry Pi auf den PC zu übertragen. Dazu braucht am RasPi weder FTP noch Samba eingerichtet werden, von einem Linux-Rechner aus geht das per SFTP, was wiederum auf SSH aufbaut. Im Linux-Dateimanager gehen wir auf Mit Server verbinden und tragen folgende Serveradresse ein:

sftp://pi@raspi167/home/pi

Anstelle meines raspi167 muss natürlich der eigene Name des Raspberry Pi eingegeben werden. Dann können wir in gewohnter Weise mit der grafischen Oberfläche auf den Raspberry Pi zugreifen und die Datei kopieren.

Auf das Smartphone bekommen wir die Datei dann in dem wir das Smartphone per USB anstecken. Alternativ können wir die Datei auch per E-Mail aufs Handy schicken.

Weitere Artikel in dieser Kategorie:

122 Kommentare

  1. Jerome

    Hallo,

    danke für die Anleitung.
    Für den mobilen Zugriff vom Smartphone wird aber eine mobile IPv6_Adresse vorausgesetzt, richtig ?
    D2-Kunden wären dann z.B. aussen vor, da die meisten nachwievor „nur“ mit einer IPv4-Adresse mit dem Smartphone im Netz sind.

    LG

  2. Helmut (Beitrag Autor)

    Genau so ist es, es sei denn, man bekommt IPv6 über einen WLAN-Hotspot.
    Mehr dazu in diesem Artikel Raspberry Pi VPN Teil 3: IPv4 versus IPv6.

  3. Hans

    Lieber Helmut,

    vielen Dank für die großartige Anleitung. Ich hätte hierzu zwei Fragen:
    Wie kann ich zwei RPI-VPNs koppeln, so dass alle Geräte auf der einen Seite auch die Geräte auch der anderen Seite erreichen? (quasi LAN-to-LAN statt Server-Client).
    Kannst du mir einen Tipp geben, wie ich die o.g. Anleitung dazu anpassen muss?
    Kann ich auch mehrere RPI-VPNs mit einander verbinden?
    Danke!

    Gruß
    Hans

  4. Sven

    Hallo Helmut,

    vielen Dank für die sehr ausführliche und gut beschriebene Anleitung.
    Eine kleine Frage hätte ich dann noch.
    Meine Situation: Telekom Mobilfunk, also Dual-Stack und DS-Lite zuhaus. Das bedeutet, dass der Tunnel ja nur über IPV6 aufgebaut werden kann. Können dann innerhalb des tunnels ipv4 und ipv6 gleichzeitig getunnelt werden oder wie kann ich mir das vorstellen? mal angenommen ich habe gerade zugriff auf meinen heimserver der nur ipv4 spricht und ich würde gleichzeitig eine werbsite aufrufen, die nur ipv6 spricht, was wäre dann?

    Gruß Sven

  5. Helmut (Beitrag Autor)

    Hallo Hans,
    mit PiVPN ist das nicht möglich, eventuell aber mit OpenVPN selbst. Aber dazu kann ich Dir leider keine Anleitung geben. Versuche mal „OpenVPN Lan to Lan“ in der Suchmaschine Deines Vertrauens!

  6. Helmut (Beitrag Autor)

    Richtig Sven,
    in Deiner Konstellation wirst Du typischerweise den Tunnel unter IPv6 aufbauen. Durch den Tunnel selbst wird mit PiVPN immer nur IPv4 übertragen. Das stellt aber kein Problem dar, da Webserver heute immer (auch) per IPv4 erreichbar sind.

  7. Hans

    Hallo Helmut,

    ich bin genau nach deiner Anleitung vorgegangen. Nun ist es so, dass ich mich intern (im WLAN) mich per VPN verbinden kann, von extern (anderes Netzwerk bzw. Mobilfunk mit IPv6/IPv4 DualStack) allerdings nicht.

    Kann es sein, dass ich noch ein paar Routen definieren muss, in der FB oder auf dem RPI? In anderen Anleitungen habe ich davon etwas gelesen. Oder ist das bei PIVPN nicht erforderlich?
    Hast du eine Idee, was ich tun kann, damit der Zugriff auch von außerhalb funktioniert?

  8. Helmut (Beitrag Autor)

    Nein Routen brauchst Du nicht definieren. Was sagt denn das Log am Smartphone? Wird der Domänenname richtig aufgelöst?

  9. Hans

    Ok, danke! Es scheint nun zu funktionieren. Die Portweiterleitung der FB hat komischerweise nicht richtig funktioniert. Nun klappt es! :-)

  10. Helmut (Beitrag Autor)

    Prima !!

  11. Hans

    Hallo Helmut,
    eine allerletzte Frage zum Thema: Weißt du, warum in der /etc/sysctl.conf dieser Eintrag auskommentiert ist?

    #net.ipv6.conf.all.forwarding=1

    Für ipv4 ist es aktiv. Muss es das nicht auch für ipv6 sein?
    Danke!

  12. Helmut (Beitrag Autor)

    Die Frage ist, was Du mit einer Änderung erreichen möchtest. Wenn alles funktioniert würde ich lieber die Finger davon lassen.

  13. Hans

    Ok, danke. Ich würde gerne auch IPv6 Seiten / Adressen aufrufen können. Aber das scheint doch etwas komplizierter zu sein… Liebe Grüße

  14. Helmut (Beitrag Autor)

    Du möchtest IPv6 durch den VPN-Tunnel leiten?
    Das ist mit PiVPN derzeit noch nicht möglich, PiVPN transportiert im Tunnel ausschließlich IPv4. Dazu müsstest Du Dich direkt in OpenVPN einlesen und möglicherweise auch Dein IPv6 Netz segmentieren.

  15. Hans

    Genau, das hatte ich vor.
    Danke für den Tipp, das werde ich machen!
    Liebe Grüße

  16. Thomas

    Hallo Helmut,

    ich habe mich genau an deine Anleitung gehalten. Der einzige Unterschied ist, dass ich das myfitz Konto als DDNS-Dienst verwende.

    Das Problem ist, dass ich immer die Meldung bekomme: Resolve: cannot resolve host address: xyz.myfritz.net:1194 (no address associated with host name)

    Hast du mir einen Tipp, was ich machen könnte?

  17. Helmut (Beitrag Autor)

    Es könnte am konfigurierten DDNS-Namen liegen. Der muss bei IPv6 auf den Raspberry Pi verweisen und folgendes Format haben:
    ..myfritz.net, bei mir war das raspi167.p0wrksbfopi2gppr.myfritz.net.
    Du hast also möglicherweise MyFritz nicht richtig konfiguriert oder PiVPN oder beides.

  18. Thomas

    Daran scheint es zu liegen. Wenn ich: ping raspberrypi.xyz.myfritz.net ausführe kommt immer „Zielhost nicht erreichbar“.
    Muss ich bei den Freigaben der FritzBox http (Port 80) und UDP (Port 1194) freigeben?

  19. Helmut (Beitrag Autor)

    Wenn es ein DNS Problem ist, dann hat es nichts mir den Freigaben zu tun. Also hier nicht durcheinander kommen und besser mal mit „nslookup“ prüfen, ob der Name aufgelöst wird.
    Freigeben brauchst Du nur UDP 1194, wobei – wenn ich mich recht erinnere – MyFritz von sich auch TCP anlegt. Aber das macht ja nichts.

  20. Thomas

    Hallo Helmt,

    ich habe gestern den halben Tag noch getestet.
    Was ich mittlerweile hinbekomme ist den Pi über das Internet anzupingen. Der VPN-Server geht aber leider nicht. Hier sagt er mir immer: „Cannot resolve host address“. So langsam weiß ich nicht mehr weiter.

  21. Helmut (Beitrag Autor)

    Thomas, Du lieferst leider nur wenig Informationen.
    Von wo aus pingst Du denn? Vom Smartphone? Und ist das im WLAN oder im mobilen Internet?
    Pingst Du per Namen oder per IP-Adresse?
    Wenn per Namen und das ist erfolgreich, ist dann auch der selbe Name im VPN-Client konfiguriert?

  22. Thomas

    Hallo Helmut,
    ich habe 2 Wohnsitze. Der Pi steht an Wohnsitz A, ist dort an einer FritzBox 7590 an einem DSLite Internet-Anschluss angeschlossen. In der FritzBox ist das FritzKOnto angelegt und ich komme auch von außerhalb (egal ob Smartphone oder anderer Heimanshcluss) auf die Konfigurationsseite der FritzBox.
    Auf dem Pi habe ich nach deiner ANleitung OpenVPN installiert, somit auch UDO6 als Protokoll und in der FritzBox ist auch für den Pi der Port 1194 freigegeben.
    Am Wohnsitz B hänge ich an einer ConnectBox ebenfalls einem DsLite Anschluss.
    Das Anpingen vom Wohnsitz B über „CMD“ mit „ping raspberrypi.xyz.myfritz.net“ klappt auch.
    Der OpenVPN verbindet sich aber nicht von Wohnsitz B mit Wohnsitz A (pi).
    Hier kommt immer die Meldung: RESOLVE: Cannot resolve host address: raspberrypi.​xyz.​myfritz.​net:1194 (Der angegebene Host ist unbekannt. )
    could not determine IPv4/IPv6 protocol

  23. Helmut (Beitrag Autor)

    Hallo Thomas,

    also beim Ping funktioniert die Namensauflösung und mit dem VPN-Client nicht.

    MyFritz scheint in Ordnung zu sein, sonst könntest Du den Raspberry Pi nicht pingen. Zur Sicherheit kannst Du mal die IPv6-Adresse, die der Ping ausgibt mit der IPv6-Adresse des Raspberry Pi vergleichen. Nicht dass irgendwas anderes den Ping returniert. Aber das ist unwahrscheinlich.

    Machst Du Ping und VPN-Client vom selben Gerät? Und welchen VPN-Client verwendest Du?

  24. Thomas

    Hallo Helmut,
    Die IPv6-Adressen sind identisch.
    Ich habe die ovpn-Datei nun im Editor geöffnet und hier probeweise die IPv6-Adresse des Pi, anstatt des „raspberrypi.xyz.myfritz.net“ angegeben.
    Hier kommt nun eine andere Meldung:TCP/UDP: Preserving recently used remote address: [AF_INET6]IPv6:1194
    Socket Buffers: R=[65536->65536] S=[65536->65536]
    UDPv6 link local: (not bound)
    UDPv6 link remote: [AF_INET6]IPv6:1194
    MANAGEMENT: >STATE:1571680285,WAIT,,,,,,

    Ich mache sowohl den Ping, wie auch den VPN-Client von meinem PC am Wohnsitz B.
    Ich nutze: OpenVPN 2.4.7

    Die Client-Datei sieht so aus:
    client
    dev tun
    proto udp6
    remote raspberrypi.​xyz.​myfritz.​net 1194
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    remote-cert-tls server
    tls-version-min 1.2
    verify-x509-name raspberrypi_xxx name
    cipher AES-256-CBC
    auth SHA256
    auth-nocache
    verb 3

    Ich bin mir nicht ganz sicher, was unter „verify-x509-name“ stehen sollte.

  25. Helmut (Beitrag Autor)

    Hallo Thomas,

    verify-x509-name hat bei mir einen kryptischen Inhalt, den PiVPN setzt. Da würde ich nichts ändern.
    Das ist dann also ein VPN-Client unter Windows. Kenne ich zwar nicht, aber der sollte ja genau so funktionieren, wie die unter Android.

    Fassen wir zusammen: Ein Ping geht, damit funktioniert auch IPv6 auf beiden Seiten, der Client kann IPv6 nutzen und MyFritz löst den Namen in eine IPv6 Adresse auf.
    Die Frage ist, warum die Namensauflösung am selben Gerät per Ping geht und per VPN-Client nicht.
    Vielleicht versucht der VPN-Client fälschlicherweise IPv4 zu nutzen.

    Überprüfe bitte, ob MyFritz neben der IPv6- auch eine IPv4-Adresse anbietet. Per nslookup oder in der internetseitigen Weboberfläche von MyFritz.
    Und schau, ob der VPN-Client in der Konfiguration die Möglichkeit bietet eine Verbindungsaufnahme per IPv4 explizit zu verbieten.
    Davor die Konfiguration besser wieder in den Ursprungszustand bringen, am besten das Profil löschen und die .ovpn-Datei neu importieren.
    Das wären die nächsten Schritte, die ich empfehlen kann.
    Viel Erfolg

  26. Thomas

    Hallo Helmut,
    ich habe heute nochmal probiert und es nun hinbekommen.
    Ich habe den OpenVPN auf TCP6 konfiguriert.
    Aber was letzendlich das entscheidende war, ist die Freigabe in der FritzBox.
    Hier habe ich eine neue My-Fritz Freigabe für meinen Raspberry erstellt, bei der ich das Schema „Manuelle Eingabe“ vpn:// genommen habe.
    Den Port habe ich bei 1194 belassen.

  27. Helmut (Beitrag Autor)

    Glückwunsch Thomas,

    dass es jetzt funktioniert. Das andere Schema bei der MyFritz-Freigabe, dürfte aber kaum die Ursache gewesen sein. Eher, dass sich MyFritz sehr leicht verkonfiguriert, sobald man manuell eingreift, was für VPN allerdings unumgänglich ist. Mir ist das mehrfach passiert. Du hast MyFritz neu konfiguriert und damit passt es jetzt. Eine Erklärung, warum die Namensauflösung bei einem Ping funktioniert hatte und im VPN-Client nicht, ist das allerdings auch nicht. Hauptsache es geht.

    Viel Erfolg weiterhin mit Deinem VPN

  28. Peter

    Hallo.Vielen Dank erstmal für die Anleitung.Ich habe diese soweit 1zu1 umgestzt kann aber leider in keinster Weise eine Verbindung aufbauen. Nach nun mehr als eine Woche hin und her testen bin ich mit meinem Latein am Ende. Kurz was zu meiner Konstellation:
    – Fritzbox mit DS-lite
    – Raspberry mit Pi-hole und PiVPN
    – vServer mit 6tunnel (um die IPv4 Anfragen von z.B. Mobilfunk auf IPv6 zu tunneln)

    Aufgrund des DS-Lite Anschlusses habe ich mir einen vServer gemietet und einen 6tunnel auf den Port 443 gebaut um von außen per IPv4 (Mobilfunk) auf den PiVPN zugreifen zu können.Der tunnel funktioniert so weit. In der Fritzbox habe ich eine Portfreigabe 443 auf die IPv6 Adresse des Raspberry geamcht.Da 6tunnel nur TCP beherrscht habe ich in der PiVPN-Konfiguration auch dieses ausgewählt.
    Die OpenVPN-Clients habe ich so eingestellt das sie eine Verbindung (IPv4) zu Port 443 des vServer aufbauen von wo es weiter (mit IPv6) zum Port 443 des Raspberry gehen soll.
    Leider bekommen die Clients aber keine Antwort vom Server.
    Was könnte hier noch die Ursache sein?

  29. Helmut (Beitrag Autor)

    Das tut mir leid, zu 6tunnel kann ich nichts sagen. Hast Du denn die Kompatibilität von PiVPN zu 6tunnel gecheckt?

  30. Peter

    Ja die Kompatibilität ist gegeben.

  31. Marcel

    Hallo,

    vielen Dank für dieses gute Tutorial. Ich bin darauf gekommen, da meine alte VPN Lösung, direkt über OpenVPN, nicht mehr funktionierte. Ich habe scheinbar ein ähnliches Problem wie Thomas (zwei Beiträge über mir). Könnt ihr mir sagen wie ihr die myFritz-Freigabe korrekt hinbekommen habt? Wenn ich eine Freigabe erzeuge, wird direkt ein IPv4 und ein IPv6 Eintrag erzeugt. Ich denke das diese Kombination sich gegenseitig behindert und der Grund für mein Problem sind.

    Da ich zusätzlich noch den Dienst von Feste-IP nutze, habe ich mein Problem, so gut wie ich es als nicht ITler kann, im Forum geschildert. Vielleicht hilft euch das weiter: https://forum.feste-ip.net/viewtopic.php?f=4&t=801

    Wie auch Thomas habe ich eben eine neue myFritz-Freigabe mit dem Schema „vpn://“ erzeugt. Auch hier wurde wieder eine IPv4 Eintrag, den ich gar nicht haben will, erzeugt. Wenn ich den IPv4 Eintrag manuell lösche, verschwindet aber auch automatisch der IPv6 Eintrag.

    Der VPN-Dienst an sich funktioniert soweit. Aus meinem lokalen Netz komme ich problemlos auf den VPN

  32. Helmut (Beitrag Autor)

    Nein eine IPv4 und IPv6-Freigabe behindern sich nicht gegenseitig. Eigentlich hab ich das oben im Artikel beschrieben, wie es mit MyFritz geht. Wo genau liegt denn das Problem, wenn Du es genauso machst? Wichtig ist die zusätzliche Freigabe für UDP.

  33. Marcel

    Genau der Punkt mit der zusätzlichen UDP-Freigabe irritiert mich…
    In der Vergangenheit konnte ich eine MyFritz-Freigabe einrichten und habe nur den IPv6 Eintrag bekommen. Dieser lief auf TCP, welches ich bewusst nutze, da es mit Feste-IP.net funktioniert (UDP wird soweit ich weiß nicht unterstützt).
    Nach einem Firmware-Update der Fritzbox (oder ich hab es selber irgendwie zerfummelt) war dort ein IPv4 und ein IPv6 Eintrag. Wie in dem oben verlinkten Forenbeitrag ist das bei meiner anderen MyFritz-Freigabe für meine NAS nicht passiert. Dort ist noch immer lediglich der IPv6-Eintrag vorhanden. Ich kann auch weiterhin wie gewohnt extern auf meine NAS zugreifen.
    Ich habe also die Vermutung, dass das Problem durch die doppelte (IPv4 und IPv6) TCP-Freigabe auf Port 1194 zustande kommt. Theoretisch kann ich aber auch auf feste-ip verzichten und direkt die myfritz-Adresse nutzen. Werde den VPN Server mal auf UDP6 umstellen und deine Methode versuchen. Hab Teil 8 ehrlich gesagt nur kurz überflogen.

  34. Helmut (Beitrag Autor)

    Wenn Du PiVPN nutzt, so wie in dieser Artikelserie beschrieben, dann wird per Standard UDP 1194 verwendet und es muss folglich auch UDP an der Fritzbox freigegeben sein.. Wenn Du das anders machst, dann muss die Freigabe natürlich zu Deiner Konfiguration passen.

  35. Marcel

    Ich bekomm es einfach nicht hin. Was muss den in der client.conf stehen?

    proto udp6
    remote myfritzadresse.myfritz.net 1194

    oder muss da dann was anderes hin?

  36. Helmut (Beitrag Autor)

    Du hattest geschrieben, dass Dein VPN im internen Netz funktionieren würde. Dann kann der Client an sich das Problem ja nicht sein.
    Richtig, in der client.ovpn sollte es in etwa so aussehen:
    proto udp6
    remote raspi167.p0w385aef998ppr.myfritz.net 1194

  37. Marcel

    Genau. Auch nach dem ich den PiVPN mit genau deinen Einstellungen neu aufgesetzt habe (mit UDP, myfritz Freigabe auf TCP und einer zusätzlichen Freigabe für UDP) kann ich lediglich intern auf den VPN zugreifen. Der Dienst an sich scheint also zu funktionieren, nur die FritzBox macht mir einen Strich durch die Rechnung.

  38. Helmut (Beitrag Autor)

    Ist die Freigabe (IPv4 und IPv6) denn auf der Weboberfläche von MyFritz im Internet sichtbar?
    Und der Client bekommt vom Provider auch eine IPv6 Adresse zugewiesen?

  39. Marcel

    Die Freigaben sind auf der Weboberfläche der Fritzbox sichtbar (grüner Punkt vor der Freigabe), auf der myfritz Homepage ist sie sichtbar und mein Raspberry bekommt auch eine eigene IPv6 Adresse (beginnend mit 2a00:…, meines Wissens nach ein Indiz dafür das es eine externe ip ist).
    Ich bin da mittlerweile echt sprachlos. Selbst wenn mein Smartphone nicht IPv6 fähig wäre, müsste es gehen da die IPv6 durch den myfritz Dienst auf IPv4 gemappt wird.

  40. Helmut (Beitrag Autor)

    Nein, MyFritz macht kein Routing zwischen IPv4 und IPv6. Überprüfe, ob Dein Smartphone vom Provider eine IPv6 Adresse bekommt.
    Ich gehe recht in der Annahme, dass Dein Homenetzwerk vom DSL-Provider (oder was auch immer) nur IPv6 bekommt?

  41. Sven

    Hallo Marcel,

    ich hab euren Dialog nur mal kurz überfolgen und ich hoffe weiterhelfen zu können:

    da du ja scheinbar den dienst feste ip nutzen musst, muss auf jedenfall sowohl in der server config als auch in der client config proto tcp6 stehen. in der client config gehört die serveradresse von feste ip rein, die du dir ausgesucht bzw zugewiesen bekommen hast, mit der sehr hohen protnummer.
    die freigabe in der fritzbox war bei mir auch für v4 und v6, was für den betrieb aber irrelevant war.

  42. Alex

    Hallo,

    eine super Anleitung !
    Über mein eigenes WLAN habe ich das nu am Laufen, ich kann mich in den PIVPN mit OpenVPN Connect (Android) verbinden. Das klappt. Getestet mit proto tcp6 !

    Nun habe ich es aus dem Mobilfunknetz heraus getestet. Dazu habe ich zuerst einen Portmapper auf feste-ip eingerichtet. Als IPV6-Adresse die MyFritz-Adresse genutzt, die ich vorher auch genutzt habe. Als Port den, der in der Fritzbox freigegeben ist. In der Clinet-Config habe ich proto tcp6 gelassen und als remote ‚meine URL von feste-ip‘ eingetragen, Leerzeichen und dann die hohe Portnummer.

    OpenVPN zeigt mir im Log Connection [..] via TCP6 an, ‚TCP recv error: Connection reset by peer‘. ‚Transport error on … NETWORK_RECV_ERROR.

    Hat einer eine Idee, woran das liegen kann und wie ich da weiter komme ?
    Kann ich irgendwie testen, ob Pakete am Raspi ankommen ?

  43. Marcel

    Hallo,

    Erstmal danke an Sven und Helmut für euer Feedback. So wie ihr es beschrieben habt, hab ich es gemacht. Klappt leider immer noch nicht. Vielleicht setze ich mich heute Abend noch einmal dran.

    Alex, wenn du auf der Feste-ip Seite die Verbindung bzw. den Port testest, bekommst du dann auch die Meldung „Port nicht erreichbar“? So ist es jedenfalls mit identischer Konfiguration bei mir.

  44. rschz

    Hallo Helmut,

    tolle Anleitung, vor allem die Ausführlichkeit hat mich dazu animiert, mir auch einen Raspberry mit VPN Zugang einzurichten.
    Meine Konstellation:
    – Fritzbox mit DS-lite von Deutsche Glasfaser
    – Raspberry mit PiVPN
    – vServer mit 6tunnel (um die IPv4 Anfragen von z.B. Mobilfunk auf IPv6 zu tunneln)
    Den vServer möchte erst einbinden, wenn der Raspberry mit VPN läuft. Ich habe zwei Handys, davon hat das eine im Mobilnetz DualStack (Telekom), das andere nur ipv4 (aber auch Telekom).
    Bei der Einrichtung von pivpn habe ich mich an Deine Anleitung gehalten, lediglich beim Port bin ich abgewichen auf eine andere Zahl, wie z.B. 1000. Und wegen der späteren Tunnelung über einen vServer verwende ich als Protokoll tcp statt udp. Die Konfig Dateien für Client und Server habe ich auch geändert (tcp6 proto – wie hier schon in den Kommentaren geschrieben)
    Den DDNS bei deSec habe ich eingerichtet. Der meldet auch meine IP Adresse(n). Da beginnen schon die ersten Probleme. Dort wird mir eine IP4 Adresse angezeigt (die aber nicht meine ist, sondern die von Glasfaser, das ist sozusagen der Router von Glasfaser, hinter dem ich dann irgendwo hänge). Aber auch die IP6 meines Raspberry. Insofern müßte das gut sein. Jedoch beim VPN Aufbau vom IP6 Handy zeigt das Log an, daß versucht wird, die Verbindung mit der IP4 Adresse herzustellen – das kann natürlich nicht funktionieren.
    Dann habe ich – wie hier auch einige andere User – das Ganze neu mit myFritz Freigabe versucht. Mein Raspberry heißt hier pc—xxxx-yyyy-zzzz-xxxx.wertzuiop.myfritz.net. Wie hier auch schon beschrieben habe ich die Manuelle Vergabe mit „vpn://“ verwendet. Die Freigabe wird mir auf der MyFritz Seite auch angezeigt. Beim Verbindungsaufbau zeigt der Client auf dem ip6 Handy „DNS resolve error“ und Host not found on TCP6 session an.
    Daraufhin habe ich versucht, den Raspberry anzupingen. Das funktioniert auch nicht – weder wenn ich die myfritz Freigabe Adresse verwende noch die deSec Adresse. Aber auch die direkte Eingabe der IPV6 Adresse liefert keine ping Erreichbarkeit. Ich habe auch noch andere Geräte innerhalb meines Heimnetz versucht anzupingen (ipv6 Geräte mit Freigabe). Keines ist erreichbar. Das einzige Gerät auf das ich Zugriff habe und auch anpingen kann, ist meine Fritzbox.

    Ich habe nur noch Fragezeichen… Fritzbox Einstellungen habe ich schon zigmal geprüft – oder ich sehe den Wald vor lauter Bäumen nicht mehr…

  45. Helmut (Beitrag Autor)

    Das wundert mich nicht, das Thema ist zu komplex, als dass Du mehrere Konfigurationsparameter gleichzeitig ändern könntest und es dann noch funktioniert. Ich würde empfehlen zu allererst streng nach Anleitung für IPv6 vorzugehen und erst wenn das funktioniert, stückweise in Richtung Deiner Zielkonfiguration umzustellen, also Port ändern und auf TCP wechseln.
    Du solltest versuchen, kein IPv4 an den DDNS-Server zu übermitteln. Nur IPv6, denn bei DS-Lite funktioniert kein ankommendes IPv4.
    Und was das Pingen angeht, kannst Du von außen natürlich nur Geräte pingen, für die Du an der Fritzbox eine Freigabe eingerichtet hast.

  46. rschz

    Ok. Ich werde morgen versuchen, pivpn mit udp und Standardport aufzusetzen. Melde mich dann nochmal.
    Dennoch bleiben für mich Fragezeichen: Warum kann ich kein Gerät anpingen (wie oben geschrieben, habe ich natürlich Freigaben gesetzt)?
    Und an den DDNS Server habe ich kein Ip4 übermittelt. Meine Testkonfiguration ist mein Heimnetzwerk unter Deutsche Glasfaser und mein Handy mit Telekom DualStack.

  47. Helmut (Beitrag Autor)

    Aber scheinbar hat der DDNS-Server eine IPv4-Adresse, denn Du schreibst: „… Dort wird mir eine IP4 Adresse angezeigt (die aber nicht meine ist, sondern die von Glasfaser …“ Wenn der DDNS-Server eine IPv4-Adresse bekommen hat – woher auch immer, dann wird er sie auch an den VPS-Client weiterreichen und die Kommunikation falsch laufen. Schau mal, wo die herkommt und ob Du sie unterbinden kannst.

  48. rschz

    Habe alles nochmal von ganz vorne begonnen. Der Raspberry komplett neu aufgesetzt und streng nach Anleitung gearbeitet.
    Das Ergebnis ist genau wie vorher. Der Hostname kann nicht aufgelöst werden, im Client log steht nach wie vor die ip4 Adresse des Glasfaser Server…
    Das das so nicht gehen kann, ist mir schon klar, nur habe ich keine Ahnung, was ich jetzt noch ändern könnte…

  49. Helmut (Beitrag Autor)

    Du hast von deSEC gesprochen. Wie übermittelst Du denn die IPv6 Adresse? Mit ddclient, so wie im Artikel? Was gibt denn
    sudo ddclient -force
    am Raspberry Pi aus?
    Möglicherweise entnimmt deSEC Deine IPv4 Adresse dem Absender des Datenpakets, das die IPv6 Adresse meldet. Dann müssten wir eine Möglichkeit finden, dass ddclient auch die Meldung per IPv6 macht oder deSEC die IP-Adresse nicht annimmt. Du könntest versuchen in der ddclient Konfiguration update.dedyn.io durch update6.dedyn.io zu ersetzen. Dann würde ddclient einen dedizierten IPv6-Server bei deSEC ansprechen.

  50. Jeremy

    Guten Abend ich hoffe ich komme noch nicht zu spät….

    jedoch bekomme ich keine Verbindung im Internen Netz als auch extern zu Stande woran liegt das ?
    Was ich im Protokoll lese ist das die Verbindung über UDPv4 versucht, kann es daran liegen? Wenn ja wie kann ich das ändern

    MFG Jeremy

    2020-01-11 23:08:12 1

    2020-01-11 23:08:12 —– OpenVPN Start —–
    OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28

    2020-01-11 23:08:12 OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28

    2020-01-11 23:08:12 Frame=512/2048/512 mssfix-ctrl=1250

    2020-01-11 23:08:12 UNUSED OPTIONS
    4 [resolv-retry] [infinite]
    5 [nobind]
    6 [persist-key]
    7 [persist-tun]
    10 [verify-x509-name] [raspberrypi_90d69897-71c4-4288-a675-954f5c6e0a46] [name]
    13 [auth-nocache]
    14 [verb] [3]

    2020-01-11 23:08:12 EVENT: RESOLVE

    2020-01-11 23:08:12 Contacting [5.146.195.13]:1194/UDP via UDP

    2020-01-11 23:08:12 EVENT: WAIT

    2020-01-11 23:08:12 Connecting to [m4s-t3r.dedyn.io]:1194 (5.146.195.13) via UDPv4

    2020-01-11 23:08:22 Server poll timeout, trying next remote entry…

    2020-01-11 23:08:22 EVENT: RECONNECTING

    2020-01-11 23:08:22 EVENT: RESOLVE

    2020-01-11 23:08:22 Contacting [5.146.195.13]:1194/UDP via UDP

    2020-01-11 23:08:22 EVENT: WAIT

    2020-01-11 23:08:22 Connecting to [m4s-t3r.dedyn.io]:1194 (5.146.195.13) via UDPv4

    2020-01-11 23:08:32 Server poll timeout, trying next remote entry…

    2020-01-11 23:08:32 EVENT: RECONNECTING

    2020-01-11 23:08:32 EVENT: RESOLVE

    2020-01-11 23:08:32 Contacting [5.146.195.13]:1194/UDP via UDP

    2020-01-11 23:08:32 EVENT: WAIT

    2020-01-11 23:08:32 Connecting to [m4s-t3r.dedyn.io]:1194 (5.146.195.13) via UDPv4

    2020-01-11 23:08:42 EVENT: CONNECTION_TIMEOUT [ERR]

    2020-01-11 23:08:42 Raw stats on disconnect:
    BYTES_OUT : 1566
    PACKETS_OUT : 29
    CONNECTION_TIMEOUT : 1
    N_RECONNECT : 2

    2020-01-11 23:08:42 Performance stats on disconnect:
    CPU usage (microseconds): 69442
    Network bytes per CPU second: 22551
    Tunnel bytes per CPU second: 0

    2020-01-11 23:08:42 EVENT: DISCONNECTED

    2020-01-11 23:08:42 Raw stats on disconnect:
    BYTES_OUT : 1566
    PACKETS_OUT : 29
    CONNECTION_TIMEOUT : 1
    N_RECONNECT : 2

    2020-01-11 23:08:42 Performance stats on disconnect:
    CPU usage (microseconds): 89912
    Network bytes per CPU second: 17417
    Tunnel bytes per CPU second: 0

    2020-01-11 23:12:33 1

    2020-01-11 23:12:33 —– OpenVPN Start —–
    OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28

    2020-01-11 23:12:33 OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28

    2020-01-11 23:12:33 Frame=512/2048/512 mssfix-ctrl=1250

    2020-01-11 23:12:33 UNUSED OPTIONS
    4 [resolv-retry] [infinite]
    5 [nobind]
    6 [persist-key]
    7 [persist-tun]
    10 [verify-x509-name] [raspberrypi_90d69897-71c4-4288-a675-954f5c6e0a46] [name]
    13 [auth-nocache]
    14 [verb] [3]

    2020-01-11 23:12:33 EVENT: RESOLVE

    2020-01-11 23:12:33 Contacting [5.146.195.13]:1194/UDP via UDP

    2020-01-11 23:12:33 EVENT: WAIT

    2020-01-11 23:12:33 Connecting to [m4s-t3r.dedyn.io]:1194 (5.146.195.13) via UDPv4

    2020-01-11 23:12:34 EVENT: DISCONNECTED

    2020-01-11 23:12:34 Raw stats on disconnect:
    BYTES_OUT : 108
    PACKETS_OUT : 2

    2020-01-11 23:12:34 Performance stats on disconnect:
    CPU usage (microseconds): 38860
    Network bytes per CPU second: 2779
    Tunnel bytes per CPU second: 0

    2020-01-11 23:12:36 1

    2020-01-11 23:12:36 —– OpenVPN Start —–
    OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28

    2020-01-11 23:12:36 OpenVPN core 3.git::2ae73415 ios arm64 64-bit PT_PROXY built on Dec 2 2019 14:44:28

    2020-01-11 23:12:36 Frame=512/2048/512 mssfix-ctrl=1250

    2020-01-11 23:12:36 UNUSED OPTIONS
    4 [resolv-retry] [infinite]
    5 [nobind]
    6 [persist-key]
    7 [persist-tun]
    10 [verify-x509-name] [raspberrypi_90d69897-71c4-4288-a675-954f5c6e0a46] [name]
    13 [auth-nocache]
    14 [verb] [3]

    2020-01-11 23:12:36 EVENT: RESOLVE

    2020-01-11 23:12:36 Contacting [5.146.195.13]:1194/UDP via UDP

    2020-01-11 23:12:36 EVENT: WAIT

    2020-01-11 23:12:36 Connecting to [m4s-t3r.dedyn.io]:1194 (5.146.195.13) via UDPv4

    2020-01-11 23:12:46 Server poll timeout, trying next remote entry…

    2020-01-11 23:12:46 EVENT: RECONNECTING

    2020-01-11 23:12:46 EVENT: RESOLVE

    2020-01-11 23:12:46 Contacting [5.146.195.13]:1194/UDP via UDP

    2020-01-11 23:12:46 EVENT: WAIT

    2020-01-11 23:12:46 Connecting to [m4s-t3r.dedyn.io]:1194 (5.146.195.13) via UDPv4

  51. Helmut (Beitrag Autor)

    Hallo Jeremy,

    in der Tat versucht Dein Client eine UDP4 Verbindung aufzubauen. Die Ursache ist darin zu sehen, dass er vom DDNS-Server eine IPv4 Adresse (5.146.195.13) zurück erhalten hat. Du musst also mal schauen, warum in einer IPv6 Umgebung eine IPv4 Adresse beim DDNs Server landen kann. Ich hab in meiner Antwort an rschz vor ein paar Tagen bereits einen Verdacht geäußert in Richtung deSEC. Leider hat er sich bisher nicht dazu geäußert.

    Wenn ich Deinen DDNS-Server auslese, dann bekomme ich:
    host m4s-t3r.dedyn.io
    m4s-t3r.dedyn.io has address 5.146.195.13
    m4s-t3r.dedyn.io has IPv6 address 2a02:908:1061:54e0:ba27:ebff:fe4a:1e05

    also eine IPv6- aber auch eine IPv4-Adresse. Letztere ist natürlich schädlich, wenn Dein Raspberry Pi darüber gar nicht erreichbar ist.

    Wenn Dein ddclient die IPv4 Adresse nicht rausgibt, dann mach doch bitte den Versuch den dedizierten IPv6-Server bei deSEC anzusprechen. Also in der ddclient Konfiguration update.dedyn.io durch update6.dedyn.io ersetzen!
    Und bitte gib hier Feedback, ob das was bringt, damit ich ggf. den Artikel entsprechend ergänzen kann.

  52. K. H. Dondorf

    Hallo Herr Karger,
    ich habe Ihre Beiträge mit Interesse gelesen.
    Bevor ich mit der Installation beginne, folgende Grundsatzfrage:

    Kann eine VPN-Verbindung z.B. von einem Smartphone hinter einem DS-Lite-Anschluss zu einem Raspberry Pi Vpn hinter einem Dual-Stack aufgebaut werden?
    Für eine Antwort wäre ic Ihnen sehr dankbar.

    MfG

    K. H. Dondorf

  53. Helmut (Beitrag Autor)

    Per IPv6 auf jeden Fall und vermutlich geht es sogar per IPv4, da Sie das am DS-Lite nur abgehend nutzen.

  54. Sergej B

    Hallo Helmut,

    vielen lieben Dank für deine Anleitung!
    Ich habe das ganze gerade zum laufen gebracht und das Gefühl der ersten erfolgreichen Verbindung ist schon echt toll.

    Ohne deine wirklich vorbildliche Anleitung wäre das für mich nicht möglich gewesen.
    Schön dass es Menschen wie dich gibt!

    Grüße vom Augsburger Land
    Sergej

  55. Helmut (Beitrag Autor)

    Danke Sergej für das Kompliment.

  56. Jan

    Hallo Helmut,

    erstmal vielen Dank für diesen ausführlichen Artikel! Ich bin geplagt mit einem Router von Unitymedia und minimalsten Einstellungsmöglichkeiten, dein Artikel gab mir Hoffnung endlich einen VPN Tunnel in mein Heimnetz aufbauen zu können.

    Mir stellen sich 2 Probleme:

    1. Beim Clienten bekomme ich die Meldung über einen Transport Error: DNS resolve error on ‚####.dedyn.io‘ for UDP session: DNS/RRset does not exist. #### ist anonymisiert. Mit ‚dig ####.dedyn.io ANY‘ bekomme ich aber einen AAAA Eintrag, der die IP des Pi enthält. Auf meinem Router sind Portfilter von für die Ports 443, 1194 auf den Pi geleitet.

    2. Evtl. Denkfehler: Ich bekomme ja die IP des Pi über dedyn. Also kann ich ja anstatt
    ‚remote ####.dedyn.io 1194‘ in dem ovpn File auch die IPv& Adresse in diese Zeile packen, oder? Wenn ich mit meinem WLAN verbunden bin funktioniert das wunderbar, ansonsten bekomme die Fehlermeldung, dass ‚No route to host‘ möglich sei.

    Die Problematik ähnelt der von Thomas, leider kann ich nur in der Conenctbox keine Einstellungen in dieser Art vornehmen.

    Für Tipps und Hilfe bin ich dankbar,

    Lieben Gruß

    Jan

  57. Helmut (Beitrag Autor)

    Hallo Jan,
    zu 1: Mal prüfen, warum Dein Client den Namen über dedyn.io nicht auflösen kann. Hat das Smartphone überhaupt IPv6
    zu 2: Ja, das sollte gehen, dass Du anstelle des Namens die IPv6-Adresse einträgst. Geht halt nur so lange, bis die sich ändert.
    So lange Du IPv6-Freigaben an Deinem Router eintragen kannst, sollte es auch mit Deiner Connectbox funktionieren.

  58. Jan

    Hallo Helmut,

    hab ich geprüft, war wohl nicht der Fall. Ich gehe nun über 6tunnel gegen ####.dedyn.io, was korrekt aufgelöst wird. So scheint es zumindest.
    Ich komme nur nicht gegen meinen PI. Auch von meinem Server bekomme ich ihn nicht angepingt. Es muss schon die ipv6 Adresse des PIs, und nicht die des Routers, der davor steht an dedyn gemeldet werden, oder hab ich einen Denkfehler?

    Vielen Danke für deine Antwort!
    Gruß
    Jan

  59. Helmut (Beitrag Autor)

    Du verwendest 6tunnel? Das hattest Du nicht erwähnt. Meine Aussagen beziehen sich natürlich nur auf die im Artikel verwendete Konstellation.
    Gib hier gerne Nachricht, wenn Du das zum Laufen bringst.

  60. Jan

    Hallo Helmut,

    hatte ich, als ich meinen ersten Post schrieb noch nicht. Als du mich darauf hingewiesen hast, dass mein Smartphone evtl. keine IPv6 Adresse hat, habe ich es probeweise ergänzt um eine Lösung zu finden. Gerne kann ich hier etwas ausführlicher werden.

    Ich benutze im Moment nicht mehr 6tunnel sonder socat. 6tunnel leitet leider nur tcp weiter, ich hätte jedoch gerne udp.
    Auf einem Server bei der AWS, praktisch umsonst, mit IPv4 und IPv6 Adresse leite ich eingehende Datenpakete via socat von udp4 auf udp6 um, und schickt sie an dedyn, jetzt mit IPv6 Adresse.

    Im client.conf File steht im Moment die IPv4 Adresse des Servers bei der AWS.

    Wenn ich jetzt meine Firewall ausschalte, was ich leider komplett machen muss, da das Freischalten einzelner Ports die Connectbox nicht unterstützt, komme ich sogar auf meinem PI raus.

    Hier bekomme ich nur leider nun TLS Handshake Errors, um die ich mich noch kümmern muss. Wenn ich mich richtig Entsinne ist der Host der IP Adresse vom PI nicht auffindbar, ich vermute, dass irgendwo an meinem AWS Server irgendeine Firewallregel Pakete wegschmeißt, die eine Verbindung vom PI zum Client unmöglich machen.

    Um die unelegante Client IPv4/IPv6 Problematik zu lösen dachte ich mir, dass ich entweder, falls der Client eine IPv6 Adresse hat direkt gegen Dedyn gehe, mit ClientFile1, und wenn nicht, dann mit ClientFile2 gegen meinen AWS Server.

    Soweit der Stand,
    Gruß
    Jan

  61. Helmut (Beitrag Autor)

    Wie gesagt Jan, wenn Du das mit einem IPv4-auf-IPV6- Übersetzer zum Laufen bringst, dann poste hier gerne eine Zusammenfassung. Interessiert andere sicher auch.

  62. Gunther

    Hallo Helmut,

    vielen Dank für die super Beschreibung.
    Leider kämpfe ich mit folgendem Phänomen:
    Die FritzBox zeigt eine andere IPv6 Adresse, wie die die
    ich bei wieistmeineip.de und ähnlichen Seiten angezeigt bekomme.
    Mein Provider ist Unitymedia/Vodafone und ich habe DS-lite.
    Wie kann ich mir dies erklären und beheben?

    Grüße,
    Gunther

  63. Helmut (Beitrag Autor)

    Hallo Günther,
    geht es um die IPv6-Adresse des Routers oder eines Endgeräts (Raspberry Pi zum Beispiel)? Und wo schaust Du an der FritzBox und von welchem Gerät aus rufst Du wieistmeineip.de auf? Und schließlich, worin unterscheiden sich die beiden abgefragten IP-Adressen?

  64. Jerome

    Hallo,

    erstmal danke für diesen Blog und den unermüdlichen Einsatz Helmut !!

    Ich habe gestern auch versucht, streng nach dieser Anleitung einen VPN-Tunnel aus einem mobilen ipv6-Netz der Telekom, zu meinem Rpi3@Deutsche-Glasfaser aufzubauen.

    Dazwischen hängt meine Fritte 7390. Das DDClient-Update zu Spdyn klappt immerhin.

    Allerdings erhält mein RPi von der Fritte keine globale 2001er IPv6, und daran scheitert es scheinbar. Die Fritte ist per Default-DG-Anleitung konfiguriert, und es funktioniert soweit alles andere.

    Hat noch jemand ne Idee, was ich einstellen muss, um die globale-IP zu bekommen, die ja scheinbar nötig ist ?

    Was muss ich liefern, um eine Antwort zu bekommen ?
    LG

    J.

  65. Jerome

    … ach ja, auf dem RPi läuft das aktuellste Raspbian-Buster-Lite incl. aller Updates bis gestern. Die Fritz hat die aktuellste FW für diese Version (6.83 oder so).

    Ergänzend: mein DNS ist ein weiterer RPi im Hausnetz mit PiHole. Diesen habe ich bei der OpenVPN-Konfiguration auch angegeben

    LG

  66. Stefan

    Hallo Helmut,

    vielen Dank für den schönen Beitrag.

    Pi-hole hatte ich bereits in meinem Heimnetzwerk im Einsatz. Bei der Einrichtung von PiVPN wurde die Anwesenheit von Pi-hole erkannt (Stand 16.03.2020) und automatisch mit allen notwendigen Einstellungen eingebunden.

    Ich habe mich für WireGuard entschlossen und es läuft fantastisch. Nach Erstellung einer Config für das Smartphone brauchte ich lediglich in der entsprechenden Android-App den QR-Code einscannen – komfortabler geht es kaum!

    Nachdem Vodafone Ende 2019 in seimem Mobilfunknetz IPv6 ausgerollt hat habe ich endlich ohne Umwege und trotz DS-Lite-Anschluss wieder Zugriff auf mein Heimnetzwerk bzw. die heimischen Server-Dienste.

    Viele Grüße,

    Stefan

  67. Helmut (Beitrag Autor)

    Hi Jerome,

    welche IPv6-Adressen bekommt denn Dein RasPi? Kommst Du vom RasPi aus ins Internet? Falls ja und wenn Du DS-Lite hast, dann müsste er ja eine globale IPv6-Adresse haben.

    LG Helmut

  68. Stefan

    Hallo erneut,

    als ich von Umwegen sprach ging es um Folgendes.

    Mein Miet-Server mit Linux hat eine feste IPv4-Adresse. Ich habe bei der Firewall auf dem Miet-Server den gleichen Port wie mein VPN-Server auf dem Raspberry Pi geöffnet. Per socat habe ich mir auf dem Miet-Server eine Weiterleitung in mein Heimnetzwerk eingerichtet:

    (1) sudo ufw allow 9999/udp
    (2) sudo crontab -e
    (3) @reboot /usr/bin/socat UDP4-LISTEN:9999,fork,su=nobody UDP6:raspi.dyndns.bla:9999 &

    In obigen Beispiel ist „9999“ der Port des VPN-Server-Dienstes und „raspi.dyndns.bla“ die dynamische IP-Adresse des Raspberry Pi. Auf meinem heimischen Router ist eine entsprechende IPv6-Freigabe für das Raspberry Pi eingerichtet.

    Auf diese Weise hatte ich bereits mit reinem IPv4-Mobilfunknetz Zugriff auf mein Heimnetzwerk. Ein paar ergänzende Angaben:

    – Unitymedia DS-Lite-Anschluss
    – AVM FRITZ!Box 6590 Cable
    – Raspberry Pi 4 Modell B mit 4 GB RAM, Raspbian GNU/Linux 10 (buster)
    – Miet-Server: Root-Server von http://www.delta-networks.de mit Ubuntu 18.04.4 LTS

    Viele Grüße,

    Stefan

  69. Helmut (Beitrag Autor)

    Hallo Stefan,

    vielen Dank für Deine Ausführungen. Du hattest Deinen Mietserver mit socat verwendet um eine Übersetzung von IPv4 auf IPv6 durchzuführen. So konntest Du bereits mit IPv4 am Smartphone Deinen DS-Lite-Anschluss daheim erreichen. Und Du hast das scheinbar per UDP hinbekommen.
    Wenn Du Dir vorstellen kannst, die zugehörigen Installationen und Konfigurationen in einem Artikel zusammen zu fassen, dann würde ich den gerne in meinem Blog veröffentlichen, als Teil 13 quasi. Das könnte viele andere Leser in der Tat interessieren.

    LG Helmut

  70. Stefan

    Hallo Helmut,

    ich kann gerne kann versuchen meine Lösung zu dokumentieren.

    Dabei würde ich davon ausgehen, dass sämtliche von dir beschriebenen Vorarbeiten bis https://blog.helmutkarger.de/raspberry-pi-vpn-teil-5-vorarbeiten-fuer-ein-vpn-unter-ipv6/ abgeschlossen sind. Konkret meine ich:

    – Raspberry Pi bootet
    – Anwender hat Zugriff auf Raspberry Pi (lokal oder per SSH)
    – Raspberry Pi hat globale IPv6-Adresse
    – Privacy Extensions deaktviert
    – Dynamische IPv6-IP-Adresse eingerichtet

    Oder soll ich bei einer Neuinstallation des Raspberry Pi starten?

    Wie sieht es bezüglich dem (Miet-)Server mit IPv4-Adresse aus? Kann ich ein laufendes System inklusive (SSH-)Zugriff annehmen (Ersteinrichtung abgeschlossen)? Oder soll ich speziell den von mir verwendeten Anbieter näher beschreiben?

    Viele Grüße,

    Stefan

  71. Helmut (Beitrag Autor)

    Natürlich kannst Du auf alle meine Artikel verweisen und brauchst nichts nochmal schreiben, was dort bereits dokumentiert ist.
    Und was den Server angeht, da kannst Du ein laufendes System mit SSH ruhig voraussetzen. Wer das nicht hinbekommt, der wird kaum socat einsetzen.
    Sonst lieber ein paar Grundlagen vermitteln (was ist socat) und weniger auf spezielle Dinge Deines Providers eingehen.
    Schick mit Deinen Artikel gerne per E-Mail an webmaster@helmutkarger.de.
    Ich würde mich freuen.

  72. Heinzo

    Hallo Helmut,
    das ist mit Abstand die beste Anleitung für Raspi, OpenVpn und ipv6 die ich finden konnte. Ich konnte mich sehr gut durcharbeiten und habe, so wie ich denke, alles so gemacht wie du das vorgegeben hast.
    Aber irgendwie bekomme ich einfach keine Verbindung zustande. Scheinbar fehlen mir dann doch die nötigen Kenntnisse dafür, sehr schade. Ich kämpfe schon seit einigen Tagen mit dem DS-Lite Anschluss von Vodafone, mit dem ich es einfach nicht gebacken bekomme, mich per VPN und dem Raspberry mit meinem Heim-Netzwerk zu verbinden. Ich vermute dass ich denPunkt nicht so richtig verstanden habe, wie die Freigaben für den Raspi in der Fritzbox und mit MyFritz genau anzugeben sind, welche ip-Adressen ich weiterleiten muss. Den weg über ddns.de bin ich auch gegangen, fand mich aber nicht so richtig zurecht, da ich ja lediglich eine feste ipv6-Adresse zur verfügung habe, die aber bei der Abfrage im Raspi für das dyndns-tool gar nicht erscheint. Ein Zugriff mit einer ipv4-Adresse scheint bei dem DS-Lite eben nicht möglich zu sein.
    Für die Verbindung habe ich sogar zwei mobil-Varianten zur Verfügung und ausprobiert. Ein iPhone über Vafone, das absurder Weise immer noch per ipv4-Adresse mobil unterwegs ist und ein iPhone von der Telekom, das eine ipv6-Adresse zugewiesen bekommt.
    Vielleicht könntest du noch einmal explizit (für Dummies :-) )noch einmal auf die DS-Lite Problematik eingehen und wie ich das speziell mit MyFritz, einer Fritzbox 6591-Cable und einem Raspberry Pi4B auf die Reihe bekommen kann. Das wäre ein absoluter Traum!
    Ich bekomme das einfach nicht hin, vermutlich zu alt, oder zu doof…

    Beste Grüße
    Heinzo

  73. Helmut (Beitrag Autor)

    Eine Kurzanleitung für DS-Lite kann ich leider nicht so einfach anbieten, wie Du siehst ist die Thematik so komplex, dass ich 12 Artikel dafür gebraucht hab. Du findest aber das was Du zum Verständnis von DS-Lite brauchst sicher in Teil 3 der Artikelserie. In kurzen Worten: Bei DS-Lite hast Du öffentlich nur IPv6 am Heimnetzwerk zur Verfügung. Folglich brauchst Du auf Clientseite, also am Smartphone, ebenfalls IPv6. Mit Deinem Telekom-Handy sollte es also funktionieren. Was ich Deiner Fehlerbeschreibung leider nicht entnehmen kann, ist ob Du ein DDNS-Problem hast, oder eins mit der Routerfreigabe. Versuche am besten zuerst mal zu testen, ob Dein DDNS-Anbieter die richtige IPv6-Adresse bekommt (und keine IPv4). Wenn das geht, dann kümmere Dich um die Freigabe.
    Viel Erfolg

  74. Luca

    Hallo Helmut,

    erst einmal vielen Dank für den ausführlichen Beitrag. Ich habe Probleme beim Erreichen des Servers über einen VPN-Client (Android sowie PC mit Windows). Meine Konstellation ist:

    – DS-Lite -> IPv6
    – Raspberry Pi als Server im Heimnetz mit pivpn (open vpn)
    – MyFritz als DDns

    Die Namensauflösung aus xyz.myfritz.net zu einer statischen IPv6 Adresse funktioniert auch. Ich kann ihn von außerhalb über seinen DNS Namen pingen.
    Die Log-Dateien von Server und Client zeigen mir, dass keine Anfragen beim Server ankommen. Der Server Log ist dementsprechend leer und die Log-Datei vom Client (Android, OpenVPN Version 3.1.0) gefüllt mit time-outs.

    Log-Datei (Android Client):
    15:50:44.083 — Connecting to [Pi123.xyz.myfritz.net]:1194 (AAAA:BBBB:CCCC:DDDD:EEEE:FFFF:9999:8888) via UDPv6
    15:50:53.888 — Server poll timeout, trying next remote entry…
    15:50:53.891 — EVENT: RECONNECTING
    15:50:53.898 — EVENT: RESOLVE
    15:50:53.944 — Contacting [AAAA:BBBB:CCCC:DDDD:EEEE:FFFF:9999:8888]:1194 via UDP
    15:50:53.948 — EVENT: WAIT
    15:50:53.952 — Connecting to [Pi123.xyz.myfritz.net]:1194 (AAAA:BBBB:CCCC:DDDD:EEEE:FFFF:9999:8888) via UDPv6
    15:51:03.891 — Server poll timeout, trying next remote entry…
    15:51:03.893 — EVENT: RECONNECTING
    15:51:03.903 — EVENT: RESOLVE
    ….

    In diesem Fall gehe ich davon aus, dass es das Problem bei der Portfreigabe in der FritzBox liegt. Hier ein Ausschnitt zu den freigegebenen Ports:

    [URL=https://www.bilder-upload.eu/bild-7bfc7c-1585755590.png.html][IMG]https://www.bilder-upload.eu/thumb/7bfc7c-1585755590.png[/IMG][/URL]

    https://www.bilder-upload.eu/bild-7bfc7c-1585755590.png.html

  75. Helmut (Beitrag Autor)

    In der Tat schaut das nach einem Freigabeproblem aus. Beide Enden haben IPv6 und die Namensauflösung funktioniert auch. Die Freigabe schaut aber auch gut aus, UDP wurde nachgetragen. In welchem Netz befindet sich denn der Client? Könnte es sein, dass das Netz den Port 1194 blockiert. Würde es denn funktionieren, wenn sich das Smartphone im heimischen WLAN befindet?

  76. Luca

    Der Client (Android) einmal in einem Mobilfunknetz und einmal im eigenen Hausnetz in dem sich auch der Server befindet. Beides funktioniert nicht. Ich habe auch einen Port Scanner über den Server und die FritzBox laufen lassen. Dort wird mir Port 1194 nicht als offen angezeigt. Ich bin kein IT-Experte, aber meine Kollegen aus der IT sind der Meinung, dass die Ports angezeigt werden müssten.

    „/var/log/openvpn.log“ Ich bin mir ziemlich sicher, dass die Datei das einzige und richtige Log zum Server ist und somit auch Sessions protokollieren müsste?

    Vielen Dank auf jeden Fall für deine Unterstützung.
    Ich habe selten so viele Rückmeldungen zu Fragen unter einem Beitrag gesehen. Hut ab!

  77. Luca

    PS: Habe es! Die Ports bei der FritzBox 7412 müssen gerne mal öfter freigegeben werden, bis sie es dann auch wirklich sind!
    Jetzt hänge ich am Handshake im Client Log steht „name/password empty“ fest, aber ich kämpfe mich erst einmal weiter durch. Vielen Dank trotzdem.

  78. Luca

    Bei mir läuft es jetzt auch. Fazit:
    Die Portfreigabe bei einer FritzBox 7412 funktioniert nicht immer beim ersten Mal, auch wenn es im Status steht. Ich empfehle dir tatsächliche Portfreigabe mit nmap zu überprüfen:

    sudo apt-get install nmap
    sudo nmap -sU -6 -p 1194 Pi123.xyz.myfritz.net

    Weiterhin empfehle ich bei der Installation für Windows 10 Home 64 Bit die Version 2.4.8 von OpenVPN. Die empfohlene Version 2.7.1 hat bei mir nicht funktioniert.
    Mein Adroid Client hat noch Probleme. Ich werde die anderen Versionen von OpenVPN testen.

  79. Helmut (Beitrag Autor)

    Also doch die Freigaben an der Fritzbox. Prima, dass es jetzt funktioniert.

  80. Sven

    Hi Helmut,

    auch von mir ein großes Lob für die Anleitung. Ich habe die Anleitung befolgt, nutze myFritz zur Namensauflösung und kann mich per macOS und dem OpenVPN Client mit meinem Heimnetz (Unitymedia DS Lite mit Fritzbox 6590) verbinden.

    Ich werde aber bei OpenVPN auf das virtuelle Netz 10.8.0.0 gesetzt (ich bekomme die IP 10.8.0.2). Es existieren sogar Routings, welche es mir erlauben, auf das eigentliche Netz 192.168.178.0 zuzugreifen. Allerdings klappt die Namensauflösung nicht. Ich habe beim Setup als einzigen DNS 192.168.178.1 eingegeben (meine FritzBox IPv4 Adresse), allerdings kann ich nicht auf die Namen zugreifen. Auch ist es mir nicht möglich, trotz IP Adresse und Port auf http://192.168.178.27:8581 zuzugreifen (die GUI für Homebridge). Muss man für andere Ports noch mehr machen?

    Danke dir!

  81. Helmut (Beitrag Autor)

    Glückwunsch Sven,
    da bist Du ja schon sehr weit gekommen. Die Lösung für die interne Namensauflösung findest Du vielleicht in diesem Artikel. Sie lautet „.fritz.box“ hinter den Namen anzuhängen. 10.8.0.0 ist das IPv4 Tunnelnetz, das ist ganz richtig so. Siehe auch hier. Du solltest alle IPv4-Geräte in Deinem Heimnetz per Tunnel erreichen können ohne weitere Ports zu öffnen. Der Tunnel schleust alles zum Raspberry Pi durch und damit bist Du bereits im Heimnetz. Ich sehe jetzt keinen Grund, warum das mit dem Port 8581 nicht funktionieren sollte.

  82. Sven

    Hi Helmut,

    super, mit dem .fritz.box funktioniert nun die Namensauflösung. Gibt es eigentlich einen Trick, wie man eine IP Adresse im eigenen Band der Fritzbox bekommt? Also irgendwas zwischen 192.168.178.231 und 239. Bei PPTPD VPN kann man das einstellen. Geht das auch bei OpenVPN ohne Tunnelnetz?

    Leider ist bei mir der Zugriff auf interne Server extrem schwierig. Wenn ich nachdem Aufbau des VPNs versuche, mit SSH auf andere Server im Netzwerk zuzugreifen, dann klappt ein Verbindungsaufbau nur in 1 von 10 Fällen, sonst hängt er sich nach der Passworteingabe immer auf. Auch klappt leider der Zugang über 8581 auch noch nicht. Hast du noch Ideen zur Fehlersuche?

    Danke dir :-)

  83. Helmut (Beitrag Autor)

    Nicht dass ich wüste. So weit ich es kenne benützt OpenVPN ein eigenes Netz für den Tunnel. Denkbar wäre aber vielleicht, dass Du Dein Homenetz subnettest und ein Teilnetz den OpenVPN-Tunnel andienen kannst. Wobei das aber kaum Vorteile bringen wird, weil der Raspberry dann zwischen den beiden Subnetzen routet.

    SSH vom Smartphone durch den Tunnel auf alle meine Raspberries geht bei mir einwandfrei. Wenn es manchmal bei Dir doch geht, dann scheint irgendeine Komponente auf dem Weg zu schwächeln.

  84. Christoph

    Hi Helmut,

    vielen Dank für den tollen und verständlichen Artikel. Leider funktioniert das Ganze bei mir nicht. Der OpenVpn Client versucht immer über ipv4 eine Verbindung aufzubauen. Dazu muss ich sagen, dass ich was Netzwerke etc. angeht kompletter Anfänger bin. Ich nutze myFritz als DNS und die Fritzbox als ddns. Habe so meine ich bei der Konfiguration von PiVpn auch alles richtig gemacht. Die Freigaben im Router sehen so aus: https://imgur.com/a/TfBx7bQ

    Der VPN soll in der Theorie das Netzwerk von meinem Bruder mit meinem verbinden.
    Mit meinem Rechner in meinem Netzwerk kann ich mich mit dem VPN verbinden (ip4 im Heimnetzwerk sollte ja funktionieren).

    Ich bin mit meinem kleinen Latein am Ende. Hast du vielleicht noch irgendeine Idee?

    Vielen Dank und beste Grüße,
    Christoph

  85. Helmut (Beitrag Autor)

    Hallo Christoph,
    eins vorab: Mit der Konfiguration, die PiVPN erstellt, kannst Du einen VPN-Client mit einem VPN-Server verbinden, also Smartphone ins Heimnetz, das verbindet aber keine zwei Netzwerke miteinander, so dass alle Geräte in A mit allen in B kommunizieren könnten. OpenVPN an sich soll das aber können – was für Dich aber Nacharbeit in OpenVPN bedeutet und vermutlich auch jeweils einen OpenVPN-Router in jedem Netzwerk.

    Aber jetzt zum Standardfall OpenVPN-Client baut Tunnel zu RasPi im Heimnetz auf.
    Auf dem Screenshot sieht man leider nicht, was das für Freigaben sind, ob TCP/UDP, IPV4/IPv6, vermutlich aber alles zusammen, da es 4 Stück sind.
    Frage: Was hast Du denn überhaupt außen an Deinem Heimnetz anliegen? DualStack oder DS-Lite? Wenn DS-Lite, dann darf es keine IPv4 Freigaben geben und kein DDNS auf IPv4, denn Dein Router hat kein IPv4. Und wenn DualStack, dann sollte die Verbindung zumindest per IPv4 ja funktionieren.

  86. Christoph

    Danke für die schnelle Antwort.

    Sollte meines Wissens nach DS-Lite sein. Doch läuft die Fritz-Freigabe nur, wenn sowohl IPv4 als auch IPv6 freigegeben sind.

  87. Helmut (Beitrag Autor)

    Check das besser mal, ein DDNS-Eintrag für IPv4 macht ja keinen Sinn, wenn der Client dem nicht folgen kann.
    Siehe Teil 12.

  88. Jens

    Hallo,

    ich glaub ich brauch mal Einzelunterricht.
    Bin der Meinugn ich hab alles gemacht:
    Vorbereitungen Pi auf IPv6, deSec registriert und erfolgreich update, Freigabe in FritzBox eingerichtet mit Pi und 1194, OpenVPN Zertifikate erstellt und auf Handy geladen.
    Aber er verbindet sich trotzdem nicht…..

    Wer kann helfen bzw. was an Daten muss ich leifern?

    DANKE!

  89. Helmut (Beitrag Autor)

    Die erste Frage wäre, ob das Handy überhaupt IPv6 hat. Wenn ja, kann die IP-Adresse anhand des deSec-Namens aufgelöst werden? Und dann: Was sagt denn das Log des Clients?

  90. Heinzo

    Hallo Helmut,

    mittlerweile habe ich eine Verbindung über OpenVPN und ipv6-Adressen vom Iphone zum Raspberry hinbekommen. Also VPN-Verbindung steht. Perfekt bis jetzt! :-)
    Jetzt hänge ich nur noch da dran, dass ich keine Verbindung mit meinem Netzwerk herstellen kann. Das heißt, ich kann mich über den Safari-Browser nicht mit den ipv4-Adressen im Netzwerk verbinden um an die Geräte zu kommen. Eine Verbindung ins Internet klappt ebenfalls nicht. Da bin ich am verzweifeln. Ich habe die ServerConfig schon gefühlte Hundert mal neu konfiguriert. Ich denke, das muss entweder etwas mit der Firewall zu tun haben, oder der Konfiguration in der Fritzbox, oder DNS-Server…. völlig Ratlos.
    Hast du eine Idee was es sein könnte oder welche Einstellungen ich für das Routing auf meine Netzwerkadressen brauche?

    viele Grüße

  91. Helmut (Beitrag Autor)

    Versuch zuerst einmal, ob Du die Geräte in Deinem Heimnetz über den Tunnel per IPv4 Adresse erreichen kannst und nicht mit Namen. Wenn das nicht geht, probier alle IP-Adressen des Raspberry Pi zu pingen. Wenn Du den Pi erreichen kannst, aber die anderen Adressen nicht, dann ist OpenVPN verkonfiguriert und routet die Pakete nicht weiter.
    Kannst Du Deine Geräte per IP-Adresse erreichen, aber nicht mit Namen, dann ist es ein DNS-Problem. Schau, ob es nur am Domänennamen liegt, bei einer Fritzbox üblicherweise fritz.box. Falls nicht, schau, was Du bei der OpenVPN-Konfiguration als DNS-Serer eingetragen hast. Das muss natürlich ein DNS-Server sein, der auch Deine internen Geräte kennt, also die Fritzbox, oder Pi-Hole, falls Du das einsetzt.
    Viel Erfolg.

  92. Heinzo

    Hallo Helmut,

    Das ist ja gerada das absurde, denn wenn ich über den VPN mit meinem Iphone verbunden bin, kann ich über ein Netzwerktool („Network“)alle Adressen im Heimnetz über die ipv4 anpingen und bekomme auch eine Rückmeldung. Ein Zugriff auf die Geräte im Safari-Browser z.B. auf die Benutzeroberfläche des Routers oder der Überwachungskamera funktioniert aber nicht. Auch der zugriff via Apps z.B. auf die Hausautomation geht nicht.

    Interessant ist, dass in diesem Netzwerktool Informationen zur Netzwerkverbindung aufgelistet werden und sobald ich mich mit dem VPN verbunden habe anscheinend keine ip-Adresse mehr habe, sowohl ipv4 als auch ipv6….Wenn ich mich vom VPN trenne, zeigt es die von Vodafone zugewiesenen ipv4 und ipv6 Adressen an. Kann das ein Hinweis sein?

    Viele Grüße

  93. Helmut (Beitrag Autor)

    Eine IP-Adresse musst Du bei bestehendem Tunnel immer haben, da würde ich jetzt eher dem Tool misstrauen.
    Nochmal zum Zugriff auf Geräte über den Safari Browser. Geht das auch nicht, wenn Du in der URL-Zeile die IPv4-Adresse eingibst? Also die der Fritzbox beispielsweise.

  94. Heinzo

    Ok, da hast du bestimmt recht, OVPN zeigt mir sowohl ein private ipv4- als auch eine ipv6-Adresse an. Ebenso die ipv6 Server-Adresse, die gleichzeitig auch die Server-public-ip ist. Aber wie kann ich prüfen ob diese auch bei der Fritzbox ankommen und wie diese verarbeitet werden?!

    Nein, egal was ich eingebe, „fritz.box“ oder 192.168.178.1 oder auch die ipv6 Adressen, es kommt nichtst zurück. „Safari konntedie Seite nicht öffnen, da der Server nicht mehr antwortet“. Ich habe den Eindruck, dass im ersten moment die Seite aufgerufen werden will, aber dann durch irgend etwas blockiert wird… Wie gesagt, einzig das Ping kommt von allen Geräten zurück.
    Momentan völlig ratlos, was ich noch ausprobieren könnte.
    Vileleicht sollte ich anstell von OpenVPN einmal WireGuard ausprobieren. Aber mein Gefühl sagt mir, dass irgendwas in der Fritzbox blockiert. Also wäre das dann auch wieder Sinnlos…

  95. Heinzo

    …könnte eventuell der DNS-Rebind-Schutz etwas damit zu tun haben? Wenn ich die ipv6 Serveradresse des Raspberry-OVPN dort eintrage?! …ist mir grad eingefallen…

  96. Helmut (Beitrag Autor)

    Die 192.168.178.1 kannst Du bei aktivem Tunnel zwar pingen aber nicht im Browser aufrufen. Das kann ja eigentlich nicht sein, denn der VPN Server filtert ja keine Ports und IP-mäßig ist der Weg ja frei. (IPv6-Adressen kannst Du durch den Tunnel nicht aufrufen, der Tunnel macht nur IPv4)
    In welchem Netz befindet sich denn der Client? Im mobilen Internet? Oder im heimischen WLAN. In letzterem Fall könnten die Pings evtl. am Tunnel vorbei laufen? Hat Dein Netzwerktool auch eine Traceroute Funktion? Damit könntest Du den Weg der Datenpakete verfolgen. Vielleicht bringt das Klarheit.
    Du könntest auch mal versuchen eine IPv4 Adresse im Internet zu pingen, zum Beispiel 85.13.134.231 um zu sehen, ob die Pings nur intern funktionieren, oder auch ins Internet gehen.

  97. Helmut (Beitrag Autor)

    Nicht die IP-Adresse sondern den DynDNS-Namen solltest Du in jedem Fall dort eintragen. Siehe hier. Wenn der Client im heimischen WLAN ist, würde der Rebind Schutz verhindern, dass der Tunnel überhaupt aufgebaut werden kann. Das sind aber nicht die Symptome, die Du schilderst. Der Tunnel wird ja erfolgreich aufgebaut.

  98. Heinzo

    Ich seh schon, ich bin hier mit meinem Halbwissen völlig überfordert :-( ….
    Hier nochmal vielen Dank für deine Geduld!!

    Der Client greift über das Vodafone-Netz mit einer ipv6-Adresse auf den Server zu. Einen DynDNS habe ich nicht, der Zugriff erfolgt direkt auf die in der Fritzbox ausgewiesene öffentliche ipv6-Adresse.Tracefunktion hat das Tool nicht. Pingen kann ich alles, auch die ipv4 internetadresse. Die in meinem Netzwerk nicht vorhandenen ipv4-Adressen kann ich auch nicht anpingen, daher schließe ich, dass der ping auch korrekt arbeitet.

    Wenn ich dich nicht all zu sehr nerve, könnte ich dir einmal das Verbindungsprotokoll des clients per mail schicken? :-| …würde das helfen?

  99. Helmut (Beitrag Autor)

    Ja schick ruhig, aber das Log wird nur sagen, dass der Tunnel erfolgreich aufgebaut wurde. Sonst könnten die Pings ja nicht laufen.
    Hast Du denn von Deinem Provider eine statische IPv6-Adresse bzw einen Prefix bekommen, dass Du ohne DynDNS auskommst?

  100. Heinzo

    Nein, bis jetzt funktionierts :-) … gibt’s statische ip6-Adressen von Vodafone überhaupt?!

    Ich habe versucht die MyFritz-DNS über eine Portweiterleitung an den Rasperry in der Fritzbox zu konfigurieren, aber eine MyFritz-Freigabe bekomme ich nur eine TCP-Verbindung gebacken und nicht über ein UDP-Protokoll. Ich sag‘ ja, es könnte viel einfacher sein, wenn mann sich auskennt ;-)

  101. Helmut (Beitrag Autor)

    In der Tat, der Tunnel scheint zu stehen und er will wohl auch IPv6 weiterleiten. Hast Du PiVPN verwendet? Wenn ja, dann vermutlich eine neuere Version, die das auch kann.
    Ein Eintrag gefällt mit nicht:
    [dhcp-option] [DNS] [1.0.0.1]
    Ist der beabsichtigt und gibt es unter der Adresse einen DNS-Server? Der erklärt aber nicht Dein Problem.

  102. Helmut (Beitrag Autor)

    UDP musst Du bei der MyFritz Freigabe von Hand zusätzlich nachtragen.
    Mit der Konfiguration der IP fliegst Du halt in ein paar Stunden auf die Schnauze, sobald Dein Provider den Prefix ändert. Dann stimmt Deine Konfiguration nicht mehr.

  103. Heinzo

    Es geht!!! :-)
    …manchmal steckt der Teufel im Detail.
    Ich habe die Verbindung mit einem anderen Iphone hergestellt und siehe da, es schnurrt wie ein Kätzchen!

    Jetzt gibt es zwei Möglichkeiten. Entweder es liegt an der Vodafone-Mobil-Verbindung, da das funktionierende mit Telekom läuft (kann ich mir aber nicht vorstellen), oder es liegt daran, dass ich auf dem Iphone eine Beta-IOS-Version 14.0 installiert habe und das noch Fehler hat (ich muss ja immer allen Mist ausprobieren…war ein fehler). Dann muss ich das zurücksetzen.
    Das kann ich aber erst heute Abend heraus finden, wenn ich an das Iphone meiner Frau ran komme ;-)
    Ich berichte…..wenn es euch interessiert :-)

    Die MyFritz-Freigabe werde ich noch einrichten, jetzt weiß ich ja, dass es funktioniert. Hoffentlich kriege ich das auch noch hin…..

  104. Helmut (Beitrag Autor)

    Ich bin gespannt. Das interessiert sicher auch andere Leser.

  105. Heinzo

    Also jetzt ist es Gewissheit und ich bin mit meinem Latein wieder am Ende!
    Es muss definitiv am mobilen Netz von Vodafone liegen!
    Nachdem es auf dem Iphone meiner Frau auch nicht funktionierte, hab ich die Simkarte von der Telekom eingesetzt und alles hat wieder funktioniert.
    Wie soll ich das jetzt wieder herausbekommen an was es liegt?
    Hast du eine Idee, oder soll ich mich mal prophylaktisch bei Vodafone beschweren?

    Die Abfrage unter test-ipv6.com ergibt, bis auf den Netzanbieter, eigentlich die gleichen Werte, alles Bestens…. aber irgend wo muss doch der Unterschied liegen!

  106. Helmut (Beitrag Autor)

    Interessant. Schau mal auf die Logs von OpenVPN-Client, ob Du da Unterschiede findest.
    Eigentlich ist es ja so: Entweder es lässt sich ein VPN-Tunnel aufbauen, oder nicht. Wenn er mal aufgebaut ist, dann sollte alles keine Rolle mehr spielen, was der Tunnel erfolgreich durchquert hat, also Mobilfunknetz, Router, usw.

    Funktioniert es denn eigentlich auch, wenn Du mit Deinem Client im heimischen WLAN bist?

  107. Heinzo

    Dachte ich auch, aber irgend ein unterschied muss ja dann trotzdem sein. Die Logs vergleiche ich noch…
    Im heimischen WLAN funktioniert es….aber nur Netzwerk intern!! Ins Internet komme ich nicht…..wird immer suspekter ….doch irgend ein DNS Problem ?!

  108. Heinzo

    Komischerweise, Google geht… aber weiter nicht…. Links aus Google aufrufen geht zwar, aber komme nicht dort an….

  109. Heinzo

    So, hab jetzt WireGuard installiert und alles geht!
    Hast du noch eine Idee wie ich die MyFritz Adresse in die Client.conf reinbringe?
    Wenn ich den client file dann aufs Handy spiele nimmt er es nicht an weil es angeblich keine WireGuard Konfiguration ist.
    Die reine ipv6 Adresse funktioniert einwandfrei.

  110. Helmut (Beitrag Autor)

    Zu WireGuard kann ich nichts sagen, aber da wird es doch auch eine Möglichkeit geben, ein Client-Konfigurationsfile zu erzeugen.

  111. Daniel

    Hallo,

    erst mal schönen Dank für die Anleitung !

    Ich habe jetzt nur noch das Problem, dass ich nicht per Smartphone auf den VPN zugreifen kann, trotz D1 Netz mit IPV6. (DS-Lite Anschluss, Glasfaser, somit dürfte IPV6>IPV6 funktionieren)

    Intern per WLAN klappt das verbinden wunderbar.

    Im OpenVPN Client erscheint lediglich „Waiting for Server“. Die DNS Auflösung ist auch korrekt. Die Freigaben in der Fritz sind gesetzt, in diesem Fall Port 448. Auch mit anderen Ports das selbe Problem.
    Anpingen lässt sich der Raspi per Smartphone.

    Hat jemande eine Idee ?

    Danke im voraus.

  112. Helmut (Beitrag Autor)

    Nochmal schauen, ob die Freigaben auch per UDP gesetzt sind.

  113. Daniel

    Danke für die Antwort.

    Die Freigaben sind per UDP in der Fritz gesetzt. Demnach weiss ich echt nicht, was das noch sein könnte das es nicht funktioniert.

  114. Daniel

    Was noch zu erwähnen sei, dass ich ohne Probleme von unterwegs auf die Fritzbox zugreifen kann.

    Ich poste mal die xx.ovpn vom client und die Server .conf, vielleicht hilft das weiter.

    client
    dev tun
    proto udp6
    remote XXXX.dedyn.io 448
    resolv-retry infinite
    nobind
    remote-cert-tls server
    tls-version-min 1.2
    verify-x509-name VPN_1615b509-681e-4ec3-b675-8cd075343632 name
    cipher AES-256-CBC
    auth SHA256
    auth-nocache
    verb 3

    <<<<<<<<<<<<<<<
    dev tun
    proto udp6
    port 448
    ca /etc/openvpn/easy-rsa/pki/ca.crt
    cert /etc/openvpn/easy-rsa/pki/issued/VPN_1615b509-681e-4ec3-b675-8cd075343632.crt
    key /etc/openvpn/easy-rsa/pki/private/VPN_1615b509-681e-4ec3-b675-8cd075343632.key
    dh none
    ecdh-curve prime256v1
    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 "dhcp-option DNS 8.8.4.4"
    # Prevent DNS leaks on Windows
    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"
    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.io

  115. Helmut (Beitrag Autor)

    Wenn Ping geht, aber der VPN-Client trotzdem keine Verbindung aufbauen kann, muss irgendwo noch ein Fehler versteckt sein. Schau Dir DDNS nochmal genauer an. Wird nur eine IPv6-Adresse aufgelöst und keine IPv4? Bekommt der Client die richtige IPv6-Adresse? Was ist im eigenen WLAN anders? Läuft der Tunnel dort über IPv6?

  116. Daniel

    Hallo Helmut,

    jetzt funktioniert’s endlich. Ja das Problem lag am DDNS.
    Zuvor lief die Verbindung nur über UDPv4 im WLAN und über Mobil tat sich wie erwähnt nichts.

    Beim DDNS hatte ich die IPV6 Adresse des Routers drin(was auch so sein müsste ??). Jetzt hab ich die vom raspi hinzugefügt und es läuft.

    Schönen Dank für die Hilfe !!

  117. Helmut (Beitrag Autor)

    Prima. Bei IPv6 brauchst Du für DDNS nur die IP-Adresse des VPN-Servers. Die des Routers nur, falls Du den von außen administrieren möchtest.

  118. Wolfgang Pühl

    Ich habe meine Probleme mit dem Script!
    Es läufte bei meinen Versuchen eigentlich ganz schön durch, aber dann endet es mit „ERR Failed to download EsayRSA

    Ich habe das script angesehen und verucht unter der in den Einstellungen gesetzten url …download.sourceforge… easyrsa zu finden, aber das ergibt nix.
    Kann ich den Teil im Script auskomentieren und (bevor ich das Script laufen lasse) easy-rsa per apt installieren.
    Ich habe es oft versucht, auch unter manuellem Entfernen von openvpn und easysra, nix führt zum Erfolg
    Können Sie mir helfen?

  119. Helmut (Beitrag Autor)

    Hört sich so an, als wollte PiVPN easy-rsa installieren, aber der Downloadlink funktioniert nicht. Ich würde probieren, easy-rsa vorher von Hand zu installieren. Dann sollte PiVPN erkennen, dass es bereits vorhanden ist.

  120. Christoph

    Hallo Helmut,

    ich bin seit mehreren Stunden dabei und bekomme es einfach nicht hin.

    Ich habe exakt deine Anleitung befolgt und alle Voraussetzungen was eine IP6 und IP4 am Smartphone und der Fritzbox sind auch erfüllt. Habe die Port Konfiguration inzwischen auf Port:220 gesetzt, was leider nichts daran ändert. Ich komme einfach nicht weiter, vielleicht kannst du etwas erkennen, siehe unten das Logging. Auf der Fritzbox sind die Portfreigaben erstellt und Funktionsfähig. Wichtig zu erwähnen ist, das die Verbindung ueber W-LAN im Heimnetzwerk funktioniert.

  121. Anonymous

    Hallo Helmut,

    komme einfach nicht weiter. Local im W-Lan funktioniert es und über Mobilfunk nicht.

    Bin schon den halben Tag dabei. Habe exakt deine Anleitung befolgt. Oben das Logging.

    Gruß

    Christoph

  122. Helmut (Beitrag Autor)

    Bitte hier keine langen Loggings posten, das macht die Kommentare recht unübersichtlich. Falls nötig kannst Du mir die per E-Mail schicken.
    Was hast Du denn vor?
    Du scheinst per IPv6 verbinden zu wollen und Dein Mobilprovider ist Vodafone.
    Was für einen VPN-Client setzt Du denn ein? Bekommst Du von Vodafone überhaupt eine IPv6-Adresse?

Schreiben Sie einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.