OpenVPN und IPv6 – Ein harter Kampf!

OpenVPN und IPv6 – Der Kampf beginnt!

Da IPv6 immer mehr Gewicht gewinnt, wollte ich mich bereits für die Zukunft vorbereiten und meine Seiten unter IPv6 erreichbar machen. Kann ja nicht so schlimm werden, dachte ich, IPv6 ist ja nun wirklich nichts neues mehr und nachdem ich S4U gänzlich den Rücken gekehrt habe, habe ich jetzt auch viel mehr Möglichkeiten 😉 

Also war meine erste Frage – Wo fange ich an? Wieso? Wenn ich eins umstelle dann muss ich auch den Rest umstellen da MySQL, Webserver Monitoring, API’s Proxy usw. dann alle IPv6 können müssen damit es auch alles funktioniert.

Aber ich schweife ab. Wir waren bei OpenVPN und IPv6. Damit habe ich auch angefangen, gestern…. (Eigentlich begann ich mit Proxmox aber das kommt später 😉 , da ich weiß dass mein Kollege von Layers Gedanken damit gerade viel Anfangen kann 🙂 )

Mein OpenVPN Setup mit IPv6

Ich wollte unbedingt ein privates IPv6 Subnetz haben für die ganzen OpenVPN Geschichten da ich so zum einen von außen nicht überall erreichbar bin und ich wenig Lust hatte 18 Millionen IPv6 Adressen manuell zu erstellen und ein geroutetes Subnetz gibt es nur gegen Aufpreis. Außerdem ist so ein wenig mehr Kontrolle gegeben und man kann mit den netten iptables Regeln nicht ganz so schnell durcheinander kommen.

Also habe ich mir das fd8b:75bb:54e8:9a87::/64 ausgesucht. Das ist für private Zwecke Analog den 192.168.0.0/24er Netzen. Der OpenVPN Server hat ein 64er public Subnetz wo er für den VPN Dienst eine Public IPv6 nutzt. 

Ich gehe hier also davon aus, dass mindestens eine public IPv6 auf dem Server bereits konfiguriert ist und einer Netzwerkkarte zugeordnet ist und das OpenVPN bereits mit einer IPv4 Konfiguration läuft (Falls nicht ist hier eine Anleitung) und der Kernel natürlich IPv6 kann.

 

Beginnen wir also.

Die OpenVPN server.conf anpassen

Hier muss gar nicht so viel angepasst werden.

Fügt einfach diese Zeilen hinzu und ersetzt ggf. mit eurem Subnetz 🙂

Die Datei liegt Default unter /etc/openvpn

server-ipv6 fd8b:75bb:54e8:9a87::/64 # Das IPv6 Subnetz
push "route-ipv6 fd8b:75bb:54e8:9a87::/64" # Route vom OpenVPN Subnetz
push "dhcp6-option DNS fd8b:75bb:54e8:9a87::1" # OpenVPN private IP und gleichzeitig der DNS
tun-ipv6 # gehört eigentlich an den Anfang der OpenVPN config
proto udp6 # gehört auch an den Anfang
client-config-dir ccd # falls nicht vorhanden bislang 

So blöd es klingt. In der server.conf war es das bereits 🙂

 

Als Nächstes aktivieren wir das IPv6 forwarding

sysctl -w net.ipv6.conf.all.forwarding=1

Dauerhaft sollte man in der /etc/sysctl.conf folgendes eintragen

net.ipv6.conf.all.forwarding=1

 

Ein paar iPtables Regeln wären auch cool fürs Maskieren

ip6tables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT
ip6tables -A INPUT -i tun+ -j ACCEPT 
ip6tables -A FORWARD -i tun+ -j ACCEPT
ip6tables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -t nat -A POSTROUTING -s fd8b:75bb:54e8:9a87::/64 -o eth0 -j MASQUERADE

Müssen natürlich an eure Ports, Netzwerkkarten und euer Subnetz angepasst werden. Eh klar 🙂

Wie man diese Regeln permanent macht sollte jeder wissen. Falls nicht würde ich an dieser Stelle ernsthaft überlegen den Server zu kündigen. Ihr könnt aber auch gern nachfragen.

Ein Hinweis aber am Rande, solltet Ihr einen virtuellen Server haben der auf Openvz Basis läuft dann könnt Ihr euch das sparen denn der Kernel der aktuell bei OpenVZ eingesetzt wird ist zu alt für IPv6 NAT. Ihr braucht entweder einen richtigen dedicated Root, KVM oder LXC (Alles was den Kernel 3.2 und höher benutzt funktioniert)

Sollte euer IPv6 Netz public sein dann braucht Ihr natürlich keinerlei NAT

Die Client config

Klar, die sollte nicht fehlen.

Fügt folgende Zeilen in eure Client config ein

tun-ipv6
proto udp6
remote 2a05:8b81:1000:14e::d7b9 1194 # Hier sollte unbedingt eure public IPv6 stehen

Das war es auch schon fast. Sollte man auf einem Windows Client den gesamten IPv4 und IPv6 durch den Tunnel jagen wollen, so muss nur die “redirect-gateway mit dem IPv6 Flag erweitert werden

redirect-gateway ipv6

Wichtig, wirklich nur das IPv6 ergänzen und nicht die Zeile zusätzlich einfügen, da der String  “redirect-gateway” nur einmal vorkommen darf.

Statische IP vergeben da keine automatische Vergabe stattfindet

Eine Kleinigkeit die unbedingt gemacht werden muss. In eurem “ccd” Verzeichnis, welches in der server conf angegeben wird, muss für jeden Client, der eine IPv6 erhalten soll, noch zusätzlich folgender Eintrag hinterlegt werden:

ifconfig-ipv6-push fd8b:75bb:54e8:9a87::2/64 fd8b:75bb:54e8:9a87::1/64

Die erste IPv6 ist dabei eine statische IPv6 für den Client und die zweite IPv6 das Gateway.

Einen Nachteil hat das ganze. Man muss alle Routen mittels up Script selbst anlegen. OpenVPN kann das bei IPv6 leider noch nicht.

Windows Clients müssen, zum Zeitpunkt des Beitrags, mindestens den OpenVPN-2.4-alpha2 Client haben damit es überhaupt funktioniert.

Download OpenVPN Client 64 2.4 Alpha2 64 Bit

Download OpenVPN Client 64 2.4 Alpha2 32 Bit

Das sind derzeit die aktuellsten Versionen. Updates können hier runtergeladen werden.

 

Und nun Willkommen in der IPv6 Welt!

Wenn man sich das alles mühsam zusammensuchen muss und nichts irgendwo richtig dokumentiert ist, kann man damit ohne Probleme eine ganze Nacht und den folgenden Vormittag verbringen. Nicht zu vergessen der Abend zuvor 🙂 

Hoffentlich spart Ihr euch ein paar Stunden!

Share it!Share on FacebookEmail this to someoneShare on Google+Tweet about this on Twitter

13 Gedanken zu “OpenVPN und IPv6 – Ein harter Kampf!

  1. Hallo,

    vielen dank für die super Beschreibung!
    Es funktioniert auf anhieb und ich habe danach länger gesucht, jetzt versuche ich das ganze über tcp6 zum laufen zu bringen, nur leider funktioniert dies nicht so einfach.

    Würde mich über eine Antwort dazu sehr freuen, danke schon mal.

    Gruss Patrick

    • Hi Patrick,
      freut mich wenn es problemlos ging.

      das ganze via TCP ist eigentlich relativ easy umzusetzen. Ich rate jedoch von TCP Verbindungen generell ab.
      Der Ansatz war schon richtig, einfach ein tcp6 anstelle des udp6 einsetzen und das natürlich am Server und client.
      Dann sollte die Verbindung auch funktionieren.

      Welche Fehlermeldung / Logs kommen denn?

      • der Client schreibt folgendes:

        “TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)”

        Leider benötige ich das ganze in TCP da ich einen Portmapper verwenden möchte um über das Handy eine verbindung aufbauen zu können.

        Die Server Logs zeigen nichts.
        Danke

        Gruss

      • der Client schreibt folgendes:

        “TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)”

        Leider benötige ich das ganze in TCP da ich einen Portmapper verwenden möchte um über das Handy eine verbindung aufbauen zu können.

        ich vermute es liegt an den IP6Tables

        Die Server Logs zeigen nichts.
        Danke

        Gruss

        • Hmm… wie sieht denn das gesamte Log aus?
          Von dem Ausschnitt würde ich sagen dein Client kann entweder den Host nicht auflösen oder wird tatsächlich via iPtables geblockt.

          Kannst du mal nen normales TCP probieren ohne die v6? Klappt diese Verbindung? Bekommst du da eine IPv6 im Client zugewiesen?

          • Also mittlerweile habe ich es geschafft es richtig einzurichten. Ich war auf einem Port welcher belegt war durch ein anderes Programm. Danke für die Hilfe, ich werde den Artikel gerne mal weitersagen auf meiner Website.

          • Hi Patrick,

            okay dann war es kein Fehler in der Anleitung 🙂
            Ports sollten natürlich frei sein, klar.
            Freut mich wenn ich helfen konnte und Danke fürs sharen 😉

            LG
            André

  2. Pfui NAT,
    Das ist nicht Teil der IPv6-Welt, sondern der Hölle.
    Aber schön zu wissen, dass auch teuflische Dinge funktionieren.

    • Durchaus aber Maskieren ist nun mal notwendig sofern man ein privates IPv6 Netz verwendet. Andernfalls gibts keine Verbindung ins Internet…
      Ein Public IPv6 Netz braucht das logischerweise nicht 😉
      Habe den Hinweis aber ergänzt. Danke

  3. Vielen Dank an den Autor.
    Wow echt mal die beste Anleitung für OpenVPN bisher. Ich hab mich halb tot gegoogelt und schon mindestens 5 andere Anleitungen abgearbeitet, aber spätestens beim IPV6 Thema ging dann nichts bei den meisten Autoren nichts mehr. Auch die breite der Ausführung is einzigartig. Viele schreiben eine Seite und verlieren dann die Lust oder setzen kann eine Menge vorraus, wo dann ein Noop wie ich in einer Sackgasse endet. Also echt mal ganz großen Dank für dein echt spannend geschriebenen Artikel.
    Ich hab soeben grade das erste mal eine erfolgreiche Verbindung aufgebaut. *juhu*

    So wie soll es anders sein… Ich hab noch ein paar blöde Fragen wo eure Erfahrungswerte mich sicher um Lichtjahre weiterbringen können. Also ich wollte dann die Verbindung testen. Ich hab auf dem raspberry pi ssh aktiviert und via Putty die IPV6 als Connection eingetragen. Einloggen klappt dann. Aber ging das über die VPN Leitung? Also beim ersten Connect kam ganz kurz der Key Exchange…

    Aktuelle habe ich den Test erst mal von einem Windows 10 Client aus probiert. Mein Ziel ist es auf meinem S7 das Openvpn zum laufen zu bringen.

    Im Log bei dem Windows 10 Versuch sehe ich folgende roten Einträge:
    >”Tue Apr 03 21:32:32 2018 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.”
    #-Bedeutet das soviel das ich in meiner .ovpn Datei die Zeile “tun-ipv6” weglassen soll? Ich möchte ja Android nutzen. Brauche ich da dann die Zeile doch noch oder kann die weg?

    Wie ich schon schrieb möchte ich das ganze via Handy aus dem Mobilfunk Netz Congstar nutzen.
    Da ich ein Unitymedia “DS-Lite”-Opfer bin kann ich ohne Portmapping also keine IPV4 Verbindungen zu meinem VPN Server aufbauen. Aber das stört mich gar nicht, weil Congstar (Telekom) bereits IPV6 IP´s vergeben und damit sollte ich eine IPV6-IPV6 Verbindung aufbauen können.

    Ich habe einen Dynamic DNS Anbieter (spdyn.de) der auch IPV6 kann. Mir war etwas unklar wo ich diese Dyn.DNS Domain eintragen muss. Reicht es dann statt der lokalen IPv6 die ich aktuelle in der OVPN Datei drinnen hab einfach meine dyn. Dns Adresse einzutragen? Also so etwa: remote xy.spdns.xy 1194

    Von Routings habe ich bisher leider nur viel wenig Ahnung. Ich möchte den IPV6 VPN Server nutzen, um z.B. auf meine Fritzbox im ersten Step zuzugreifen. (Ich hab da ein paar Smarthome Experimente die via IPv4 super liefen.)
    #-Wie kann ich den Trafic auf meine Fritzbox routen? Ich schätze ich muss irgendeine Route erstellen für die IPV6 (oder IPV4?) der Fritzbox?

    #-Im Log der VPN Verbindung habe ich dann noch ein paar rote Einträge gefunden. Vielleicht kann jemand noch was dazu sagen?
    -“Tue Apr 03 21:32:32 2018 WARNING: –ns-cert-type is DEPRECATED. Use –remote-cert-tls instead.”
    #-Klingt schlimm?!?

    ” WARNING: ‘tun-ipv6’ is present in remote config but missing in local config, remote=’tun-ipv6′”
    #-Ok also muss ich die Zeile auch noch in der Server Config checken?

    Dann noch einige Warnmeldungen wegen Unsicherheit:
    “WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a –cipher with a larger block size (e.g. AES-256-CBC).”
    “WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.”
    #-Das klingt ja toll, aber wie macht man das? Ist das überhaupt nötig…Also ich bin weder reich noch ein super gutaussehendes Model..also kein wirklich attraktives Ziel ;-}

    Vielleicht hat ja jemand noch ein paar Tips. Gerne auch in Form von Links wo ich mich schlau lesen kann.
    Vielen Dank auf jedenfall noch Mal für die super spannende Anleitung.
    So gut hat das bisher noch niemand im Netz veröffentlicht.
    Danke
    Grüße
    Oli

    • Hi Oli,

      vielen Dank für die Blumen 🙂
      Ich bemühe mich immer die Anleitungen und anderen Beiträge nicht für die Profis da draußen zu schreiben sondern für die Leute die es wirklich brauchen können. Ich muss gestehen, dass ich auch vorab jeden Artikel durch einen Kollegen, der nicht so Technik versiert ist, testen lasse und dann die Stellen ausbessere die schwer verständlich sind oder Probleme bereiten.
      Freut mich wirklich wenn man das raus liest und auch zu schätzen weiß 🙂

      Zu deinen Fragen. Welche Route dein Client genommen hat kannst du am besten über die CMD herausfinden. Auf Windows Maschinen wäre es mit dem Befehl “tracert” möglich und auf Linux mit traceroute.

      Auf dem Handy ein VPN einrichten ist relativ easy, OpenVPN gibt es als App und du musst nur noch die configs aufs Handy kopieren und dann importieren. Leider habe ich aktuell kein Android Gerät im Haushalt aber solltest du nicht weiterkommen, melde dich gern. Dann organisiere ich eines.

      Die Option tun-ipv6 ist mittlerweile bei wenigen Clients tatsächlich unnötig aber das ist abhängig von der Client und OS Version.
      Sie schadet zumindest nicht wenn du diese drin lässt 😉

      Die DynDNS Adresse wäre abhängig davon was du erreichen willst. Ich lese heraus, dass dein Server daheim steht und dann wäre in der tat die remote Zeile mit deinem DynDNS Host zu ersetzen.

      Routings und Fritzbox… Soweit ich weiß kann die Fritzbox doch OpenVPN bereitstellen? dann bräuchtest du dir keine Gedanken um die Routings machen. Das erledigt die Fritzbox selbst.
      Wenn dein Server nicht die Fritzbox direkt ist, dann musst du in der Server config noch dein Subnetz eintragen ala “push route 192.168.172.x/24” oder wie auch immer dein Heimnetz ist. Ich denke aber dass dein Server auf der FB läuft?

      ns-cert kannst du bedenkenlos austauschen.

      Zum Cipher kann auch ich dir nur zum switch raten.
      Dazu einfach in der Serverconfig die Zeile anpassen
      cipher AES-128-CBC
      den Server neustarten und anschließend auch die Zeile in den Clients anpassen.
      Das hat weniger etwas mit gut aussehendes Model oder Reich sein zu tun. Du willst deinen Traffic ja verschlüsseln also ist da auch irgendetwas was es für dich lohnenswert macht diesen zu verschlüsseln. Das sollte dann auch entsprechend sicher sein. Nicht zu guter letzt auch zum Eigenschutz denn wenn da mal einer drin ist, mit deiner IP Online bestellt etc. dann hast du den Ärger 😉
      Deine PIN der Geldkarte steht ja auch nicht auf der Geldkarte *hope so*. Warum also hier ein Risiko eingehen wenn es nur eine Zeile in der Server und Client config ist? 🙂

      Hier ist noch, falls noch nicht gesehen, eine Anleitung für Android und auch den Server an sich. Ich würde sagen den gesamten Teil brauchst du nicht lesen aber ein paar Anregungen / Verbesserungen wirst du noch finden zu deinem derzeitigen Setup 🙂
      https://www.sugar-camp.com/anleitung-openvpn-server-auf-debian-7-8-installieren-und-anschliessend-mit-android-ios-oder-windows-verbinden/

  4. Hi Andre,
    na in Blumen hättest du ne ganze Wiese verdient 😉
    Man merkt auf jeden Fall einen Unterschied… das würde ich schon weit über dem einordnen was ich sonst wo gefunden habe. Ich hab eine Magazine Flatrate und dort sind auch diverse Linux;raspberry, pc, Netz (…) Magazine dabei und man kann sehr cool über alle jemals veröffentlichten Artikel nach Stichworten suchen und von den ~200 Treffer zu OpenVPN war keiner so brauchbar. Die meisten kamen, wie gesagt, nicht über IPV4 raus.
    Meine Systembeschreibung habe ich ganz vergessen. Ich habe zwar eine Fritzbox Cable 6490 und die hat ein VPN Modul, aber es ist wohl nicht OpenVpn und der peinliche Part für AVM. Es kann auch nach Hersteller Angaben keine reinen IPV6 VPN Verbindungen. Also nur IPV4 support. Was echt mal traurig ist.
    Außerdem hat AVM die Latte für den Telnet SSH Zugriff deutlich erschwert…ich würde es sicher hin kriegen, aber die Zeit ist es mir nicht wert. Zudem wäre es nicht unwahrscheinlich, dass ich bei einem Fehler eine Weile kein Netz mehr habe. Never touch a running system ;-}
    Ich hab dann mal in meiner unendlichen Hardware Halde geschaut und einen älteren Raspberry Pi gefunden. Eine der ersten Anleitungen war auch für einen PI und mir geht es auch darum den Stromverbrauch nicht unbedingt unnötigt hoch zu schrauben. Ich nutze das ganze als Test und um mit der Thematik wärmer zu werden. Schützenswert ist da nur wenig. Ich selber möchte auf meine Fritzbox und etwas von extern an meinen Smart Home Projekten von extern arbeiten/testen können. Android Devices habe ich ziemlich viele…und auch damit habe ich coole Projekte gemacht. Aus einem alten Handy kann man sehr energiesparend auch ein Babyphone oder Einbrecher/Raumüberwachung machen….Also da ich keine Kinder oder wertvolle Dinge habe ist es auch nur so ein theoretisches Projekt. 😉

    Zum Thema Sicherheit ist schon wichtig. Ich habe alles voll verschlüsselt und habe das Thema vor Jahren auch auf Arbeit voran getrieben.

    Mensch auf das “tracert” hätte ich auch kommen können….aber in dem Fall hatte es nur ein hop, weil beide am gleichen Switch hängen. Aktuelle habe ich ja nur von inter getestet. Inzwischen kriege ich ohne VPN in alle Richtungen auch vom Andoid (WLAN Subnetz => PI LAN Subnetz) einen Ping.

    Die Config ist bei mir aber noch gar nicht sauber…ich hab nun versucht die Config zu ändern und hab dannach ein sudo service openvpn stop/start gemacht. Bei Cipher habe ich dann mal AES-256-CBC
    (aber auch mal die 128er Variante) reingenommen. Erst am Server und dann am Client…. Und dann hatte ich deutlich mehr rote Meldungen im Log.
    Die Meldung war glaube ich schon vorher…

    Thu Apr 05 20:49:23 2018 WARNING: –ns-cert-type is DEPRECATED. Use –remote-cert-tls instead.

    Nun hat er wohl noch ein MTU Thema…wobei ich nur den Cipher Wert geändert habe… ich vermute mal die Pakete sind vielleicht deswegen größer geworden…. 1500 ist ja der default bei Windows….

    Thu Apr 05 20:49:26 2018 WARNING: ‘link-mtu’ is used inconsistently, local=’link-mtu 1542′, remote=’link-mtu 1558′

    Was echt seltsam ist, ist dass er immer noch mit der Cipher Meldung kommt… ich hab es so im Gefühl, dass ich wohl alle Keys neu machen muss…oder neu initialisieren…Beim Pi dauert das Ewigkeiten.

    Thu Apr 05 20:49:26 2018 WARNING: ‘cipher’ is used inconsistently, local=’cipher BF-CBC’, remote=’cipher AES-256-CBC’
    Thu Apr 05 20:49:26 2018 WARNING: ‘keysize’ is used inconsistently, local=’keysize 128′, remote=’keysize 256′
    Thu Apr 05 20:49:27 2018 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a –cipher with a larger block size (e.g. AES-256-CBC).
    Thu Apr 05 20:49:27 2018 Outgoing Data Channel: Using 160 bit message hash ‘SHA1’ for HMAC authentication
    Thu Apr 05 20:49:27 2018 Incoming Data Channel: Cipher ‘BF-CBC’ initialized with 128 bit key
    Thu Apr 05 20:49:27 2018 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a –cipher with a larger block size (e.g. AES-256-CBC).
    Thu Apr 05 20:49:27 2018 Incoming Data Channel: Using 160 bit message hash ‘SHA1’ for HMAC authentication
    Thu Apr 05 20:49:27 2018 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.

    Und am Ende noch mal diese Meldung….

    Thu Apr 05 20:49:37 2018 Authenticate/Decrypt packet error: cipher final failed
    Thu Apr 05 20:49:48 2018 Authenticate/Decrypt packet error: cipher final failed
    Thu Apr 05 20:49:57 2018 Authenticate/Decrypt packet error: cipher final failed
    Thu Apr 05 20:50:08 2018 Authenticate/Decrypt packet error: cipher final failed

    Ich werde den Pi am Wochenende sowieso neu aufsetzen und das ganze noch mal neu installieren.
    Der kleene Raspberry kriegt gleichzeitig eine etwas flottere Speicherkarte, aber der Falschenhals ist vermutlich die CPU. Mein erstes Ziel wird es sein, dass die Windows => PI IPV6 VPN Verbindung klappt.
    Die Konfiguration kann ich ja dann auch auf einem Android Device nutzen…. Dort kam bei meinem ersten Test auch eine Fehlermeldung. Also direkt lief die unter Windows funktionierende Konfiguration nicht. Aber gefühlt lag es eher an der Android OpenVPN App.

    Das mit dem “push route 192.168.2.x/24” müsste ich gemacht haben….

    Ich muss mal schauen, ob ich an irgendeiner Stelle bei der Neueinrichtung diese höhere Cipher Sicherheit auswählen kann. Ich meine aber, dass das schon so war…. Oder vielleicht braucht es auch nur eine Art Reinitialisierung der Keys…. da habe ich zu wenig Erfahrung. Ich bin mal gespannt, ob ich es beim nochmaligen Aufsetzen am Wochenende wieder zum laufen bringe.
    So zum Schluß noch Fragen:
    -Welche Routen brauche ich unbedingt? Und was ich eher unwichtig/optional?
    Ich muss wohl vom PI eine zur Fritzbox machen

    -Also das mit dem eigenen getrennten Subnetz für IPV6… Braucht man das?

    -Muss man etwas spezielle beim Dynamic DNS Anbieter machen? Und muss ich die IPV6 von der Fritzbox aus hochladen lassen? Kriegt man dann überhaupt den PI? Oder muss man vom PI ein Upload von dessen IPV6 machen? Woher kennen die meinen Port? Durch die Verwendung der Domain? xyz.spDNS.eu:1194 oder so?
    -Port technisch hat mir übrigens ein Kollegen der Watchguard VPN Guru ist geraten statt 1194 den Port 443 zu nehmen, weil wenn IPv6 verbreiteter ist kann man dann auch eher über diesen Port aus femden Netzen raus kommen. Das deckt sich mit meinen Erfahrungen….Hotel WLAN usw haben 1194 oft gesperrt oder nicht erreichbar.

    Danke für den Link…. das lege ich mit dazu…. Ich mache es wieder komplett von IPV4=>IPV6 einmal durch.
    Also kurz… Es bleibt sehr spannend 😉

    Merci auf jeden Fall für deine schnelle Antwort.
    Grüße
    Oli

    • Hi Oli,
      für Blumenwiesen ist es noch zu kalt 😉

      Klingt nach vielen spannenden Projekten bei dir. Kann man dazu was lesen irgendwo?
      Von diesen PC Zeitschriftenanleitungen halte ich persönlich rein gar nichts denn wer hat schon Laborbedingungen zu Hause? Auch stehen da nicht die vielen Stunden drin an denen die geschraubt und probiert haben bevor alles so funktionierte…

      Zu deinen Meldungen: Die ns-cert-type is deprecated war vorher schon da.

      Der Windoof default MTU liegt genau genommen bei 1492.
      Wenn du in deiner lokalen config jedoch link-mtu 1558 einfügst, sollte die verschwinden. Unabhängig davon ist diese Meldung kein Drama. Der Wert wird eh automatisch angepasst beim Aushandeln der Verbindung (soweit die Windoof theorie)

      Deine Ciphermeldungen sagen ganz klar, dass deine lokale (client) config nicht den AES-256-CBC benutzt sondern BF-CBC
      Also, Server config sollte passen. VPN trennen und dann noch mal die Config checken, vielleicht ging beim Speichern was schief??

      Die Authenticate Meldungen sind ein logisches Resultat aus obiger Inkonsistenz.

      Die Cipher haben nichts mit den Keys zu tun. Das ist völlig Banane. Das ist eine reine config Geschichte.

      Zu deinen Fragen:
      Routen nur die die aktuell eingerichtet sind, die funktionieren ja 😉
      Ein getrenntes privates v6 Subnet ist nicht zwangsweise benötigt. Kommt eben drauf an ob du dein vom Anbieter zugewiesenes v6 Netz bis zum VPN Server durchreichen kannst. Diese 64er Netze ändern sich ja auch wie die v4 Adresse bei einem reconnect der FB

      DynDNS kannst du nur zu Hostnamen X deine aktuelle IP mappen.
      Wenn du einzelne Ports dann erreichen willst, wie zum Beispiel dein VPN Server, musst du in der Fritzbox noch eine Portweiterleitung machen vom Port 1194 (oder welchen du auch immer gewählt hast) auf den internen VPN Server auf Port 1194. Protokoll (tcp oder udp) ist abhängig von deiner config.
      Der DYNDNS Anbieter an sich kennt den Port aber nicht und er braucht den auch nicht.

      Als Portempfehlung den 443?? Das ist unsinn! Immer mehr Webseiten werden verschlüsselt und der https Port ist und bleibt 443.. Ich habe auch noch nie erlebt das der Port 1194 in Hotels geblockt wird. Wohl eher das UDP Protokoll aber passieren kann natürlich beides ja.
      Wenn du den ändern willst / musst dann würde ich eher 81 / 8080 oder ganz abartig 56780 nahe legen. Letzterer klingt komisch aber war bislang nie gesperrt.

      LG
      André

Schreibe einen Kommentar