WireGuard auf Mikrotik
Moin zusammen,
vor einigen Monaten habe ich Wireguard auf meinem MT Router eingerichtet.
Die Adressen sind angelegt und in der FW entsprechende Regeln definiert.
Auf dem Client sieht die Konfiguration so aus:
Funktioniert alles wunderbar, solange der Client sich mit einem WLAN (außerhalb des hauseigenen WLANs, z.B. im Hotel) verbinden kann. 4G oder 4G+ sind schon schwierig und das Webinterface meiner Homeassistent App zeigt einen Timeout an. Das nervt etwas, da man halt nicht immer ein WLAN zur Verfügung hat.
Ich habe keine Ahnung an welcher Schraube man hier drehen kann, offenbar ist die mobile Verbindung zu langsam. Ich habe schon mal mit MTU herumgespielt, aber das führt zu keinem wirklichen Erfolg.
Frage 2:
In Homeassitant habe ich eingebettete Webseiten von Hosts aus dem selben Subnetz. Allerdings wird der Hostname dieser Webserver über die VPN Verbindung nicht aufgelöst. Was muss ich in Wireguard wo einstellen, damit die Hostnamen aus meinem lokalen Subnetz über VPN aufgelöst werden. Wenn ich die IP Adressen konfiguriere, werden die Daten auch via VPN Verbindung angezeigt. Heißt, grundsätzlich funktioniert das schon.
vor einigen Monaten habe ich Wireguard auf meinem MT Router eingerichtet.
Name: VPN
MTU: 1320
Listen Port: 08/15
Private Key: 4711
Public Key: 1234
Peer1:
Interface: VPN
Allowed address: 172.16.nn.xx/32Die Adressen sind angelegt und in der FW entsprechende Regeln definiert.
Auf dem Client sieht die Konfiguration so aus:
[Interface]
PrivateKey = 4711
Address = 172.16.nn.xx/32
DNS = 172.16.nn.1
[Peer]
PublicKey =1234
AllowedIPs = 0.0.0.0/0
Endpoint = mydomain:08/15
PersistentKeepalive = 30Funktioniert alles wunderbar, solange der Client sich mit einem WLAN (außerhalb des hauseigenen WLANs, z.B. im Hotel) verbinden kann. 4G oder 4G+ sind schon schwierig und das Webinterface meiner Homeassistent App zeigt einen Timeout an. Das nervt etwas, da man halt nicht immer ein WLAN zur Verfügung hat.
Ich habe keine Ahnung an welcher Schraube man hier drehen kann, offenbar ist die mobile Verbindung zu langsam. Ich habe schon mal mit MTU herumgespielt, aber das führt zu keinem wirklichen Erfolg.
Frage 2:
In Homeassitant habe ich eingebettete Webseiten von Hosts aus dem selben Subnetz. Allerdings wird der Hostname dieser Webserver über die VPN Verbindung nicht aufgelöst. Was muss ich in Wireguard wo einstellen, damit die Hostnamen aus meinem lokalen Subnetz über VPN aufgelöst werden. Wenn ich die IP Adressen konfiguriere, werden die Daten auch via VPN Verbindung angezeigt. Heißt, grundsätzlich funktioniert das schon.
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672868
Url: https://administrator.de/forum/wireguard-auf-mikrotik-672868.html
Ausgedruckt am: 24.06.2025 um 15:06 Uhr
16 Kommentare
Neuester Kommentar
Der Mikrotik erlernt keine IP Routen automatisch wie man das von Winblows, Mac OS oder Linux kennt!
Wenn du ein Netzwerk hinter dem Client (Initiator) erreichen willst musst du bei Mikrotik immer eine statische Route setzen! Auch vice versa, sollte der MT der WG Client sein. Darüber stolpert man vielfach.
Das Mikrotik Handbuch weist explizit darauf hin! ("routing information must be configured" Wenn man es denn liest...)
Weiterer Konfigfehler ist auf deinem Client dessen IP Adresse im internen WG Netz! Dort nutzt du eine falsche Subnetzmaske! Ein Grund warum ein korrektes Cryptokey Routing dann scheitert mit deinen Symptomen. Die MTU muss man in der Regel nicht anfassen und kann sie auf dem Default belassen. Sie hat auch mit dem Problem nichts zu tun.
Überlege dir zusätzlich ob es sinnvoll ist im Client ein Gateway Redirect zu machen?! Was das ist erklärt dir im Detail das hiesige Wireguard Tutorial!
In der Mehrzahl der Fälle ist der Redirect aus Performance Sicht immer kontraproduktiv und ein Split Tunneling deutlich flotter. Es sei denn man möchte z.B. aus Sicherheitsgründen explizit allen Traffic clientseitig in den Tunnel schicken.
In den weiterführenden Links des Tutorials am Schluss findest du außerdem diverse Mikrotik Live Beispiele.
Wenn du ein Netzwerk hinter dem Client (Initiator) erreichen willst musst du bei Mikrotik immer eine statische Route setzen! Auch vice versa, sollte der MT der WG Client sein. Darüber stolpert man vielfach.
Das Mikrotik Handbuch weist explizit darauf hin! ("routing information must be configured" Wenn man es denn liest...)
Weiterer Konfigfehler ist auf deinem Client dessen IP Adresse im internen WG Netz! Dort nutzt du eine falsche Subnetzmaske! Ein Grund warum ein korrektes Cryptokey Routing dann scheitert mit deinen Symptomen. Die MTU muss man in der Regel nicht anfassen und kann sie auf dem Default belassen. Sie hat auch mit dem Problem nichts zu tun.
Allerdings wird der Hostname dieser Webserver über die VPN Verbindung nicht aufgelöst. Was muss ich in Wireguard wo einstellen
Hier musst du dem Client einen lokalen DNS Server in der WG Konfig mitgeben! Wie das geht steht im u.a. Tutorial im Kapitel: DNS Eintrag im ClientÜberlege dir zusätzlich ob es sinnvoll ist im Client ein Gateway Redirect zu machen?! Was das ist erklärt dir im Detail das hiesige Wireguard Tutorial!
In der Mehrzahl der Fälle ist der Redirect aus Performance Sicht immer kontraproduktiv und ein Split Tunneling deutlich flotter. Es sei denn man möchte z.B. aus Sicherheitsgründen explizit allen Traffic clientseitig in den Tunnel schicken.
In den weiterführenden Links des Tutorials am Schluss findest du außerdem diverse Mikrotik Live Beispiele.
Moin aqui,
ich kann mir kaum vorstellen, dass es am falschen Routing liegt, da das Ganze ja läuft und zwar ziemlich zuverlässig! LTE geht auch, nur bei 4G und 4G+ kommen die Timeouts. Wenn es ein Routing Problem wäre, würde ich erwarten, dass es überhaupt nicht geht. Ok, die Subnetzmaske mag falsch sein, aber ich verstehe noch nicht an welcher Stelle, diese falsch sein soll! Aber auch da wäre meine Erwartung dass das nichts mit dem Medium zu tun hat, über das ich die VPN-Verbindung aufbaue. Liege ich da falsch? Kann das die Ursache sein?
Als Endgerät nutze ich ein Android Smartphone.
Die Sache mit dem DNS und dem Split Tunnel schaue ich mir an. M.E habe ich das auf einem der Smartphones auch so gemacht.
ich kann mir kaum vorstellen, dass es am falschen Routing liegt, da das Ganze ja läuft und zwar ziemlich zuverlässig! LTE geht auch, nur bei 4G und 4G+ kommen die Timeouts. Wenn es ein Routing Problem wäre, würde ich erwarten, dass es überhaupt nicht geht. Ok, die Subnetzmaske mag falsch sein, aber ich verstehe noch nicht an welcher Stelle, diese falsch sein soll! Aber auch da wäre meine Erwartung dass das nichts mit dem Medium zu tun hat, über das ich die VPN-Verbindung aufbaue. Liege ich da falsch? Kann das die Ursache sein?
Als Endgerät nutze ich ein Android Smartphone.
Die Sache mit dem DNS und dem Split Tunnel schaue ich mir an. M.E habe ich das auf einem der Smartphones auch so gemacht.
aber ich verstehe noch nicht an welcher Stelle, diese falsch sein soll!
Zeigt das du das Tutorial nicht gelesen hast! 
[Interface]
PrivateKey = 4711
Address = 172.16.nn.xx/24
DNS = 172.16.nn.1
[Peer]
PublicKey =1234
AllowedIPs = 0.0.0.0/0
Endpoint = mydomain:08/15
PersistentKeepalive = 30 Ist hier etwas geraten weil du leider keine Angaben über die Größe (Prefix) des internen WG IP Netzes machst.
Hm! Ich verstehe deine Frage schon wieder nicht. Was heißt, ich mache keine Angaben zum internen WG Netzwerk! Ich habe auf dem WG Interface ein ganz normales Subnetz konfiguriert (Address:172.16.nn.1/24, Network: 172.16.nn.0).
Ich habe WG für Mikrotik damals analog zu einem Video konfiguriert und da musste ich nirgends statische Routen eintragen, so wie in deinem Tut beschrieben. Die Routen gibt es bei mir natürlich auch, sind aber automatisch angelegt worden. Von daher unterscheidet sich dein Tut etwas von dem Video von damals.
Das mit der Subnetzmaske ist ein valider Punkt, den gucke ich mir in deinem Tut noch mal an, aber dennoch verstehe ich immer noch nicht, was das mit dem Übertragungsmedium zu tun haben soll. Wie gesagt, über LTE oder einer WLAN-Verbindung zu einem Hotspot läuft alles seit zwei Jahren reibungslos. Schauen wir mal.
wegen dem DNS. Das läuft noch nicht.
Ich habe auf dem Smartphone nachgeschaut. Unter Interface steht bei Adressen nun 172.16.nn.102/24 Der Nameserver ist der 172.16.nn.1. Das sind exakt die Adressen aus dem Subnetz, die ich auf dem MT konfiguriert habe.
Mein Homeassistant befindet sich im Subnet 172.16.yy.0 und ich habe ein Forward vom WG Subnetz in das yy.0 konfiguriert. Leider werden aber keine Hostnamen aufgelöst. Muss ich die DNS Requests auch noch weiterleiten?
NACHTRAG:
Das mit dem DNS geht jetzt, ich habe bei den eingebetteten Webseiten im Homeassistant nun den FQDN konfiguriert. jetzt geht es auch über VPN.
Ich habe WG für Mikrotik damals analog zu einem Video konfiguriert und da musste ich nirgends statische Routen eintragen, so wie in deinem Tut beschrieben. Die Routen gibt es bei mir natürlich auch, sind aber automatisch angelegt worden. Von daher unterscheidet sich dein Tut etwas von dem Video von damals.
Das mit der Subnetzmaske ist ein valider Punkt, den gucke ich mir in deinem Tut noch mal an, aber dennoch verstehe ich immer noch nicht, was das mit dem Übertragungsmedium zu tun haben soll. Wie gesagt, über LTE oder einer WLAN-Verbindung zu einem Hotspot läuft alles seit zwei Jahren reibungslos. Schauen wir mal.
wegen dem DNS. Das läuft noch nicht.
Ich habe auf dem Smartphone nachgeschaut. Unter Interface steht bei Adressen nun 172.16.nn.102/24 Der Nameserver ist der 172.16.nn.1. Das sind exakt die Adressen aus dem Subnetz, die ich auf dem MT konfiguriert habe.
Mein Homeassistant befindet sich im Subnet 172.16.yy.0 und ich habe ein Forward vom WG Subnetz in das yy.0 konfiguriert. Leider werden aber keine Hostnamen aufgelöst. Muss ich die DNS Requests auch noch weiterleiten?
NACHTRAG:
Das mit dem DNS geht jetzt, ich habe bei den eingebetteten Webseiten im Homeassistant nun den FQDN konfiguriert. jetzt geht es auch über VPN.
Was heißt, ich mache keine Angaben zum internen WG Netzwerk!
Du hast ja oben eine falsche /32 Hostmaske bei der internen WG Adressierung angeben aber keine Angaben über deine tatsächlich dort verwendete Subnetzmaske gemacht im internen WG Netz. Das war damit gemeint... Die Subnetzmaske hat mit dem physischen Übertragungsmedium natürlich rein gar nichts zu tun, da hast du Recht. Sie ist aber dennoch wichtig damit das Cryptokey Routing sauber funktionieren kann. Bei deinem Client ist sie aber mit einer Hostmaske de facto falsch oben.
und da musste ich nirgends statische Routen eintragen
Ja, das ist auch völlig normal und musst du auch nicht bei reiner Client Nutzung was du ja in deinem Falle machst. Die Client Adressen "kennt" der Mikrotik ja, da sie an ihm direkt dran sind.Man kann mit dem Client aber auch sein dahinter liegendes lokales Netz routen wie es bei einer Site-to-Site VPN Verbindung üblich ist. Bei dir ist das aber bei reiner Client Nutzung nicht der Fall. In sofern kannst du den Routing Hinweis dann entspannt ignorieren.
jetzt geht es auch über VPN.
👏 👍
Wenn es das denn nun war als Lösung bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Moin aqui,
nein, das war nicht die Lösung! Über 4G (und kleiner) geht die Verbindung weiterhin nicht!
nein, das war nicht die Lösung! Über 4G (und kleiner) geht die Verbindung weiterhin nicht!
Eigentlich wie immer, als erstes Wireshark Trace machen und du siehst i.d.R sofort die Ursache.
Wenn da zu viele retransmissions auftreten, ist fragmentierter Traffic und damit die MTU die Ursache.
Als erstes also sicherstellen das die PMTU Discovery durchgängig vom Client bis zum Ziel funktioniert, d.h. ICMP Frames müssen vom Client zum Ziel durchkommen (Firewall am Mikrotik und am Zieldevice checken!), ist das nicht der Fall, dies als erstes korrigieren! Nur für den Fall das die der TCP-Stack der Devices kein PMTU beherrscht (eher selten), kann man auch ein explizites MSS Clamping in der Mikrotik Mangle Chain einsetzen (daran denken den "gemangelten" Traffic von einem evt. vorhandenen Fasttrack auszunehmen!).
Wie man die MTU via Ping mit der Option -f für "Do not fragment" ermittelt sollte man in einem Admin Forum ja eigentlich nicht mehr erwähnen müssen ...
Beachten sollte man auch, dass bestimmte Ports je nach Provider evt. auch einer/einem Drosselung/TrafficManagment unterliegen. Um Probleme mit dem Port auszuschließen, sollte man also auch mal temp. den Port wechseln.
Wenn da zu viele retransmissions auftreten, ist fragmentierter Traffic und damit die MTU die Ursache.
Als erstes also sicherstellen das die PMTU Discovery durchgängig vom Client bis zum Ziel funktioniert, d.h. ICMP Frames müssen vom Client zum Ziel durchkommen (Firewall am Mikrotik und am Zieldevice checken!), ist das nicht der Fall, dies als erstes korrigieren! Nur für den Fall das die der TCP-Stack der Devices kein PMTU beherrscht (eher selten), kann man auch ein explizites MSS Clamping in der Mikrotik Mangle Chain einsetzen (daran denken den "gemangelten" Traffic von einem evt. vorhandenen Fasttrack auszunehmen!).
Wie man die MTU via Ping mit der Option -f für "Do not fragment" ermittelt sollte man in einem Admin Forum ja eigentlich nicht mehr erwähnen müssen ...
Beachten sollte man auch, dass bestimmte Ports je nach Provider evt. auch einer/einem Drosselung/TrafficManagment unterliegen. Um Probleme mit dem Port auszuschließen, sollte man also auch mal temp. den Port wechseln.
1
Moin, Moin,
hat etwas gedauert, aber ich habe die MTU jetzt von meinem Android mit dem Tool Ping&Net ermittelt. Sie liegt bei 1320. Das ist auch das, was in der WireGuard Konfig eingestellt ist. Trotzdem kann ich meinen Server nicht unter 4G erreichen. Parallel habe ich WireGuard auch unter Windows auf dem Laptop laufen. jetzt baue ich zwar die Verbindung zum Internet mit dem Android Handy auf, aber auch hier zeigt sich das gleiche Problem. Bei Netzten unter 4G+ gibt es keine Verbindung zum Webinterface des Hosts. Der Ping geht durch; Forward auf das WireGuard Interface ist vorhanden. Den Port habe ich noch nicht gewechselt. Provider ist Congstar.
hat etwas gedauert, aber ich habe die MTU jetzt von meinem Android mit dem Tool Ping&Net ermittelt. Sie liegt bei 1320. Das ist auch das, was in der WireGuard Konfig eingestellt ist. Trotzdem kann ich meinen Server nicht unter 4G erreichen. Parallel habe ich WireGuard auch unter Windows auf dem Laptop laufen. jetzt baue ich zwar die Verbindung zum Internet mit dem Android Handy auf, aber auch hier zeigt sich das gleiche Problem. Bei Netzten unter 4G+ gibt es keine Verbindung zum Webinterface des Hosts. Der Ping geht durch; Forward auf das WireGuard Interface ist vorhanden. Den Port habe ich noch nicht gewechselt. Provider ist Congstar.
Arbeitest du mit Interface Listen auf dem MT??
Wenn ja ist dort meistens der Management Zugriff über die Liste "WAN" verboten. Das bedeutet dann das man via WAN (und damit ist auch der VPN Tunnel gemeint) nicht per WinBox oder WebGUI auf den MT zugreifen kann. Das musst du entsprechend anpassen. Nur das du das auf dem Radar hast...
Kannst du denn zu mindestens alle anderen Endgeräte in deinem lokalen LAN via VPN erreichen? Sprich arbeitet grundsätzlich das WG VPN?
P.S.: Thema 2mal Moin... 🤣
Wenn ja ist dort meistens der Management Zugriff über die Liste "WAN" verboten. Das bedeutet dann das man via WAN (und damit ist auch der VPN Tunnel gemeint) nicht per WinBox oder WebGUI auf den MT zugreifen kann. Das musst du entsprechend anpassen. Nur das du das auf dem Radar hast...
Kannst du denn zu mindestens alle anderen Endgeräte in deinem lokalen LAN via VPN erreichen? Sprich arbeitet grundsätzlich das WG VPN?
P.S.: Thema 2mal Moin... 🤣
Moinsen,
ich arbeite tatsächlich mit Interfacelisten und habe jetzt das WAN mal zugelassen. Aber noch einmal: Wieso funktioniert das alles bei >=4G+. Wäre es ein Konfigurationsfehler in dem VPN, dann würde es doch grundsätzlich nicht funzen, oder?
Es grüßt der Sabbelkopp!
ich arbeite tatsächlich mit Interfacelisten und habe jetzt das WAN mal zugelassen. Aber noch einmal: Wieso funktioniert das alles bei >=4G+. Wäre es ein Konfigurationsfehler in dem VPN, dann würde es doch grundsätzlich nicht funzen, oder?
Es grüßt der Sabbelkopp!
Da es hier seit Jahren einwandfrei auch über Mobilfunk funktioniert ist entweder dein VPN-Setup fehlerhaft, deine Gegenstelle im LAN oder dein Provider auf dem spez. Port.
"Funzen" 🤮 och Mensch wenn ich das schon hör, einfach nen Wireshark Trace am Device und am Ziel machen und die Developer Tools am Browser öffnen und den Traffic beobachten und die Sache ist gegessen .
dann würde es doch grundsätzlich nicht funzen, oder?
Ist nicht gesagt."Funzen" 🤮 och Mensch wenn ich das schon hör, einfach nen Wireshark Trace am Device und am Ziel machen und die Developer Tools am Browser öffnen und den Traffic beobachten und die Sache ist gegessen .
ich habe die MTU jetzt von meinem Android mit dem Tool Ping&Net ermittelt. Sie liegt bei 1320.
Das ist aber eher ungewöhnlich und ziemlich wenig, habe hier Testweise selbst beim Billigheimer O2 bzw. AldiTalk volle 1420...und MSS 1392 (8byte ICMP und 20 byte IPv4 header).1
Mohooin,
ich habe jetzt noch einmal mit Ports und MTU herumgespielt. Portänderungen bewirken nichts. Sobald ich die MTU auf 1420 ändere, geht nichts mehr!
Aber ich glaube, ich habe im congstar Forum in Bezug auf WireGuard etwas gefunden:
das sieht vielversprechend aus. Auch mit MTU 1420. Gefühlt geht der Seitenaufbau auch deutlich schneller als vorher.
Morgen ist Vatertag angesagt, da bin ich viel unterwegs. Schauen wir mal, ob das VPN dann endlich einmal zuverlässig klappt!
ich habe jetzt noch einmal mit Ports und MTU herumgespielt. Portänderungen bewirken nichts. Sobald ich die MTU auf 1420 ändere, geht nichts mehr!
Aber ich glaube, ich habe im congstar Forum in Bezug auf WireGuard etwas gefunden:
das sieht vielversprechend aus. Auch mit MTU 1420. Gefühlt geht der Seitenaufbau auch deutlich schneller als vorher.
Morgen ist Vatertag angesagt, da bin ich viel unterwegs. Schauen wir mal, ob das VPN dann endlich einmal zuverlässig klappt!
Zitat von @Spartacus:
Mohooin,
ich habe jetzt noch einmal mit Ports und MTU herumgespielt. Portänderungen bewirken nichts. Sobald ich die MTU auf 1420 ändere, geht nichts mehr!
Aber ich glaube, ich habe im congstar Forum in Bezug auf WireGuard etwas gefunden:
das sieht vielversprechend aus. Auch mit MTU 1420. Gefühlt geht der Seitenaufbau auch deutlich schneller als vorher.
Morgen ist Vatertag angesagt, da bin ich viel unterwegs. Schauen wir mal, ob das VPN dann endlich einmal zuverlässig klappt!
Mohooin,
ich habe jetzt noch einmal mit Ports und MTU herumgespielt. Portänderungen bewirken nichts. Sobald ich die MTU auf 1420 ändere, geht nichts mehr!
Aber ich glaube, ich habe im congstar Forum in Bezug auf WireGuard etwas gefunden:
das sieht vielversprechend aus. Auch mit MTU 1420. Gefühlt geht der Seitenaufbau auch deutlich schneller als vorher.
Morgen ist Vatertag angesagt, da bin ich viel unterwegs. Schauen wir mal, ob das VPN dann endlich einmal zuverlässig klappt!
Dann erklärt sich das natürlich, bei dem APN versaut dir NAT64 die MTU und IPv4 wird über IPv6 only getunnelt ...
https://telekomhilft.telekom.de/conversations/telekom-hilft-news/neuer-i ...
Der Todestoß für die Performance...
1
Tach auch!
ich wollte noch einmal Rückmeldung geben. Das Problem ist gelöst und die Performance nun mega! Es lag tatsächlich am APN. Muss man erst einmal drauf kommen.
Ich markiere den Beitrag nun als "gelöst"!
Schönen Sonntag,
Spartacus
ich wollte noch einmal Rückmeldung geben. Das Problem ist gelöst und die Performance nun mega! Es lag tatsächlich am APN. Muss man erst einmal drauf kommen.
Ich markiere den Beitrag nun als "gelöst"!
Schönen Sonntag,
Spartacus
1
Just for Info... Oftmals ist ein APN Wechsel beim Provider automatisch mit höheren Kosten verbunden sofern der Vertrag auf einen "Surf only" APN mit CG-NAT gemappt ist. Du verwurstest damit eine der festen IPv4 Adressen des Providers was in Zeiten leerer IPv4 Pools oftmals kostenpflichtig ist, da diese den besser bezahlten Business Tarifen vorbehalten sind. Das solltest du ggf. zur eigenen Sicherheit nochmal checken um am Monatsende keine böse Überraschung im Portemonaie zu erleben.
