VPN zum FritzBox Server

[HabNeFritzbox]

Probiere es aus, sonst lässt den anderen Wert wo sagst dass es funktioniert.

 

[Networker_23]

Nachdem das Ganze am Wochenende einwandfrei funktioniert hat, treten die Probleme beim Verbindungsaufbau jetzt wieder auf. Ich bin ratlos - woran kann das liegen? MTU ist 1200. Bin am überlegen, mir die IPV4 Unterstützung zu buchen...

 

[HabNeFritzbox]

1418 macht auch Probleme?

Verwende doch sonst Wireguard VPN, dann läuft mit IPv4 und IPv6.

 

[Networker_23]

Dafür brauche ich die FritzBox Labor Firmware - richtig?

 

[HabNeFritzbox]

Richtig, dann könntest natives IPv6 nutzen, und die Konfig dürfte deutlich einfacher sein.

 

[PeterPawn]

1418 macht auch Probleme?

LOL ... hast Du den Rest des Threads auch gelesen?

Und woher nimmt man eigentlich die Gewißheit, daß

treten die Probleme beim Verbindungsaufbau jetzt wieder auf

die korrekte Formulierung ist und es nicht eher:

treten wieder Probleme beim Verbindungsaufbau auf

heißen müßte?

Ob das dieselben Probleme sind oder doch neue, sieht man immer noch am ehesten in den VPN-Protokollen und davon ist eben leider immer noch nichts zu sehen - weder die auf der FRITZ!Box-Seite, noch die aus dem SC auf dem Windows-PC. Also bleibt weiterhin nur die Option zu raten ... oder man sucht sich dann doch eine Alternative. Warum es offenbar keine Protokolle gibt, kann man ja auch nicht wirklich erkennen.

Aber zu den "Nebenwirkungen" einer solchen Alternative oder gar einer nativen IPv6-Verbindung steht da ja auch nichts wirklich:

Richtig, dann könntest natives IPv6 nutzen, und die Konfig dürfte deutlich einfacher sein.

- schon die Frage, ob die Gegenstelle überhaupt eine IPv6-Adresse hat, müßte man ja zuerst mal klären und wenn ich #11 noch einmal lese, dann steht da etwas von "7390 an IPv4-Anschluß".

Wie sollte es da einen Gewinn bringen, wenn man mit Labor-Firmware und WireGuard dann IPv6 als Transport-Protokoll benutzen kann? Woher weißt Du (@HabNeFritzbox) denn, daß die Gegenstelle nun doch IPv6 (und zwar "native", denn ansonsten braucht's da dann wieder Tunnel-Protokolle und auch die haben ihren eigenen Overhead) kann, obwohl das in #11 doch gar nicht steht?

---

Manchmal fragt man sich, ob das wirklich alles noch Sinn ergibt - eher gewinnt man den Eindruck, daß da nur mal "irgendwelche Ideen" in den Raum gehauen werden, die der "Absender" selbst nicht richtig begründen kann und diese "ausführlichen Beiträge", mit denen die wenigsten Fragesteller dann etwas anfangen können, doch nur zum Sammeln von Postings dienen. Kannst Du das nicht woanders machen, wo solche "Einwürfe" die Leute weniger von einer möglichen Problemlösung abbringen können? Oder vielleicht doch mal DEN GANZEN THREAD jeweils lesen, was dann - im besten Fall - der "Qualität" Deiner Antworten zugute kommen könnte?

 

[HabNeFritzbox]

Die 7590 könnte Wireguard bekommen, und man kann Wiregurad direkt auf dem Client probieren.

Bei IPv4 Anschluss ist Frage ob nur IPv6 nicht aktiviert wurde, oder nicht vorhanden ist.

 

[Networker_23]

Also der entfernte Anschluss unterstützt IP V4 und V6. Jetzt für mich Dummy mal zum mitschreiben ;-)

Welche Protokolle von der FritzBox und von Shrewsoft werden für eine Analyse genau benötigt und wo liegen die Protokolle ab (FritzBox 7390)?

 

[Peter_Lehmann]

Ich schreibe extra ganz langsam

Natives Wireguard baut seine Tunnel sowohl über IPv4 als auch über IPv6 auf. Und innerhalb des Tunnels können auch beide Protokolle benutzt werden.
Voraussetzungen:

1. Der ISP bietet beide Protokolle (also DS). Wenn nur DS-Lite, dann läuft der Tunnel eben "nur" über IPv6.
2. Bei der Konfiguration des WG-Servers ist es möglich, jeden einzelnen Endpunkt sowohl mit IPv4 als auch IPv6 zu konfigurieren. Also eine echte Dualstack-Konfiguration.
   Hier muss ich einschränkend bemerken, dass ich nicht weiß, was das "AVM-Wireguard" letztendlich in seinen Konfigurationsmöglichkeiten bringen wird. Ich nutze als WG-Server mit OpenWrt umgeflashte 4040 und 7412, und da kann ich wirklich alle Parameter setzen. Es ist natürlich auch möglich, dass AVM wie beim IPsec-VPN eine für ONU bewusst eingeschränkte Konfiguration ausliefert.

Meine Erfahrung ist, dass bei meinem Internetanschluss mit DS in so ca. 80% der Fälle die Tunnel über IPv6 aufgebaut werden. Das entspricht auch meinen Erfahrungen für die sonstige Internetnutzung. (Nachgewiesen in meinem pi-hole.)
Auch die Wireguard-App auf meinen beiden Androiden nutzt überwiegend für den Tunnel IPv6 - mittlerweile "können" das ja wohl auch alle Mobilfunk-Provider.

Ach ja, ich gehe bei meinen Bemerkungen natürlich vom WireGuard-VPN aus und nicht vom kastrierten AVM-IPsec. Sorry, ich hatte deinen Beitrag nicht vollständig gelesen und "Shrew" nicht beachtet. Aber in der c't habe ich gelesen, dass IPv6 mit der 7.50 generell funktionieren soll. Warten wir es ab …

 

[PeterPawn]

Die 7590 könnte Wireguard bekommen, und man kann Wiregurad direkt auf dem Client probieren.

Der "VPN-Server" ist aber keine 7590, sondern - nach dem bisher Geschriebenen - eine 7390. Die kriegt schon mal länger keine Updates mehr und es ist eher unwahrscheinlich, daß sich das mit FRITZ!OS 7.50 und WireGuard noch einmal ändert.

Eine VPN-Verbindung direkt "zum Client" (in diesem Falle dann irgendein PC mit VNC-Server) ist zwar auch eine Alternative, funktioniert dann aber wieder nur für exakt diesen einen Client - auch eine "Nebenwirkung", die man kennen und berücksichtigen sollte. Ein Zugriff auf andere Clients im LAN der 7390 funktioniert dann nur noch mit zusätzlichen Einstellungen an der 7390 (deren IPv6 auch "etwas wacklig", weil älter ist) oder wenn der PC als WireGuard-Gateway seinerseits NAT macht und die Pakete an andere Clients mit seiner eigenen Adresse aussendet, damit die Antworten auch wieder über ihn gehen würden.

Das hat - für mich - mit der ursprünglichen Frage nur noch wenig zu tun ... da war eben die FRITZ!Box der Peer für die IPSec-Verbindung, die gar nicht von der 7590 mit DS-Lite aufgebaut wurde, sondern mit dem "Shrewsoft VPN Client" auf einem Windows-PC - damit haben andere Geräte im LAN KEINEN Zugriff auf das entfernte Netz, was AUCH WIEDER ein Faktor ist, den man kennen und berücksichtigen sollte, wenn man so etwas konfiguriert. Das kann ein gewünschter Effekt sein ... oder man wußte es nur nicht besser.

Aber es bringt wenig, ständig neue Möglichkeiten in den Raum zu stellen, die mit den bisher bekannten Fakten kollidieren ... zumindest sollte man dann auch in der Lage sein, die Vor- und auch die NACHTEILE, die sich aus solchen Änderungen der "Rahmenbedingungen" ergeben, dem Fragenden zu erklären.

Am Ende hast Du jedenfalls mit Deiner "WireGuard-Idee" die bisherigen Umstände an BEIDEN ENDEN der VPN-Verbindung schlicht ignoriert ... der Ausgangspunkt für den Aufbau einer VPN-Verbindung (das ist ja hier dann auch kein LAN-LAN) war gar nicht der lokale Router (die 7590) und das Ziel der VPN-Verbindung (die 7390 am anderen Anschluß) kriegt ziemlich sicher weder eine Labor- noch eine Release-Version mit WireGuard (mal abgesehen davon, daß das bei der "single core"-CPU der 7390 wohl ohnehin nur funktionieren würde, wenn man auf "Echtzeit"-Erfordernisse, wie DECT, verzichtet).

Genauso gut hättest Du also auch vorschlagen können, sich gleich an beiden Enden der VPN-Verbindung einen speziellen "VPN-Router" hinzustellen - es gibt das Geräte, die können sogar sehr viele VPN-Verbindungen gleichzeitig bedienen. Nur hat auch das eben nichts mehr mit der Ausgangslage zu tun.

Hier: https://www.ip-phone-forum.de/threads/vpn-zum-fritzbox-server.312761/post-2471368 wird das wenigstens noch etwas näher erklärt - wobei sich daran, daß das mit der ursprünglichen Fragestellung nur noch wenig zu tun hat und mit der nach der Beschreibung vorhandenen Technik so auch nicht zu realisieren ist, dennoch nichts ändert.

---

@Networker_23:
Ich hatte auch meine Gründe, warum ich auf Deine "Nachfragen" (u.a. hier: https://www.ip-phone-forum.de/threads/vpn-zum-fritzbox-server.312761/post-2471085 und auch danach noch in weiteren Beiträgen) nicht mehr geantwortet habe. Ich stehe nämlich auf dem Standpunkt, daß Hilfestellungen immer nur als "Anstoß" dienen sollten, damit man auf dem richtigen Weg landet. Danach halte ich die Benutzung einer Suchmaschine VOR dem Stellen von "Anschlußfragen" für absolut zumutbar ... und auch für die VPN-Protokolle der FRITZ!Box hatte ich bereits geschrieben, daß diese in den Support-Daten zu finden sind.

Eine kurze (eigene) Google-Suche sollte auch sofort eine AVM-Quelle finden, wo beschrieben ist, wie man an die Support-Daten kommt:

Warum sollte das - irgendjemand - jetzt noch einmal gesondert beschreiben, solange die AVM-Beschreibung inhaltlich korrekt ist? Jede "Nacherzählung" kann das eigentlich nur schlechter machen.

Und auch die Online-Hilfe für den Shrewsoft-Client hatte ich bereits verlinkt - da geht man einfach links oben auf "Search" und tippt "debug" ein und schon kriegt man den Link zur Seite mit der Beschreibung des Programms "VPN Trace" präsentiert.

Bei allem Verständnis meinerseits ... aber ich bin gerne zur Hilfe bei einer "Fehlersuche" bereit, jedoch (für meine Person kann ich das absolut sicher behaupten) kein Ersatz für eine Suchmaschine. Wenn sich jemand anderes findet, der Deine (Nach-)Fragen beantworten möchte - schön. Wenn das dann inhaltlich auch noch korrekt ist ... noch besser. Ob Du Dich dann von "anderen Optionen" wieder in eine neue Richtung schieben lassen willst, entscheidest Du auch alleine.

Ich kann Dir nur noch versichern, daß auch mit der vorhandenen Technik eine stabile IPSec-VPN-Verbindung MÖGLICH ist - man MUSS also auch nicht unbedingt WireGuard verwenden, was - ohne Neuanschaffung(en) oder größere Umkonfigurationen, bei denen sich auch die Art der Einwahl bzw. die jeweils "erreichbaren" Geräte im entfernten LAN ändern - hier ohnehin kaum möglich sein dürfte.

Entweder Du willst mit den vorhandenen Möglichkeiten eine funktionierende Verbindung bauen ODER Du willst das "alles ganz anders" machen ... beides gleichzeitig wird nicht funktionieren (sagt mir zumindest meine persönliche Erfahrung) und wir werden ja irgendwann mitbekommen, wie Du Dich nun entschieden hast.

 

[Networker_23]

Also mein Weg ist, die VPN-Verbindung mit Shrewsoft / IPSec zum Laufen zu bekommen. Hab jetzt einen VPN-Trace vom Aufbau der VPN-Verbindung und ein AVM Support Log erstelle (Trace siehe Anhang)

Hier versuche ich den Verbindungsaufbau von meinem Client zum entfernten Ziel:

22/03/29 13:23:47 -> : resend 1 phase2 packet(s) [1/2] 192.168.178.20:4500 -> 212.53.230.149:4500

Laut VPN Trace haben einzelne Pakete ein MTU von 1500 bytes und mehr

22/03/29 13:23:54 -> : send NAT-T:IKE packet 192.168.178.20:4500 -> 212.53.230.149:4500 ( 1548 bytes )
22/03/29 13:23:59 ii : fragmented packet to 82 bytes ( MTU 1500 bytes )


Ein Windows 10 Tablet aus einem anderen IP V4 Netz kann erfolgreich eine VPN-Verbindung aufbauen (AVM Log):

29.03.22 10:43:03 VPN-Verbindung zu xy-tablet [80.187.110.195] IKE SA: DH2/AES-256/SHA1 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.

Im AVM Log findet sich ich keinen Eintrag für meinen Windows Client (192.168.178.20)

Die grüne LED Fernzugang in der FritzBox Oberfläche ist nach Aufbau meiner VPN-Verbindung nicht aktiv.

 

[frank_m24]

VPN Verbindungen aus dem privaten Netz heraus? Geht das überhaupt bei AVM? Die meisten VPNs unterstützen das nicht. Teste es besser von außerhalb.

 

[Networker_23]

Das Windows Tablet ist ein mobiles Endgerät, welches System mal im gleichen Netz wie der VPN Server befindet und mal außerhalb (per LTE) - daher die VPN-Verbindung.

Ich versuche mit Shresoft die VPN-Verbindung zum VPN Server immer von außerhalb über meinen DS Light Anschluss.

 

[frank_m24]

Ok, jetzt hab ich das Problem verstanden.

Im AVM Log findet sich ich keinen Eintrag für meinen Windows Client (192.168.178.20)

DS-Light macht ja auch NAT. Da werden sich Anfragen von der öffentlichen IP finden, die bei dir am AFTR verfügbar ist.

Die Frage ist u.a., wie gut NAT-T an einem DS-Light Anschluss funktioniert. Da hab ich keine Erfahrung.

 

[PeterPawn]

Ob NAT-T innerhalb einer Verbindung verwendet wird, sieht man (a) am verwendeten Port (UDP/4500 anstelle von UDP/500 - auch schon beim IKE, nach den ersten Paketen, wo die Hash-Werte über die Adresse des Peers nicht mit den im Paket zu sehenden Adressen (bzw. den selbst ermittelten Hash-Werten über diese Adressen) übereinstimmen ... daran "erkennt" das Protokoll ja dann ein NAT-Gateway im Pfad) und (b) wird eine Umschaltung auch explizit(!) in der ike.log in den Support-Daten protokolliert.

Eine "Empfehlung", die ich bei der Verwendung des SC auch immer gebe, habe ich bisher noch nicht (in diesem Thread zumindest, in anderen zu ähnlichen Problemen aber schon) erwähnt ... die AVM-IPSec-Implementierung signalisiert eigentlich NICHT in den IKE-Extensions, daß sie auch in dieser Phase fragmentierte Pakete akzeptieren würde - der SC macht das hingegen schon "ausdrücklich" (entsprechende Threads und Protokolle von anderen sollten sich auch leicht finden lassen in diesem Board).

Um zu verhindern, daß die Pakete für P1 und/oder P2 zu groß werden, empfiehlt es sich auch, einfach EINEN passenden Algorithmus im SC einzustellen und die FRITZ!Box nicht mit einer langen Liste von Vorschlägen zu langweilen.

Das letzte Mal, an das ich mich hinsichtlich SC und DS-Lite erinnern kann, wäre das hier: https://www.ip-phone-forum.de/threa...t-mehr-nach-routerwechsel.312516/post-2467030 - beim dortigen "Fragesteller" haben diese Empfehlungen dann jedenfalls geholfen und bis heute (das ist jetzt knapp 5 Wochen her) hat er sich nicht mit "neuen Problemen" gemeldet.

EDIT: Eins noch ... die ältere FRITZ!OS-Version in der 7390 hat auch eine ältere Implementierung des IKE-Daemons - da sieht auch das Protokoll in den Support-Daten noch deutlich anders aus, als das in aktuellen Versionen der Fall ist (wie im oben verlinkten Thread). Aber auch da kann man "erkennen", ob/wann P1 und P2 jeweils komplett sind.

 

[Networker_23]

Ich habe mir gestern Abend die IPV4 Unterstützung für 1 EUR Aufpreis netto monatlich von meinem Provider gebucht. Mittlerweile ist sie umgesetzt. Die VPN-Verbindung funktioniert auf Anhieb mit Shrewsoft tadellos, die Verbindung ist gefühlt deutlicher performanter als sie am DS Lite Anschluss je gewesen ist.

DynDNS kann ich wieder problemlos nutzen - aus meiner Sicht die richtige Entscheidung.

 

[Peter_Lehmann]

Nun, ob das Beharren auf ein totes Pferd (IPv4 und das kastrierte AVM-IPsec) eine gute Entscheidung war, wage ich zu bezweifeln.
Aber du schreibst ja selbst "aus meiner Sicht".

Ich schaue lieber nach vorn - auch wenn das ein klein wenig Umlernen und Umdenken erfordert. Letztendlich werden die Vorteile von IPv6 überwiegen …

 

[Networker_23]

Wenn AVM irgendwann Wireguard bei der 7590 bzw. 7390 unterstützt, bin ich gerne bereit, umzusteigen. Derzeit geht allerdings nur IPsec..

Was bleibt mir also anderes übrig, um vernünftig arbeiten zu können? Es weiteren benötige ich einen Zugriff auf meine 7590 von extern per DynDns..wie sieht es da mit der IPV6 Unterstützung aus?

 

[HabNeFritzbox]

v6 ist kein Problem bei DDNS Diensten, besonders dann nicht wenn FB die Updates selbst anstößt.

Die 7390 könnte man gegen 7530 tauschen sofern es noch weitere Beweggründe gibt, dann wäre auch Wireguard kein Problem, egal ob von FB zu FB oder vom Endgerät direkt zur FB.

 

[PeterPawn]

auf ein totes Pferd (IPv4 und das kastrierte AVM-IPsec)

Sind das dann nicht schon zwei Pferde? Gar eine Chimäre? Oder ist nur eines tot und das andere zieht das Fuhrwerk (oder doch eine prächtige Kutsche namens "VPN"?) alleine weiter? Ist IPv4 dann noch ein Hengst oder - wie das AVM-IPSec offenbar - auch nur noch ein Wallach? Vielleicht aber auch eine Stute?

Auch Du wirst ja zugeben müssen, daß mit der bisher hier verwendeten Kombination aus Anschlüssen und Technik mit WireGuard kein Blumentopf zu gewinnen ist - das erfordert dann "Investitionen" (ggf. auch nur in Arbeitszeit bei einer Umstellung, wobei die 7390 ja auch ein "Fixpunkt" ist, der mit WireGuard nur schlecht zu nutzen ist), die deutlich über den einen Euro pro Monat hinausgehen.

---

Wobei das mit der Umstellung auf IPv4 auch nicht automatisch für jeden anderen Fall eine "Lösung" sein kann (abgesehen davon, daß ja jetzt sicherlich ein DualStack-Anschluß vorliegt und kein "IPv4 only", was das "Schimpfen" auf IPv4 eigentlich ebenso deutlich reduzieren sollte) - es gibt auch genug Provider und Verträge, wo eine öffentlich erreichbare IPv4-Adresse nicht einmal als Zusatzoption nachträglich zu buchen ist.

Ich hatte da mal mit einem Anschluß von M-net im Raum Hanau zu kämpfen und heftige Probleme - die dann auch nur dadurch zu lösen waren, daß ich einen zweiten Router als Tunnel-Gateway hinter den Router vom Provider gesetzt habe und einen eigenen IPv4-in-IPv6-Tunnel dann auf einer eigens dafür auf einem Server bereitgestellten IPv4-Adresse enden ließ. Hätte mir damals jemand die Option von 1 EUR/Monat für eine öffentliche IPv4-Adresse offeriert, hätte ich sofort zugeschlagen.

Denn IPv4-/IPv6-Interkonnektivität ist per se noch immer nicht so einfach ... während z.B. zwei VoIP-Clients, die mit demselben IP-Protokoll arbeiten, auch direkt miteinander kommunizieren können (DMC - Direct Media Connection), muß in dem Falle, daß eine Seite nur IPv6 und die andere nur IPv4 "spricht", immer noch irgendwo ein Gateway vorhanden sein, was die RTP-Daten dann von der einen Adressierung auf die andere umstellt - es gibt also auch gute Gründe, warum ein Client (meint hier einen Edge-Router mit VoIP-Funktionen) weiterhin IPv4 unterstützen sollte. Wild wird es allerdings, wenn sich zwei VoIP-Clients hinter jeweils einem eigenen CGN des Providers miteinander unterhalten wollen.

Gleichzeitig sind aber solche direkten Verbindungen zwischen den Endpunkten einer VoIP-Verbindung die Voraussetzung für "echte" Vertraulichkeit der Daten in einer solchen Übertragung. Wenn eine TLS-gesicherte Telefonverbindung beim Provider wieder "aufgebrochen" wird und die Daten nicht "end-to-end" verschlüsselt sind, ist das ganze TLS nur Theater.