Fritzbox IPSec VPN mit Wireguard ablösen, Anleitungen funktionieren nicht

conf_t

Admiral
Registriert
Juni 2008
Beiträge
8.851
Moinsen.

Ich will eigentlich meine VPNs von FritzVPN auf Wireguard ablösen, da perspektivisch das schlankere WG das baldige Mehr an Bandbreite besser nutzen lässt.

Im aktuellen Setting läuft das FritzVPN, aber Wireguard will nicht abheben, schon der erste Import schlägt fehlt.

Netzwerksituation (ist):
  • 3 Standorte
  • Jeder der 3 Standorte hat eine Public IPv4 und IPv6
  • Jeder Standort hat einen Split-Tunnel mit jedem Standort
  • 2 der 3 Standorte haben eine Routerkaskade, bei der der innere Router der jeweils das VPN bereitstellt.
  • jeder Standort hat seine eigene Sub-Domain (dieses MyFritz-Zeug benutze ich nicht), alles Läuft unter der gleichen TLD (also vpna.meine.tld, vpnb.meine.tld, vpnc.meine.tld)
  • Aus allen Standorten kann ich die IP-Netze zwischen den Routern erreichen.
  • Jeder Standort hat eine eigene LAN-IP:
    • A 192.168.0.0/24
    • B 192.168.2.0/24, mit 192.168.178.16/28 als Transportnetz zwischen den Routern
    • C 192.168.3.0/24 mit 192.168.178.0/28 als Transportnetz zwischen den Routern
  • Funktioniert so seit 2014.
  • Zur Zeit laufen als Router überall FB 7590 mit FritzOS 5.57
  • Dort wo Router kaskadiert sind, stellen jeweils FB 7530 die DSL Verbindung her, die haben die benötigten Portweiterleitungen zu den 7590ern.

Also als Beispiel Standort C:
Code:
Internet  ---| FB7530 | ---- (Subnetz 192.168.178.0/28) ----- | FB7590 |----- Subnetz (192.168.3.0/24)
          PubIP -  192.168.178.1  Portfwd >   zu 192.168.178.2   VPN-Dienst
C ist analog.
In den 192.168.178.xer Netzen hängen aus dem Internet erreichbare Dienste.

Nun versuche ich meine ersten Gehversuche mit WG und wollte zunächst zwischen A und C eine WG Verbindung herstellen.

Dazu habe ich auf C die Initialconfig zum Import in FB A gemäß der einschlägigen Anleitungen für Router-zu-Router Verbindungen eingerichtet. Im Rahmen des Assistenten wird eine Konfig heruntergeladen, die natürlich die unsinnigen myfirtz Domain hatte, habe diese durch meine aktuell genutzte Domain ersetzt und auch den darin hinterlegten UDP Port an der 7530 zur Weiterleitung an die 7590 eingerichtet.

Das ist die Konfig, die ich laut Assi in der entfernten (A) Fritzbox laden soll.
Code:
[Interface]
PrivateKey = $hidden$
Address = 192.168.0.1/24
DNS = 192.168.3.1
DNS = fritz.box

[Peer]
PublicKey = $hidden$
PresharedKey = $hidden$
AllowedIPs = 192.168.178.0/28, 192.168.3.0/24 #<<--- Subnetz ergänzt um aus dem entfernten Netz auch eine Route ins Transportnetz/DMZ zu haben.
Endpoint = vpnc.meine.tld:54064  # <<-- von xyz.,myfritz.net geändert, UDP 54064 ist am vorgelagerten Router geforwarded, vpnc.meine.tld: ist erreichbar.
PersistentKeepalive = 25
Problem:
Wenn ich diese Konfig einlese, schlägt das fehl, leider ist die Fehlermeldung nicht hilfreich. Daher habe ich mal unter Ereignisse geschaut, aber da gibt es auch nichts aufschlussreiches, außer, dass auffällt, dass jedes Mal, wenn ich das versuche die Konfig einzulesen, beim einlesenden Router die Internetverbindung getrennt wird. Da steht schlicht "Internetverbindung getrennt". Reproduzierbar. Und entsprechend melden die anderen Router, dass natürlich das IPSec VPN zusammengebrochen ist.

Da ich nicht weiß, ob man WG und IP-Sec gleichzeitig betreiben kann, habe ich die IPSec Tunnel mal deaktiviert und dann das ganze noch mal versucht, aber wieder bloß, dass der WG Verbindungsversuch fehlschlug und die Internetverbindung getrennt wurde.

Ich konnte halt bisher mit WG auch 0 Erfahrung sammeln, da es ja nicht läuft....
Interessanterweise lese ich auch immer wieder, man soll die Konfig, die man dann unter Einstellungen findet importieren und nicht die, die man während der Initialerstellung ausgeworfen bekommt, doch die beinhaltet ja nicht mal die URL zur Gegenstelle.

Log der FB A bei der Chose:
1703871285472.png
 
Zuletzt bearbeitet:
Du weißt, dass für den Import einer WG Konfiguration alle (!) IPSec Konfigurationen sauber (!) aus den VPN Routern entfernt werden müssen? Das heißt rein praktisch: Werksreset.

Ich empfehle noch mal die AVM Anleitungen, und beachte auch die Hinweiskästchen immer mal wieder zwischendurch. Beachte vor allem auch die Hinweise für die Angabe der IP-Adressen der jeweiligen Partner (steht ebenfalls in diesen Hinweisfeldern).
Ergänzung ()

conf_t schrieb:
mit 192.168.178.16/28 als Transportnetz zwischen den Routern
Das sind übrigens nicht die Transportnetze. Die wären im Fritzbox VPN. Aber die AVM VPN Implementierung unterstützt keine Transportnetze.
Es sind die LAN Netze der Internet-Router. Man könnte großzügig von DMZ sprechen in deinem Fall.
 
  • Gefällt mir
Reaktionen: conf_t
riversource schrieb:
Du weißt, dass für den Import einer WG Konfiguration alle (!) IPSec Konfigurationen sauber (!) aus den VPN Routern entfernt werden müssen? Das heißt rein praktisch: Werksreset.
Hmm, das wusste ich nicht, macht das alles nicht einfacher. Ich habe es befürchtet.

Für ein Werksreset muss ich über all vor Ort fahren und Stunden damit verbirngen wieder alles so einzurichten, wie es war, absolut meh.
 
Zuletzt bearbeitet:
riversource schrieb:
IPSec Konfigurationen sauber (!) aus den VPN Routern entfernt werden müssen?
Würde es gehen in der export dem Abschnitt
Code:
vpncfg {...
}
bzw.

Code:
vpncfg {
        vpncfg_version = 3;
        global {
                wg_listen_port = 0;
        }
        connections {.....
  -<!--   alles was hier steht löschen -->
}
einfach zu löschen? Dann würde ich mir den Rest an Einrichtungsarbeit pro Box nach einem Werksreset sparen....

Oder wird beim Konfigeinlesen irgendein Hash geprüft`, so das Modifikationen abgelehnt werden?
 
Sauber ist das mit Sicherheit nicht. Da würde ich eher die klassische Löschfunktion bemühen.
 
  • Gefällt mir
Reaktionen: conf_t
Update:
Ich habe jetzt mal zwischen Standort A und C die Fritten per Werksreset zurückgesetzt (reines Löschen in der vpncfg oder auch der Oberfläche reichte in der Tat nicht aus).

Ich kann jetzt zwar die in C erstellte WG Konfig in A einlesen, ohne Fehlermeldung (nach dem man weiß, dass man beim Eintrag von 2 Subnetzen in der CFG die Netze nur mit "," und nicht mit ", " trennen darf, was aus den AVM Doks nicht genau hervor geht und in der Weboberfläche wird es dann auch mit zusätzlichen Leerzeichen dargestellt, aber die Verbindung kommt noch nicht zu stande.
Für den in dem Fall genutzten UDP Port 59505 ist natürlich am Standort C in der ersten FB eine Weiterleitung zur hinteren FB eingerichtet. Und die Dyndns Einträge sind auch korrekt, alles pingbar von außen....


Das ist die an der FB C generiert und in A importierte, Zeile 10 ist um das zweite Netz ergänzt und Zeile 11 mit dem DynDNS FQDN.

Code:
[Interface]
PrivateKey = {PrivateKey}
Address = 192.168.0.1/24
DNS = 192.168.3.1
DNS = fritz.box

[Peer]
PublicKey = {PublicKey}
PresharedKey = {PSK}
AllowedIPs = 192.168.3.0/24,192.168.178.0/28
Endpoint = vpn.meine.domain:59505
PersistentKeepalive = 25

Die Konfig der Fritte A nach import:
Code:
[Interface]
PrivateKey = {PrivateKey}
ListenPort = 59497
Address = 192.168.0.1/24
DNS = 192.168.0.1,192.168.3.1
DNS = fritz.box

[Peer]
PublicKey = {PublicKey}
PresharedKey ={PSK}
AllowedIPs = 192.168.3.0/24,192.168.178.0/28
Endpoint = vpn.meine.domain:59505
PersistentKeepalive = 25

Fritte C
Code:
[Interface]
PrivateKey = {PrivateKey}
ListenPort = 59505
Address = 192.168.3.1/24
DNS = 192.168.3.1,192.168.0.1
DNS = fritz.box

[Peer]
PublicKey = {PublicKey}
PresharedKey ={PSK}
AllowedIPs = 192.168.0.0/24
PersistentKeepalive = 25
 
Zuletzt bearbeitet:
conf_t schrieb:
Das ist die an der FB C generiert und in A importierte, angepasste Konfig die ich am Ende importieren konnte (fett die von mir gemachten Änderungen):
Ich sehe nichts fett markiertes.

conf_t schrieb:
aber die Verbindung kommt noch nicht zu stande.
Was genau heißt das? Wird die Verbindung nicht aufgebaut? Fließen keine Daten?

Grundsätzlich ist es gefährlich, in AVM VPNs mit dem Subnetz 178 zu arbeiten, da das Netz für interne Zwecke genutzt wird, auch wenn man in der Box ein anderes Heimnetz konfiguriert hat. So wie ich das sehe, ist das das WAN Netz des VPN Servers, damit wird der Zugriff möglicherweise eh nicht vernünftig funktionieren. Testweise würde ich das erst mal rauslassen.
 
  • Gefällt mir
Reaktionen: conf_t
riversource schrieb:
Ich sehe nichts fett markiertes.
joh, da hat die Forumsformatierung wieder was weggehauen, schaue mal, wie ich das sonst hervorheben kann. (Edit, habe es halt beschrieben.)

Habe mich selbst (Standort C) vom Standort A mal mit FQDN genmapt:

Ergebnis:
PORT STATE SERVICE
59505/udp open|filtered unknown

Also der Port scheint offen zu sein.
Ergänzung ()

riversource schrieb:
Was genau heißt das? Wird die Verbindung nicht aufgebaut? Fließen keine Daten?
Fernzugriff ist in der Oberfläche mit einem grauen Kreis und keinem grünen Kreis markiert. Gescheites Logging ist ja für den normalen Nutzer nicht verfügbar....
1704046340481.png




Gott: Wie unnötig umständlich soll VPN-Konfig sein?
AVM: Jaaaaa.
 
Zuletzt bearbeitet:
conf_t schrieb:
59505/udp open|filtered unknown
Der Port ist nicht unbedingt offen. Anfragen laufen komplett ins Leere, kein Reject, nichts. Deshalb die Aussage "open|filtered unknown". Es kann offen oder gefiltert sein, man weiß es nicht.

conf_t schrieb:
Fernzugriff ist in der Oberfläche mit einem grauen Kreis und keinem grünen Kreis markiert.
Hast du denn mal aufs entfernte Netz zugegriffen, um einen Verbindungstrigger zu setzen?

conf_t schrieb:
Gott: Wie unnötig umständlich soll VPN-Konfig sein?
AVM: Jaaaaa.
Das AVM VPN ist denkbar einfach. Kompliziert macht es dein Setup mit Router-Kaskaden und dem Wunsch, aus dem LAN VPN auf das WAN Netz des Routers zuzugreifen. Der Anwendungsfall ist nur für die Default-Route vorgesehen, aber nicht für ein dediziertes Subnetz. Deshalb der Vorschlag: Nimm es raus.
 
  • Gefällt mir
Reaktionen: Bob.Dig
riversource schrieb:
Deshalb der Vorschlag: Nimm es raus.
Bin gerade beim Subnetz ändern…..
Die 192.168.178.xxx erhalten die gleiche IP wie das lokale Haupt-LAN, aber im dritten Oktet +100

Also 192.168.103.0/24 am Standort C statt 192.168.178.0/28
und 192.168.102.0/24 am Standort B statt 192.168.178.16/28

Dann wäre diese Klippe schon mal umschifft.
Ergänzung ()

Ok.... jetzt verhält sich die Firtte A wieder wie Eingangs beschrieben.... frisst keine Konfig mehr...
Dabei ist sie einfach generiert, ",192.168.103.0/24" in Zeile 11 hinzugefügt (ohne "") und den FQDN in Zeil 11 samt Port eingetragen..... und verliert nach dem Scheitern kurz die Internetverbindung....

riversource schrieb:
Das AVM VPN ist denkbar einfach.
Nicht wenn Usecase 1 mm neben dem Üblichen ist: "Seht her, Ich bin eine Fritzbox, bloß kein IPsec VPN parallel nutzen" Oder "Seht her, Ich bin eine Fritzbox, bloß kein IPsec VPN voher genutzt" Oder "Seht her, Ich bin eine Fritzbox, bloß nicht irgendwo den Falschen-IP Bereich nutzen." RLY? Das ist BS seitens AVM. Werde wenn das so weiter geht, werde ich auf dem Mikrotik WG einrichten..... dazu keine Transparenz bei FMs und Logs und Interfaces...
 
Zuletzt bearbeitet:
Eine Anmerkung von mir, ohne das ich mich mit den Details zur Konfig beschäftigt habe.

"Jeder der 3 Standorte hat eine Public IPv4 und IPv6
Funktioniert so seit 2014."
Das ist auffällig und kann so nicht stimmen.

Beim alten FritzOS bis 7.13, wo bei ipsec ipv6 nicht implementiert war, muste für ipsec doch der Haken raus bei ipv6, sonst lief das nicht. Heist man nutzte dann nicht Dual Stack sonder ipv4 only.
Deine Info wäre dann falsch. Kann so nicht funktioniert haben in 2014.
War bei mir so mit Telekom und später 1&1 als Provider für xdsl.
Jetzt für WG muss der Haken bei ipv6 rein.
AVM WG konfig ist in der Tat einfach, aber nicht bei side to side, wie in Deinem Fall. Router-Kaskaden sind dann noch eine weitere Herausforderung. Unterschiedliche Netze vor Ort verschlimmbessern das ganze.
 
Zuletzt bearbeitet:
hildefeuer schrieb:
"Jeder der 3 Standorte hat eine Public IPv4 und IPv6
Funktioniert so seit 2014."
Da handelt es sich um eine schlichte Auflistung. Ja, anfangs naütrlich nur Ipv4. Kannst dir den Wert dieses Abschnitts deine Beitrags zur konkreten Problemlösung überlegen. Man könnte dir den Versuch eines indirekten Adhominem-Arguments unterstellen. Leider passiert das zu oft in dem Forum. Schön in den (unwichtigen) Krümmeln suchen um andere zu diskreditieren. Wozu? Trägt ja nichts zur Lösung bei. Ja war etwas ungenau von mir,.... aber nicht Kern der Sache...

hildefeuer schrieb:
Unterschiedliche Netze vor Ort verschlimmbessern das ganze.
Ich hoffe doch. Wenn an allen Orten gleichen Netze wären, dann viel Spaß beim Routing. Überall 192.168.0.0 wäre für für die Füße.


hildefeuer schrieb:
AVM WG konfig ist in der Tat einfach, aber nicht bei side to side, wie in Deinem Fall.
Einfach ist, wenn man die Konfig per CLI einfach (auch nachträglich) editieren kann. Dann Dienst neustartet und Fertig ist die Laube. Hier leider alles umständlich per WebGUI.


Ich schaue mir gerade den Traffic per Wireshark an

Grundsätzlich reden tun beide Seiten mit einander.....

1704114316865.png


Dabei bin ich dort im Paket das gestolpert, soll das heißen, dass entgegen des Konfigfiles ein Der Privatekey nicht passt?
1704114485662.png


Edit:
Lösung dafür, dass das Konfigfile an sich seit gestern plötzlich nicht mehr akzeptiert wurde (Post11):

So bin jetzt wieder auf Stand von Post 9.
Habe mal die PubK PSK und PrivK geprüft. Die generierte Konfig (seit gestern Mehrfach komplett von vorne neu versucht WG aufzusetzen) war bei allem zu den Keys im Webinterface abweichend, außer beim PSK. Und warum unterscheiden sich bei der gleichen Fritzbox der "öffentliche Schlüssel" vom "Public Key"? Ist doch ein Synonym für einander.

Der Beweis, dass nicht ich mit den Konfigfiles durcheinander gekommen bin ist der, dass der Port in dem generierten File korrekt war, nur die Keys nicht. Da hat AVM wohl echt noch Baustellen.

Habe jetzt die Keys aus der Weboberfläche in die Konfig kopiert, und schon klappt das importieren der Konfig bei A. Da ist der "einfache" Assisstent selbst mit den Keys durcheinander gekommen?

1704115589779.png



Ping get natürlich nicht von 192.168.0.0/24 nach 192.168.3.0/24 oder umgekehrt.... mal schauen woran das liegt.


So, noch mal die Konfig in die Tonne gekloppt und von vorne. Sieht schon mal besser aus.

Jetzt komme ich immer hin von 192.168.3.20 nach 192.168.0.1...
 
Zuletzt bearbeitet:
conf_t schrieb:
Grundsätzlich reden tun beide Seiten mit einander.....
Da redet gar nichts miteinander. Die Antworten auf die Keep Alives bleiben aus. Sind die denn jetzt da, nach dem Key Wechsel?

conf_t schrieb:
Da ist der "einfache" Assisstent selbst mit den Keys durcheinander gekommen?
Waren die Voraussetzungen denn jedes Mal wirklich sauber? Für wilde Experimente eignet sich das VPN tatsächlich nicht.

conf_t schrieb:
Ping get natürlich nicht von 192.168.0.0/24 nach 192.168.3.0/24 oder umgekehrt.... mal schauen woran das liegt.
Ich würde das WAN Netz aus der Konfig rauslassen.
 
riversource schrieb:
Da redet gar nichts miteinander.
Schau bitte auf Zeile 1 und 2, sowohl die IPv6 als auch die Info-Box sagen was anders. Da ist genau 1 Response Paket (#6243)

#6231 und #6248 sind vom Source Standort A
Und alle anderen sind von Source Standort C.

Mitschnitt war in dem Fall Standort C.
riversource schrieb:
Waren die Voraussetzungen denn jedes Mal wirklich sauber? Für wilde Experimente eignet sich das VPN tatsächlich nicht.
Ausgangspunkt waren zurückgesetzte Boxen..... und dann kam ein Problem nach dem anderen, natürlich setzte man die WG Konfig zwischen durch mal von vorne auf..... wie sauber die FB ihre Konfig-bereinigen kann, kann ich nicht sagen, sieht aber so aus, als könnte sie das nicht. Und jedes Mal einen Werksreset zu machen, ist weit weit weit weit weg von benutzer freundlich.

Aber ich danke dir nochmal für die Hinweise, die zwar erst etwas abwegig klangen, es wohl aber nicht sind in der Welt von AVM....
Ergänzung ()

riversource schrieb:
Ich würde das WAN Netz aus der Konfig rauslassen.
DAs ist richtig, das geht hier um einen Test, dass das klappt, weil ich später von C auf das WAN Netz von Standort B kommen muss.

Nach dem jetzt Standort A mit C reden kann, habe ich den Spaß noch mal mit Standort A mit B und B mit C.
 
Zuletzt bearbeitet:
conf_t schrieb:
Schau bitte auf Zeile 1 und 2, sowohl die IPv6 als auch die Info-Box sagen was anders. Da ist genau 1 Response Paket (#6243)
Mit einem NACK. Kein einziges Keep Alive wird beantwortet. Wie gesagt, da redete gar nichts miteinander.

conf_t schrieb:
DAs ist richtig, das geht hier um einen Test, dass das klappt
Ok, also nach Rauslassen der WAN Verbindung klappt das VPN? Das hab ich mir gedacht, dass der Anwendungsfall nicht vorgesehen ist bei AVM, auf ein Privates Subnetz am WAN zuzugreifen. Entweder Default-Route oder gar nichts.

conf_t schrieb:
weil ich später von C auf das WAN Netz von Standort B kommen muss.
Dann mach einen VPN Server in den WAN Router von Standort B.
 
  • Gefällt mir
Reaktionen: Bob.Dig
riversource schrieb:
Ok, also nach Rauslassen der WAN Verbindung klappt das VPN? Das hab ich mir gedacht, dass der Anwendungsfall nicht vorgesehen ist bei AVM, auf ein Privates Subnetz am WAN zuzugreifen. Entweder Default-Route oder gar nichts.
Nein. Es klappt mit. Habe auch nicht geschrieben, dass ich es weggelassen hätte.
Ergänzung ()

riversource schrieb:
Dann mach einen VPN Server in den WAN Router von Standort B.
Kategorisch ausgeschlossen
Ergänzung ()

riversource schrieb:
Mit einem NACK. Kein einziges Keep Alive wird beantwortet. Wie gesagt, da redete gar nichts miteinander.
Da ging es doch nur darum, dass sicher gestellt ist, dass die Pakete ihre Ziele erreichen. Als ein Verbindung auf IP Ebene geht, nicht zwingend um Layer 5 und höher.

Man Troubleshootet sich die Layer von unten nach oben.


Was du das siehst in dem Screenshot ist eine UDP-Conversation, auch wenn sie Inhaltlich (auf Applikationsebene (WG) nicht funktioniert). Die UDP Sockets werden in beide Richtungen korrespondieren adressiert und erreicht.
 
Zuletzt bearbeitet:
conf_t schrieb:
Da ging es doch nur darum, dass sicher gestellt ist, dass die Pakete ihre Ziele erreichen.
Ok, ich hatte gedacht, dass wir über den Schritt schon hinaus sind.

Aber jetzt hast du mich verwirrt. Was ist der genaue Status? Funktioniert das VPN nun? Auch mit Zugriff auf das WAN Netz?
 
Ja, alles funktioniert in der ersten Iteration (A<-> C) wie ich es wollte.

192.168.0.0 -> 192.168.3.0
192.168.0.0 -> 192.168.103.0
192.168.3.0 -> 192.168.0.0
 
riversource schrieb:
Du weißt, dass für den Import einer WG Konfiguration alle (!) IPSec Konfigurationen sauber (!) aus den VPN Routern entfernt werden müssen? Das heißt rein praktisch: Werksreset.
Tach, wo ist das bei AVM so dokumentiert? Schließen sich IPSec und WG gegenseitig aus? Ich unterhalte momentan ein WG-VPN und drei IPSec-VPNs zu jeweils unterschiedlichen Standorten von meiner Fritzbox 5590 und das funktioniert soweit reibungslos. Die WG-Config wurde über den Assistenten, den es von AVM gibt, importiert. Ich bin kein VPN-Profi, habe aber bis heute noch keine Einschränkungen feststellen können.

Sollte ich lieber komplett auf WG umsteigen? Das hätte zumindest einen Hardwareaustausch zur Folge...

Gruß
 
Zurück
Oben