Mikrotik zu Mikrotik hinter Fritz, IPSEC Übertragung nur 1,5 MBs
Guten Tag,
ich hatte bisher bei einer FB zu FB IPSec Tunnelverbindung ca. 4 MB/s Übertragungsgeschwindigkeit.
Getestet, Kopiervorgang einer grossen Datei über den Tunnel.
Nun habe ich eine Hex und eine RB2011 zur Verstärkung geholt (hinter den Fritzboxen) und mir eine
schnellere Übertragung gewünscht.
Leider bekomme ich mit den FB + MT zu FR + MT nur ca. 1,5 MB/s übertragen.
Die CPU langweilt sich aber bei 10 - 12 %.
Ich komme ich nicht auf die Lösung wo mein Fehler liegen könnte. Hat jemand einen Tipp?
SHA256 + AES 256 ist eingestellt. Habe ich den Tunnel evtl. schlecht eingerichtet?
Upload hätte ich auf beiden Seiten 50 mbit zur Verfügung.
ich hatte bisher bei einer FB zu FB IPSec Tunnelverbindung ca. 4 MB/s Übertragungsgeschwindigkeit.
Getestet, Kopiervorgang einer grossen Datei über den Tunnel.
Nun habe ich eine Hex und eine RB2011 zur Verstärkung geholt (hinter den Fritzboxen) und mir eine
schnellere Übertragung gewünscht.
Leider bekomme ich mit den FB + MT zu FR + MT nur ca. 1,5 MB/s übertragen.
Die CPU langweilt sich aber bei 10 - 12 %.
Ich komme ich nicht auf die Lösung wo mein Fehler liegen könnte. Hat jemand einen Tipp?
SHA256 + AES 256 ist eingestellt. Habe ich den Tunnel evtl. schlecht eingerichtet?
Upload hätte ich auf beiden Seiten 50 mbit zur Verfügung.
Please also mark the comments that contributed to the solution of the article
Content-ID: 5920507976
Url: https://administrator.de/contentid/5920507976
Printed on: November 11, 2024 at 11:11 o'clock
110 Comments
Latest comment
4 Megabyte die Sekunde?
Also SMB und wie groß ist die Datei?
100MBit ungefähr 12 Megabyte Sekunde
100MBit ungefähr 12 Megabyte Sekunde
SMB ist nicht so toll im WAN. Wie sind die Pings?
Mach Mal nen Ping mit größeren Rahmen.
2048, 4096... Wie sehr geht das auf die Laufzeit?
2048, 4096... Wie sehr geht das auf die Laufzeit?
1500 auch nicht?
Servus,
ich hatte früher auch einige Probleme mit zwei Mikrotiks und IPSEC, die üblichen Anleitungen hatten zwar funktioniert, die Geschwindigkeit war erst nach vielen Optimierungsmöglichkeiten brauchbar (ein Endpunkt ist LTE).
Bei einem Umbau habe ich die Strecke auf Wireguard umgestellt und die Verbindung war sofort top.
Vielleicht ist das einen Versuch wert.
Grüße, Stefan
ich hatte früher auch einige Probleme mit zwei Mikrotiks und IPSEC, die üblichen Anleitungen hatten zwar funktioniert, die Geschwindigkeit war erst nach vielen Optimierungsmöglichkeiten brauchbar (ein Endpunkt ist LTE).
Bei einem Umbau habe ich die Strecke auf Wireguard umgestellt und die Verbindung war sofort top.
Vielleicht ist das einen Versuch wert.
Grüße, Stefan
Auch das wird dem TO wenig nützen, denn der Knackpunkt ist seine falsche Hardware Wahl mit dem RB2011 der keine Hardware Encryption supportet!! (Siehe u.a. auch hier)
https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Hardware_acceleration
Der RB2011 kommt deshalb kaum über max. 12-15 Mbit VPN Durchsatz hinaus weil er alles in Software machen muss. Das verwendete VPN Protokoll spielt dabei keinerlei Rolle!
Der WG Versuch ist also mehr oder minder sinnfrei.
Nebenbei ist das Testen mit Kopieren von Dateien via SMB/CIFS auch wenig zielführend. Deutlich sinnvoller ist wenn man auf beiden Seiten mit iPerf3 testet.
https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Hardware_acceleration
Der RB2011 kommt deshalb kaum über max. 12-15 Mbit VPN Durchsatz hinaus weil er alles in Software machen muss. Das verwendete VPN Protokoll spielt dabei keinerlei Rolle!
Der WG Versuch ist also mehr oder minder sinnfrei.
Nebenbei ist das Testen mit Kopieren von Dateien via SMB/CIFS auch wenig zielführend. Deutlich sinnvoller ist wenn man auf beiden Seiten mit iPerf3 testet.
Der Hex ist ja wesentlich billiger und quasi besser?
Wieso dich das "schockt" ist jetzt völlig unverständlich. Jeder normale Mensch informiert sich doch vorher bei technischen Anschaffungen über Prospekte oder Datenblätter ob das was er kauft seinen Ansprüchen genügt. Machst du das nicht wenn du dir ein neues Auto, Rasenmäher oder Fernseher kaufst?? Wäre ziemlich blauäugig dann...Was genau also meinst du mit "besser"?? Wenn das rein auf die Hardware Encryption bezogen ist beantwortet dir die o.a. Mikrotik Tabelle ja alle Fragen dazu.
@aqui:
Da tust Du ihm meiner Meinung nach unrecht. Und zwar, weil man als Newbie eher falsch an das Thema rangeht. Man sieht die Funktionen von RouterOS und die Empfehlungen hier im Forum und kann nicht einschätzen was geht und was eher utopisch ist und worauf er Wert legen muss. Und ja, die Dokumentation von MT ist sehr detailliert ... sie erschlägt einen aber auch. Und je nach Funktionalität kann die sich auch mit jedem Mondzyklus, sprich SW-Update beträchtlich ändern. Kurzum, das ist ne ausgesprochen "nerdige" Sache.
@Newbie88:
Es genügt nicht das billigste Gerät mit ausreichend Ports zu kaufen - und dabei vielleicht noch zwischen Switch und Router zu unterscheiden.
Nur mal so als "Hint": Ne poplige Plastik-Fritze kommt mit nem 1 Ghz Dualcore daher – da kannste Dir bestimmt vorstellen, dass MT mit dem mächtigen RouterOS und dessen Funktionen mit 600 Mhz Singlecore nicht das fliegen lernt! Und das ist ja nur eine Komponente. Je nach Funktionen kommen dann hw-offloading, Deine Verschlüsselung, fast forward, und fast dingsbums usw. noch hinzu – die je nach Mondphase, Modell, Version, Zusatzprozessor, usw. mal schnell funktionieren oder evtl. mal eher gemächlich
Da tust Du ihm meiner Meinung nach unrecht. Und zwar, weil man als Newbie eher falsch an das Thema rangeht. Man sieht die Funktionen von RouterOS und die Empfehlungen hier im Forum und kann nicht einschätzen was geht und was eher utopisch ist und worauf er Wert legen muss. Und ja, die Dokumentation von MT ist sehr detailliert ... sie erschlägt einen aber auch. Und je nach Funktionalität kann die sich auch mit jedem Mondzyklus, sprich SW-Update beträchtlich ändern. Kurzum, das ist ne ausgesprochen "nerdige" Sache.
@Newbie88:
Es genügt nicht das billigste Gerät mit ausreichend Ports zu kaufen - und dabei vielleicht noch zwischen Switch und Router zu unterscheiden.
Nur mal so als "Hint": Ne poplige Plastik-Fritze kommt mit nem 1 Ghz Dualcore daher – da kannste Dir bestimmt vorstellen, dass MT mit dem mächtigen RouterOS und dessen Funktionen mit 600 Mhz Singlecore nicht das fliegen lernt! Und das ist ja nur eine Komponente. Je nach Funktionen kommen dann hw-offloading, Deine Verschlüsselung, fast forward, und fast dingsbums usw. noch hinzu – die je nach Mondphase, Modell, Version, Zusatzprozessor, usw. mal schnell funktionieren oder evtl. mal eher gemächlich
Servus,
sorry fürs Überlesen des schwachen RB2011.
Wenn du wirklich nur testen willst, was geht:
Stell auf beiden Seiten einen Laptop hin und installiere dir den CHR (60 Tage Testversion) in Virtualbox.
Alternativen für einen einfachen Speedtest wären auch die Bandbreitenmessung vom RouterOS selber oder mit einem einfachen Protokoll wie z.B. http.
Grüße, Stefan
sorry fürs Überlesen des schwachen RB2011.
Wenn du wirklich nur testen willst, was geht:
Stell auf beiden Seiten einen Laptop hin und installiere dir den CHR (60 Tage Testversion) in Virtualbox.
Alternativen für einen einfachen Speedtest wären auch die Bandbreitenmessung vom RouterOS selber oder mit einem einfachen Protokoll wie z.B. http.
Grüße, Stefan
Hex3 zu Hex3 schneller als Fritz zu Fritz?
Du meinst HEX S? Da steht doch schon in der Beschreibung, dass IPSec bis 470 Mbit/s bzw. knapp 60 MByte/s unterstützt werden?! Ähnlich dem normalen HEX oder dem 3011er. Das steht doch jeweils in den Datensheets? Ohne, dass ich diesbezüglich enorm erfahren wäre. Ich tapps bei MT ja auch immer nur von einem Fettnapf in den nächsten.Oder man spart sich imho den ganze Quatsch und nimmt gleich Wireguard, weil das - so wie ich das verstehe - sehr effizient in SW/CPU verschlüsselt. Nur die CPU vom RB2011 ist ja eben auch eher schwächlich.
Als kleine Ergänzung noch ein hEX-real-life-Szenario:
https://forum.mikrotik.com/viewtopic.php?t=142732
160 Mbit/s (beachte Mbit/s != MB/s) genügen Dir doch, oder? Und wenn es ein stärkeres/größeres Gerät sein soll, dann 4011 oder 5009. Für Deinen Anwendungsfall aber total drüber. Und messen, wie oben vom Kollegen @aqui schon gesagt, mit iperf, für verlässliche Resultate.
Viele Grüße, commodity
https://forum.mikrotik.com/viewtopic.php?t=142732
160 Mbit/s (beachte Mbit/s != MB/s) genügen Dir doch, oder? Und wenn es ein stärkeres/größeres Gerät sein soll, dann 4011 oder 5009. Für Deinen Anwendungsfall aber total drüber. Und messen, wie oben vom Kollegen @aqui schon gesagt, mit iperf, für verlässliche Resultate.
Viele Grüße, commodity
Ja, beim 2. Test scheint sich der Tunnel erst langsam aufzubauen.
Beide Werte sind aber zu schlecht, wenn Du wirklich 50 Mbit/s Upload hast (bitte checken, ob das real so ist). Da stimmt was nicht.
Mach vielleicht auch mal längere Tests -t 20 und/oder mehrere Treads -P 5
Wenn Upload passt und die Werte nicht besser werden, solltest die Konfig nochmal durchgehen und mit dem Tutorial von @aqui abgleichen und auch gucken, was die Fritzboxen so treiben. Sind die exposed host? Hast Du exzessive Firewall-Rules auf den MTs?
Viele Grüße, commodity
Beide Werte sind aber zu schlecht, wenn Du wirklich 50 Mbit/s Upload hast (bitte checken, ob das real so ist). Da stimmt was nicht.
Mach vielleicht auch mal längere Tests -t 20 und/oder mehrere Treads -P 5
Wenn Upload passt und die Werte nicht besser werden, solltest die Konfig nochmal durchgehen und mit dem Tutorial von @aqui abgleichen und auch gucken, was die Fritzboxen so treiben. Sind die exposed host? Hast Du exzessive Firewall-Rules auf den MTs?
Viele Grüße, commodity
Das Allereinfachste ist ja die beiden Router einmal Back to Back über eth1 mit einer Default Konfig zusammen zu stecken und dann einmal einen Site-to-Site Tunnel aufzubauen.
Hier kann man dann ganz in Ruhe auch mit unterschiedlichen Krypto Credentials und iPerf3 einmal testen was die Boxen so schaffen. So hat man Gewissheit und weiss sofort ob's an der HW oder dem Providerlink liegt. Einfache Logik... 😉
Hier kann man dann ganz in Ruhe auch mit unterschiedlichen Krypto Credentials und iPerf3 einmal testen was die Boxen so schaffen. So hat man Gewissheit und weiss sofort ob's an der HW oder dem Providerlink liegt. Einfache Logik... 😉
die default Konfig ist ja komplett ohne Firewall.
Wie kommst du denn auf den Unsinn?Die Default Konfig ist eine NAT Konfig mit dem WAN Port auf eth1 im DHCP Client Mode und die Ports 2-5 als Bridge als LAN Port plus vollständiger Firewall. Wenn du die eth1 direkt verbindest musst du denen natürlich statische IPs vergeben.
Du solltest wohl besser nochmal genau die Mikrotik Doku lesen und vor allem verstehen!
Oder ist "Router" Pflicht?
Ist die Frage wirklich ernst gemeint??
Eine Konfig ohne jeglichen Kommentar??? Was soll uns das sagen?! Kürze das bitte nur auf die VPN Kommandos alles andere ist überflüssig und verwirrt nur unnötig.
dass sich ein Tunnel langsam aufbaut.
Kann eigentlich nicht sein, denn sowie du den Tunnel in den Proposals (WinBox) mal deaktivierst und wieder aktivierst sollte der Tunnelaufbau in unter 1 Sekunde in den "established" Status gehen. Das sollte keinesfalls länger als 1 Sekunde dauern. Von einem "langsamen Tunnelaufbau" kann hier also niemals die Rede sein oder du hast etwas falsch gemacht?!Ich teste nun mal die 128 Variante.
Verwende kein AES-GCM sondern nur die CBC Variante. Variiere auch mal das Hashing SHA1 und SHA2 in beiden Phases.Eine Konfig ohne jeglichen Kommentar???
Der Grundgedanke war eher, dass man die Einstellungen besser abgleichen kann - das ist bei MT ja sonst recht unübersichtlihc.Mir fällt auf, dass beide Geräte unterschiedliche SW-Stände haben. Persönlich habe ich kein Problem mit den Betas bzw. dem RC1. Aber man sollte sehen, dass sich von 7.7 Stable zu 7.8RC1 u.a. folgende Punkte geänder haben:
*) ipsec - added support for "Framed-Route" RADIUS attribute support;
*) ipsec - do not match incoming IKE requests by unresolved DNS name peers;
*) ipsec - fixed peer matcher for incoming connection with unresolved DNS;
https://mikrotik.com/download/changelogs/testing-release-tree
@Newbie88
Kopiere Dir die beiden Ausgaben mal hier rein:
https://prlbr.de/2015/textvergleicher/
Da gibts ein paar komische Unterschiede
Kopiere Dir die beiden Ausgaben mal hier rein:
https://prlbr.de/2015/textvergleicher/
Da gibts ein paar komische Unterschiede
Der TO hat einen lokalen Back-to-Back Test mit den beiden Boxen gemacht ohne FBs! (Sofern er uns hier nicht hinters Licht geführt hat?!).
Verwunderlich wie der Tester im o.a. MT Forumsbeitrag dann auf 160Mbit/s Durchsatz kommt bei gleicher Hardware?! Das Ergebnis wiederspricht dann auch den offizellen Ergebnissen die Mikrotik selber zu der hEX Plattform veröffentlicht: https://mikrotik.com/product/RB750Gr3#fndtn-testresults 🤔
Die o.a. Werte legen den Verdacht nahe das der TO immer rein nur mit 64 Byte Paketgrößen getestet hat?! Dafür sprechen auch die CIFS/SMB Tests weil SMB hier durch die Verwendung sehr kleiner Paketgrößen eines der ineffizientesten File Transfer Protokolle ist.
Verwunderlich wie der Tester im o.a. MT Forumsbeitrag dann auf 160Mbit/s Durchsatz kommt bei gleicher Hardware?! Das Ergebnis wiederspricht dann auch den offizellen Ergebnissen die Mikrotik selber zu der hEX Plattform veröffentlicht: https://mikrotik.com/product/RB750Gr3#fndtn-testresults 🤔
Die o.a. Werte legen den Verdacht nahe das der TO immer rein nur mit 64 Byte Paketgrößen getestet hat?! Dafür sprechen auch die CIFS/SMB Tests weil SMB hier durch die Verwendung sehr kleiner Paketgrößen eines der ineffizientesten File Transfer Protokolle ist.
Auch das machen die Mikrotiks ja mit Links!
https://help.mikrotik.com/docs/display/ROS/WireGuard
https://help.mikrotik.com/docs/display/ROS/WireGuard
Der TO hat einen lokalen Back-to-Back Test mit den beiden Boxen gemacht ohne FBs!
Nö. Das hattest Du zwar empfohlen und wäre hier das richtige Vorgehen. Ich kann aber nicht sehen, dass das gemacht wurde.Die 30-36 Mbit/s, die jeweils max erreicht wurden, riechen für mich nach der Grenze des Uploads, zumal das exakt in dem Bereich ist, was die zwei Fritzboxen zuvor max erreicht haben. Auch wenn der TO meint, 50 Mbit/s gebucht zu haben, muss das ja nicht der real verfügbare Upload sein.
Bleibt das Rätsel der langsameren Verbindung des zweiten Clients, aber auch das kann Leitungs-/Providerspezifisch sein.
Also @Newbie88: Auch ein 160 Mbit/s hEX kann auf einem Upload von 30 Mbit/s eben nur diese durchreichen. Reale Leistungswerte bekommst Du nur mit Direktverbindung beider Geräte, wie Kollege @aqui oben ja empfohlen hatte. Wenn der direkte Test deutlich bessere Werte ergibt, liegt es wohl an Deiner Leitung, wenn nicht, kannst Du in der Konfig weitersuchen oder auf WireGuard umstellen.
Viele Grüße, commodity
Auch wenn der TO meint, 50 Mbit/s gebucht zu haben, muss das ja nicht der real verfügbare Upload sein.
Da hast du zweifelsohne Recht. Ganz besonders wenn eine Seite ein TV-Kabelanschluss ist wo man sich bekanntlich den Upload mit Tausenden von anderen Usern teilen muss.Zudem wäre es schon verwunderlich wenn MT IPsec Durchsatzdaten öffentlich macht die dann in der Realität so abweichen würden. Das wäre wenig glaubhaft.
Es wäre also sehr sinnvoll einen Back-to-Back Durchsatztest zu machen und dabei 2 unterschiedliche Paketgrößen zu verwenden und auch testweise mal IPsec und WG zu verwenden um zu sehen woran man ist.
Und final...nicht immer in unübersichtlichen Einzelthreads im Minutentakt zu antworten sondern diese intelligent in einem zusammenfassen.
WG ist auf MT ja kein Hexenwerk (mehr):
a) Backup machen vom bisherigen Setup: Files > Backup > Namen vergeben > keine Verschlüsselung > anschließend runterladen
b) Wenn keiner eigener DynDNS in der Fritze hinterlegt ist: IP > Cloud "DDNS Enabled" anhakeln und DNS-Namen für später rauskopieren
c) Wireguard aufrufen > Add New > OK drücken. Gleich im Anschluss neu erstellten Host öffnen (wireguard1); hier dann den "listen Port" und den "Public Key" für später rauskopieren
d) Wireguard > TAB Peers > Add New >
Public Key: den jeweiligen "Public key" (siehe Punkt c) der Gegenseite reinkopieren
Endpoint: WAN-IP-Adresse der Gegenstelle eintragen, alternativ DynDNS-Namen. Übers Webinterface geht das glaube ich immer noch nicht (lässt sich nicht speichern). Dann alternativ über Winbox oder die CLI (nicht schwierig!)
Endpoint: der Gegenstelle eintragen (steht dort unter dem WG-Host - muss aber natürlich noch von der Fritze durchgereicht werden!)
Preshared Key: Weglassen, braucht kein Mensch
Persistent Keepalive: 00:00:25
Allowed Address: Hier passieren die meisten Fehler!
a) Hier trägst Du den IP-Bereich der Gegenstelle ein. Wenn Deine Fritze auf der Gegenseite 192.168.178.1 und die Geräte dort folglich Adressen aus dem Bereich 192.168.178.0/24 haben (Standard bei den Fritzen), dann steht da: 192.168.178.0/24
b) Üblicher Weise arbeitet WG innerhalb des Tunnels mit ein eigenen IP-Bereich (kein DHCP, sondern fix), d.h. Dein wg-Interface bekommt unter IP > Add New noch eine IP-zugewiesen und die Gegenstelle eine passende IP aus dem gleichen Bereich (vergl. hier: https://kaspars.net/blog/wireguard-mikrotik-routeros).
Unter allowed IP steht dann: 192.168.178.0/24,dieWGinterne-AdressederGegenseite/32 (weil das ist ja nur eine!)
Dazwischen ein Komma ohne leer.
Anschließend müssen die Ports bei der Fritze noch durchgereicht werden und Du wirst noch irgendwo routen müssen, damit die Fritze weiß, wie sie mit Anfragen im lokalen Netz zum entfernten VPN-Punkt umgehen muss. Dabei berücksichtigen, dass die Fritze nur Routen annimmt, bei denen der Zielhost im eigenen IP-Netz liegt!
Die Kollegen sind aus dem Stehgreif mit Sicherheit fitter, wie man das gestaltet. Ich würde den Hex vermutlich eh nicht als Router hinter einer Fritze konfigurieren (Doppel-NAT und Firewall), das macht nur unnötig Stress. Wenn der im Bridgemode arbeitet, dürfte das flexibler sein.
a) Backup machen vom bisherigen Setup: Files > Backup > Namen vergeben > keine Verschlüsselung > anschließend runterladen
b) Wenn keiner eigener DynDNS in der Fritze hinterlegt ist: IP > Cloud "DDNS Enabled" anhakeln und DNS-Namen für später rauskopieren
c) Wireguard aufrufen > Add New > OK drücken. Gleich im Anschluss neu erstellten Host öffnen (wireguard1); hier dann den "listen Port" und den "Public Key" für später rauskopieren
d) Wireguard > TAB Peers > Add New >
Public Key: den jeweiligen "Public key" (siehe Punkt c) der Gegenseite reinkopieren
Endpoint: WAN-IP-Adresse der Gegenstelle eintragen, alternativ DynDNS-Namen. Übers Webinterface geht das glaube ich immer noch nicht (lässt sich nicht speichern). Dann alternativ über Winbox oder die CLI (nicht schwierig!)
Endpoint: der Gegenstelle eintragen (steht dort unter dem WG-Host - muss aber natürlich noch von der Fritze durchgereicht werden!)
Preshared Key: Weglassen, braucht kein Mensch
Persistent Keepalive: 00:00:25
Allowed Address: Hier passieren die meisten Fehler!
a) Hier trägst Du den IP-Bereich der Gegenstelle ein. Wenn Deine Fritze auf der Gegenseite 192.168.178.1 und die Geräte dort folglich Adressen aus dem Bereich 192.168.178.0/24 haben (Standard bei den Fritzen), dann steht da: 192.168.178.0/24
b) Üblicher Weise arbeitet WG innerhalb des Tunnels mit ein eigenen IP-Bereich (kein DHCP, sondern fix), d.h. Dein wg-Interface bekommt unter IP > Add New noch eine IP-zugewiesen und die Gegenstelle eine passende IP aus dem gleichen Bereich (vergl. hier: https://kaspars.net/blog/wireguard-mikrotik-routeros).
Unter allowed IP steht dann: 192.168.178.0/24,dieWGinterne-AdressederGegenseite/32 (weil das ist ja nur eine!)
Dazwischen ein Komma ohne leer.
Anschließend müssen die Ports bei der Fritze noch durchgereicht werden und Du wirst noch irgendwo routen müssen, damit die Fritze weiß, wie sie mit Anfragen im lokalen Netz zum entfernten VPN-Punkt umgehen muss. Dabei berücksichtigen, dass die Fritze nur Routen annimmt, bei denen der Zielhost im eigenen IP-Netz liegt!
Die Kollegen sind aus dem Stehgreif mit Sicherheit fitter, wie man das gestaltet. Ich würde den Hex vermutlich eh nicht als Router hinter einer Fritze konfigurieren (Doppel-NAT und Firewall), das macht nur unnötig Stress. Wenn der im Bridgemode arbeitet, dürfte das flexibler sein.
a) lernt niemand was, wenn er ein Problem hat und ihm bloß ausweicht und
Das mag sein. Nur wird an dem Thema jetzt ja schon einige Zeit rumgedoktort und Lebenszeit ist grundsätzlich begrenzt. Für Erfolg an der Börse hieß es früher mal:a) Du musst stur an Deiner Strategie festhalten
b) Du musst wissen wann es sinnvoll ist, von ihr abzuweichen
b) wird die Leitung davon auch nicht schneller face-wink
Was mit WG dann ja ebenso bewiesen wäre Das mit dem Bridge Modus... Ich habe beide MT ohne Default am laufen.
Jo, ich glaube, das meinte ich Aber @aqui hatte das eh schon entschärft, in dem er empfahl die Firewall/NAT ggfs. einfach zu deaktivieren. Bei Dir sollten die dann ja nicht aktiv sein.mich ans WG wagen
Du musst wissen wann es sinnvoll ist, von ihr abzuweichen
Ihr habt beide Recht. WG ist ja auch super. Ich setze (übergangsweise) beides (auch parallel) ein und bin schon angezählt worden, wegen meines "VPN-Zoos" . Ich dachte bloß an die Nachwelt: Wenn ich völlig ahnungslos hier nach einer konkreten Problemlösung suche und die lautet dann, "nimm halt was anderes", ist das als Rat von Fachleuten immer grenzwertig. IPSec ist immer noch ein wertvolles und sehr häufig anzutreffendes Protokoll. Da schaden grundlegende Kenntnisse nicht.
Hier aber ist ein Status erreicht und ich denke, wir haben die Ursache bereits in der Leitung gefunden. Mit WG sind ja vielleicht noch 2Mbit/s mehr Durchsatz drin, weil der Overhead kleiner ist (nie getestet), aber wirklich spürbar wird das wahrscheinlich nicht.
Auf jeden fall viel Spaß beim Experimentieren. Ich freue mich über ein gepostetes Ergebnis der Geschwindigkeitsmessung unter WG.
Viele Grüße, commodity
und 100.64.64.0/24 entschieden, ob das passt?
Nein das passt nicht! Die Null bezeichnet immer das Netzwerk (alle Hostbits auf 0) und ist keine gültige Hostadresse. Deshalb scheitert dein Tunnel.Solche simplen IP Adressierungsbasics solltest du aber kennen?! 🧐
Was auch komisch ist sind die leeren Felder bei den Keys. Hast du das anonymisiert?? Dann wäre das OK. Ansonsten ist natürlich klar das Wireguard ohne Keys generell scheitert. Guckst du auch hier
Das WG Logging kannst du aktivieren wenn du das Wireguard Logging in den Log Einstellungen zusätzlich aktivierst.
Die Route setzt der MT bei Einrichtung von WG selbst.
Wenn Du vom MT aus pingen kannst, vom Client aber nicht, ist vielleicht ein Fehler in der Peer-Konfig bei allowed address (fehlt bei Deinen Bildern). Dort muss natürlich auch Dein jeweiliges "normales" Netz erlaubt sein, das hinter den MTs für die Clients eingerichtet ist.
Also in einfacheren Worten: Bei allowed address gibt es jeweils zwei Einträge für Netze: Das eigene Netz und das gegenüber liegende WG-Netz. Letzeres kann (und sollte) mit einer 32er Maske versehen werden, aber das kannst Du dann machen, wenn alles andere geht.
Viele Grüße, commodity
Wenn Du vom MT aus pingen kannst, vom Client aber nicht, ist vielleicht ein Fehler in der Peer-Konfig bei allowed address (fehlt bei Deinen Bildern). Dort muss natürlich auch Dein jeweiliges "normales" Netz erlaubt sein, das hinter den MTs für die Clients eingerichtet ist.
Also in einfacheren Worten: Bei allowed address gibt es jeweils zwei Einträge für Netze: Das eigene Netz und das gegenüber liegende WG-Netz. Letzeres kann (und sollte) mit einer 32er Maske versehen werden, aber das kannst Du dann machen, wenn alles andere geht.
Viele Grüße, commodity
ich kann von beiden Seiten von MT zu MT die IP 100.64.64.1 + 100.64.64.2 pingen.
👏 Glückwunsch, damit rennt der Tunnel!Am UDP Port hat das abe rnicht gelesen! Du solltest besser auch im 5xxxx Bereich bleiben, denn das ist der Bereich der Ephemeral Ports die dafür vorgesehen sind! https://en.wikipedia.org/wiki/Ephemeral_port
Die 13231 liegt im Bereich der IANA Ports und ist keine intelligente Wahl. Warum MT gerade die gewählt hat ist unverständlich.
weil per CMD geht das pingen nicht?
Der Mikrotik supportet (noch) kein Cryptokey Routing was bei WG sonst Standard ist so das du die Routen zu den jeweiligen remoten LANs statisch im MT definieren musst! Hast du das gemacht?! Vermutlich nicht!Das Mikrotik Wireguard Handbuch weist explizit darauf hin!! ("IP and routing information must be configured...") Lesen hilft also...
Im dem MT Ping Tool kannst du unter dem "Advanced" Reiter immer eine Absender (Source) IP angeben mit der der Ping ausgeführt wird. Wenn du hier die IP des jeweiligen lokalen LAN Interfaces einträgst und dann das jeweils remote WG Interface und remote LAN Interface pingst kannst du immer sicherstellen das das Routing sauber klappt! Gewusst wie... 😉
Die Route setzt der MT bei Einrichtung von WG selbst.
Sonst ja aber leider (noch) nicht beim Mikrotik!
Hallo @Newbie88,
b) Bin mir gerade nciht sicher ob ich innerhalb WG überhaupt ne Route einrichten muss. Die würde ich erstmal deaktivieren und es ohne testen. Der MT - als Router - kennt ja seine selbst verwalteten Adressbereiche. Und ohne (trennende) FW-Regel routet der eigentlich alles von links nach rechts und zurück.
https://www.speedguide.net/ip/100.64.64.2
Bei sowas werden die Kollegen hier eigentlich immer ganz wuschig. Passiert aber gerne mal, wenn "man" besonders kreativ sein möchte
a) Guck, dass die Adresse aus dem private Bereich kommt!
https://www.lifewire.com/what-is-a-private-ip-address-2625970
b) Guck das sie NICHT 192.168.1780/24 lautet ODER einem Deiner von der Fritzbox verwalteten (anderen) Adressbereiche entspricht! Weil sie dann ja nicht routen kann, wenn sie nicht zwischen "hier", im VPN-Tunnel und "dort" (hinter der anderen Fritzbox) unterscheiden kann!
Ich würde da aber auch nicht /24, sondern /29 oder /30 nehmen. Die Wahrscheinlichkeit, dass Du über 250 VPN-Punkte zusammenbindest halte ich für sehr gering
https://www.freecodecamp.org/news/subnet-cheat-sheet-24-subnet-mask-30-2 ...
An einem dieser 3 Möglichkeiten: FB1, FB2 und VPN-Tunnel ginge der Adressbereich schon. Das ist ein Adressbereich, wie jeder andere auch, nur halt - Dank AVM - recht weit verbreitet. Stelle Dir einen "Client-Server"-Setup vor und Du versuchst Dich aus dem Fritzbox-WLan eines Kumpels mit 178.168.178.0/24 in Dein privates VPN zu verbinden. Und schon haste Probleme. Deshalb nimmt man - überall, wo man es beeinflussen kann, gleich andere Bereiche.
PS: Screenshots: Am Feld "Last Handshake" (unter Client) kannst Du zuverlässig erkennen, ob der Tunnel steht. Wenn Du dann - immer noch nicht - die Geräte auf der anderen Seite aufrufen kannst, dann liegts am Routing auf der Fritzbox ODER ggfs. im Mikrotik.
Logging:
@aqui war schnellerIn den FB habe ich die Ports 13231 und 51820 UDP freigeschaltet
Würde ich auf beiden Seiten vereinheitlichen. Ist zwar technisch nicht notwendig, aber Du reduzierst die FehlerquellenUnd zwei Routes gesetzt
a) Du setzt in der Fritzbox(!) ne Route, damit die weiß wo das Interface ist, auf das sie Anfragen an den anderen VPN-Standort schickt. Also von Fritzbox zur IP-Adresse des MTs!b) Bin mir gerade nciht sicher ob ich innerhalb WG überhaupt ne Route einrichten muss. Die würde ich erstmal deaktivieren und es ohne testen. Der MT - als Router - kennt ja seine selbst verwalteten Adressbereiche. Und ohne (trennende) FW-Regel routet der eigentlich alles von links nach rechts und zurück.
Als WG Adressen habe ich mich für die 100.64.64.1/24 und 100.64.64.0/24
@aqui war zwar schneller. Aber so wie ich das verstehe, verwendest Du jetzt ein Zitat: "carrier-grade NAT communication between service provider and subscribers"https://www.speedguide.net/ip/100.64.64.2
Bei sowas werden die Kollegen hier eigentlich immer ganz wuschig. Passiert aber gerne mal, wenn "man" besonders kreativ sein möchte
a) Guck, dass die Adresse aus dem private Bereich kommt!
https://www.lifewire.com/what-is-a-private-ip-address-2625970
b) Guck das sie NICHT 192.168.1780/24 lautet ODER einem Deiner von der Fritzbox verwalteten (anderen) Adressbereiche entspricht! Weil sie dann ja nicht routen kann, wenn sie nicht zwischen "hier", im VPN-Tunnel und "dort" (hinter der anderen Fritzbox) unterscheiden kann!
Ich würde da aber auch nicht /24, sondern /29 oder /30 nehmen. Die Wahrscheinlichkeit, dass Du über 250 VPN-Punkte zusammenbindest halte ich für sehr gering
https://www.freecodecamp.org/news/subnet-cheat-sheet-24-subnet-mask-30-2 ...
Als Allowed habe ich mich extra für 0.0.0.0/0
Was habe ich oben geschrieben? Ich verwende ja 192.168.178.0... Kling quasi auch nach einem Fehler?
Naja, s.o. Du darfst auf keinen Fall auf beiden Seiten des Tunnels den jeweils selben Adressbereich haben! Also sprich hinter beiden Fritzen z.B. 192.168.178.0/24 (das wäre der AVM-Standard). Und weil wir bei WG auch "natten", wär das auch innerhalb des Tunnels (bei Dir aktuell 100.64...) das selbe Problem.An einem dieser 3 Möglichkeiten: FB1, FB2 und VPN-Tunnel ginge der Adressbereich schon. Das ist ein Adressbereich, wie jeder andere auch, nur halt - Dank AVM - recht weit verbreitet. Stelle Dir einen "Client-Server"-Setup vor und Du versuchst Dich aus dem Fritzbox-WLan eines Kumpels mit 178.168.178.0/24 in Dein privates VPN zu verbinden. Und schon haste Probleme. Deshalb nimmt man - überall, wo man es beeinflussen kann, gleich andere Bereiche.
PS: Screenshots: Am Feld "Last Handshake" (unter Client) kannst Du zuverlässig erkennen, ob der Tunnel steht. Wenn Du dann - immer noch nicht - die Geräte auf der anderen Seite aufrufen kannst, dann liegts am Routing auf der Fritzbox ODER ggfs. im Mikrotik.
Passiert aber gerne mal, wenn "man" besonders kreativ sein möchte
Nein, das hat ausnahmsweise nichts mit IP "Kreativität zu tun sondern ist in diesem Falle gewollt und ganz bewusst so gewählt weil genau dafür dieser Bereich da ist. 😉Es hat den großen Vorteil das es bei der Vielzahl der RFC1918 IP Netze niemals eine Überschneidung geben kann. Relevant ist das nicht so sehr bei Site-to-Site VPNs aber VPNs mit mobilen Clients umso mehr. Siehe dazu auch hier.
ob ich innerhalb WG überhaupt ne Route einrichten muss
Innerhalb nicht. Es sind aber (noch) statische Routen für die jeweiligen remoten LAN IP Netze erforderlich. Siehe oben Anleitungswiki von Mikrotik...Und weil wir bei WG auch "natten",
Wie kommst du darauf? Der Mikrotik NATet nicht innerhalb des WG Tunnels. Wäre ja auch unsinnig und führt nur zu überflüssigem Performanceverlust.immer noch nicht - die Geräte auf der anderen Seite aufrufen kannst
Er kann innerhalb des Tunnel ja fehlerlos pingen. Bedeutet das der Tunnel aufgebaut ist aber (vermutlich) die statischen Routen der LAN Netze fehlen.denke aber ich gehe wieder auf die 100.64.xx.xx zurück,
Musst du nicht unbedingt! Der RFC erlaubt alles von 100.64.0.1 bis 100.127.255.254. Guckst du hier.Ansonsten besser noch einmal etwas zur Logik von IP Subnetzmasken nachlesen wenn das noch nicht im Kopf sein sollte! 😉
Wer IPSec und Wireguard auf nem Mikrotik zustande bringt, darf sich auf keinen Fall mehr
Völlige PC-Noobs - das wäre mal einen Freitags-Thread wert...
Gestern habe ich solchen z.B. die Funktion von WIN+L erklärt. Oder letzte Woche rief mich einer an, er käme "plötzlich" nicht mehr auf seinen Router (eine Woche vorher hatte er mich gebeten, das Router-Passwort zu ändern )
Viele Grüße, commodity
völliger PC Noob
nennen.Völlige PC-Noobs - das wäre mal einen Freitags-Thread wert...
Gestern habe ich solchen z.B. die Funktion von WIN+L erklärt. Oder letzte Woche rief mich einer an, er käme "plötzlich" nicht mehr auf seinen Router (eine Woche vorher hatte er mich gebeten, das Router-Passwort zu ändern )
Viele Grüße, commodity
@aquis Anleitungen führen immer zum Erfolg!
Ich frage mich öfter, wie viele Netze in diesem Land nicht laufen würden, wenn unser Kollege @aqui nicht wäre...
Viele Grüße, commodity
Bevor jetzt die Profis antworten:
Setze doch mal testweise eine Route mit dem IP-Adressraum der Gegenseite auf das WG-interface. Das ist ja jetzt kein IP-Bereich, den der MT kennt, denn der wird ja von der "anderen" Fritze verwaltet.
PC pingt auf PC Gegenseite:
PC > Fritzbox 1 > (routet auf) MT1 > MT1 (routet evtl. gerade nicht auf) WG1-Interface > Tunnel > WG2-Interface ... usw.
Wenn, müsstest Du das aber auf beiden Seiten konfigurieren, damit auch die Rückrute funktioniert. Ich habe leider vor ein paar Monaten mein entsprechendes Setup umgestellt. Das war genau so, wie bei Dir, aufgebaut und lief knapp ein Jahr problemlos.
Setze doch mal testweise eine Route mit dem IP-Adressraum der Gegenseite auf das WG-interface. Das ist ja jetzt kein IP-Bereich, den der MT kennt, denn der wird ja von der "anderen" Fritze verwaltet.
PC pingt auf PC Gegenseite:
PC > Fritzbox 1 > (routet auf) MT1 > MT1 (routet evtl. gerade nicht auf) WG1-Interface > Tunnel > WG2-Interface ... usw.
Wenn, müsstest Du das aber auf beiden Seiten konfigurieren, damit auch die Rückrute funktioniert. Ich habe leider vor ein paar Monaten mein entsprechendes Setup umgestellt. Das war genau so, wie bei Dir, aufgebaut und lief knapp ein Jahr problemlos.
Nein, die statischen Routen zu den Remote-Netzen muss man auf dem Mikrotik immer selbst setzen
Also bspw.
Auf der Gegenseite natürlich analog für die Netze der Gegenseite mit der WG-IP der Gegenstelle als GW.
Also bspw.
/ip route add dst-address=192.168.178.0/24 gateway=100.66.66.2
Wenn du kein IPv6 über den Tunnel nutzt kannst du die MTU auch noch auf 1440 hoch setzen, das bringt dann auch noch mal 20 Bytes mehr pro Paket.
Leider taucht da plötzlich eine IP (10.255.255.1/30) auf, welche davor in der Übersich nicht
zu finden ist.Bist du dir da ganz sicher??? Ich habe das Tutorial eben nach dem String "10.255.255" durchsuchen lassen. Kein einziger Treffer! WO bitte soll das stehen??? Oder halluzinierst du schon?? 😉
10.66.66.1 + 10.66.66.2 kann ich beidseitig pingen. Mehr geht leider nicht.
Aber das ist doch dann schon mehr als die halbe Miete!! Dann trägst du lediglich noch die statischen Routen in die MTs ein und jutt iss:MT mit lokalem LAN = 192.168.89.0/24
Statische Route: Ziel: 192.168.88.0/24 Gateway: 100.66.66.2
MT mit lokalem LAN = 192.168.88.0/24
Statische Route: Ziel: 192.168.89.0/24 Gateway: 100.66.66.1
Diese beiden Routen fehlen, obwohl man dich mehrfach darauf hingewiesen hat, in deinem obigen Screenshots!!
Jetzt die Frage an dich ob man sich dann groß wundern muss das dann nichts klappt ausser die Tür!! Dzzz...
Glückwunsch zur Wireguard-Premiere!
Die 10.255.255.1/30 bzw. 10.255.255.2/30 sind die Tunnel-IPs von Wireguard im Mikrotik-Beispiel. Die Tunnel-IPs wählst Du selbst, sie müssen nur in einem gemeinsamen Netz liegen. Bei Dir ist das 10.66.66.1 + 10.66.66.2 /24 gewesen. Da nur zwei Adressen gebraucht werden, hat Mikrotik ein 30er Netz genommen, das nur zwei Adressen hat. Du hast 254
Zur Vertiefung: https://www.youtube.com/watch?v=Q4OfOBA47AM&t=1272s
Und danke für den nützlichen Vergleich:
Die Differenz kann auch an der "Tagesform" Deines Anschlusses liegen.
Und die Physik lässt sich auch durch Wireguard nicht überlisten. Wie erwartet.
Vor lauter Begeisterung hast Du nun das ursprüngliche Ziel aus dem Blick verloren: Steigerung des Durchsatzes
Aber Neues lernen finde ich auch wichtiger - und der Durchsatz ist ja gar nicht schlecht.
Viele Grüße, commodity
Die 10.255.255.1/30 bzw. 10.255.255.2/30 sind die Tunnel-IPs von Wireguard im Mikrotik-Beispiel. Die Tunnel-IPs wählst Du selbst, sie müssen nur in einem gemeinsamen Netz liegen. Bei Dir ist das 10.66.66.1 + 10.66.66.2 /24 gewesen. Da nur zwei Adressen gebraucht werden, hat Mikrotik ein 30er Netz genommen, das nur zwei Adressen hat. Du hast 254
Zur Vertiefung: https://www.youtube.com/watch?v=Q4OfOBA47AM&t=1272s
Und danke für den nützlichen Vergleich:
Zitat von @Newbie88:
IPSec:[ ID] Interval Transfer Bandwidth
[ 4] 0.00-50.01 sec 209 MBytes 35.1 Mbits/sec sender
[ 4] 0.00-50.01 sec 209 MBytes 35.1 Mbits/sec receiver
Wireguard:[ 4] 0.00-50.01 sec 209 MBytes 35.1 Mbits/sec sender
[ 4] 0.00-50.01 sec 209 MBytes 35.1 Mbits/sec receiver
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-50.00 sec 195 MBytes 32.7 Mbits/sec sender
[ 4] 0.00-50.00 sec 195 MBytes 32.6 Mbits/sec receiver
[ 4] 0.00-50.00 sec 195 MBytes 32.7 Mbits/sec sender
[ 4] 0.00-50.00 sec 195 MBytes 32.6 Mbits/sec receiver
Die Differenz kann auch an der "Tagesform" Deines Anschlusses liegen.
Und die Physik lässt sich auch durch Wireguard nicht überlisten. Wie erwartet.
Vor lauter Begeisterung hast Du nun das ursprüngliche Ziel aus dem Blick verloren: Steigerung des Durchsatzes
Aber Neues lernen finde ich auch wichtiger - und der Durchsatz ist ja gar nicht schlecht.
Viele Grüße, commodity
Du brauchst eigentlich nur nen neuen Peer am MIkrotik anlegen, dem gibst du den die nächste freie IP (z.B. 100.66.66.3) und stellst dafür im Peer die AllowedIPs auf 100.66.66.3/32 fertsch.
anbei ein Screenshot.
Ohh man... 🤦♂️Das ist das Beispiel von Mikrotik die im internen Wireguard VPN Netz eben 10.255.255.0er IP Adressen benutzen statt deiner 10.66.66.0er die du gewählt hast. Und es ist auch nicht mein Tutorial sondern das vom Hersteller selber!
Die nutzen ja auch 10.1.101 und 10.1.202 Adressen für die lokalen LAN. Das zumindestens konntest du ja abstrahieren auf die von dir verwendeten IP Adressen. Warum ist es dann am internen WG IP Netz gescheitert bei dir?? Soviel Intelligenz solltest du aber schon aufbringen das auf deine verwendeten IP Adressen übertragen zu können...
Der gesamte RFC 1918 Bereich an privaten IPs steht dir ja zu deiner freien Verfügung! Vielleicht auch noch etwas zur Logik von Subnetzmasken lesen und verstehen.
Hast Du das MT Handbuch auch gemacht?
Ja, nee, iss klar! Ich schreibe sowas für MT in meiner Freizeit! 🙈🤣
Öhm die Route auf dem Mikrotik ist Schwachsinn. Du hast ja nicht das Netz 192.168.178.0/4 hinter dem Telefon mit der .3 . Das GW muss immer auf das Device Zeigen hinter dem das Netz zu erwarten ist. Für den einzelnen Dial-In Peer brauchst du keine statische Route. Auf dem Telefon muss dafür das 192.168.178.0/24 Netz in den AllowedIPs stehen wenn du dort nicht schon 0.0.0.0/0 stehen hast und alles über den Tunnel leitest.
Netzwerkwissen, Teil 1 Grundlagen zu Routing und Subnetzbildung
IP-Routing
Netzwerkwissen, Teil 1 Grundlagen zu Routing und Subnetzbildung
IP-Routing
Das liegt daran das da viel Müll konfiguriert wurde
- Internes 100.66.66.0/24 Netz ist 2mal drin = falsch
- .178.0er Route via .66.3 ist völliger Unsinn, denn das .178.0er Netz ist ja direkt dran an ether1 das netz kennt der Router also! Wenn dann gehört da <remotes-LAN> via .66.3 rein wenn die .66.3 die remote Tunnel IP ist. Kollege @6017814589 hat es oben schon gesagt.
- Es fehlt völlig das remote LAN des remoten MT
- Routing über ether1 ins lokale Koppelnetz zur FB klappt einzig nur dann wenn KEIN NAT (Adress Translation) an ether1 gemacht wird!!! Ansonsten bleibst du an der NAT Firewall hängen! Du kannst dann immer nur die jeweils remoten LANs an den Mikrotiks erreichen oder MUSST NAT am MT ausschalten (keine Default Konfig!!)
Irgendwas stimmt da bei deiner internen WG Adressierung nicht. Dort dürfte niemals 2 mal das gleiche IP Netz in den Routes stehen.
In der FritzBox muss dann zwingend eine statische Route definiert sein:
Zielnetz: 10.66.66.0/30 Gateway: <FB-LAN_IP_Mikrotik> !!
Ohne diese statische Route in der FB sind keine Endgeräte aus dem FB LAN erreichbar weil deren Default Gateway immer die FB ist und die muss wissen WIE sie das 10.66er Client WG Netz erreichen kann.
da die Gegenseite ein Handy ist (10.66.66.3)?
OK, dann entfällt das natürlich. Sorry...Ich habe die Variante "keine Default Konfig"
OK, dann sollte das klappen. Achte darauf das in der Client (Handy) WG Konfig dann steht "Allowed IPs 10.66.66.1/32, 192.168.178.0/24 !! (WG Tunnel IP des MT dann .66.1 und Handy hat die .66.2)In der FritzBox muss dann zwingend eine statische Route definiert sein:
Zielnetz: 10.66.66.0/30 Gateway: <FB-LAN_IP_Mikrotik> !!
Ohne diese statische Route in der FB sind keine Endgeräte aus dem FB LAN erreichbar weil deren Default Gateway immer die FB ist und die muss wissen WIE sie das 10.66er Client WG Netz erreichen kann.
Oder muss für jeden Peer eine Einstellung erfolgen?
Mit einer internen /30er Maske kannst du ja eh nur einen einzigen Peer adressieren!! Hast ja damit nur 2 nutzbare Peer IP Hostadressen und eine davon hat der WG Server im MT. Mit der Maske sind weitere Peers technisch logischerweise nicht möglich.Da geht halt auch mal einiges schief.
Ist ja auch normal. Also dranbleiben und das fixen! 😉
Und vor allem erst mal die Grundlagen des Routings aneignen (so schwer ist das ja nicht) dann wird das logisch man kann sich das dann selbst herleiten .
Bisschen dazu steht hier. 😉
Wenn du das bestehende WG Interface auch für mobile Clients nutzt musst du die Allowed-IPs beachten. Denn wenn sich nun bspw. ein Telefon am Mikrotik einwählt geht der Traffic des Clients bei Wireguard erst zum Mikrotik und wird von dort aus quasi mit der Wireguard Crypto des Mikrotik an das andere Netz übertragen, d.h. dann das in dem Remote-Netz für den mobilen Peer auch die Wireguard interne IP des mobilen Clients in den Allowed-IPs stehen muss weil ja das Cryptokey-Routing nur von den Peers Traffic erlaubt welche auch in den Allowed-IPs stehen. Alternativ setzt man hier dann eben statt einer 32 Maske eine kleinere die dann alle inkludiert.
Wenn ich da mal eine Antwort oder Lösung dazu parat hätte
Das war hoffentlich jetzt nur ironisch gemeint, oder??? Wenn nicht: Dein internes WG Netz ist dann z.B. 100.66.66.0/28 mit den gültigen Host IP Adressen von .1 bis .14. Server hat dann intern die .1 und den Client Peers vergibst du die .2 bis .14
Halte dich einfach immer ans WG Tutorial, da ist alles beschrieben.