Miktrotik und Wireguard LAN Connection
Moin zusammen,
ich versuche verzweifelt eine Verbindung mit einem Android Client per Wireguard zu einem internen Subnetz aufzubauen.
Die Verbindung besteht, aber leider klappt das Routing nicht und auch ein Ping-Test vom MT schlägt fehl.
ich habe folgende FW-Rules erstellt:
wobei
Das Subnetz für das wireguard1 Interface ist 192.168.100.0/24
Der Android Client hat 192.168.100.2
Die Smarthome-Server liegen im 172.16.50.0/24 Subnetz
Was habe ich nicht bedacht? Warum werden die Pakete nicht groutet?
P.S:
Route ist auch gesetzt:
ich versuche verzweifelt eine Verbindung mit einem Android Client per Wireguard zu einem internen Subnetz aufzubauen.
Die Verbindung besteht, aber leider klappt das Routing nicht und auch ein Ping-Test vom MT schlägt fehl.
ich habe folgende FW-Rules erstellt:
/ip firewall filter
add action=accept chain=input comment="accept established,related" connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid" connection-state=invalid
add action=accept chain=input comment="allow WireGuard traffic" dst-port=13231 protocol=udp
.....
add action=accept chain=forward comment="WG to LAN" dst-address-list= SmartHome in-interface=wireguard1
......
wobei
- wireguard1 ->wireguard interface ist
- dst-address-list=SmartHome ->eine Liste mit den Servern ist, die erreicht werden sollen.
Das Subnetz für das wireguard1 Interface ist 192.168.100.0/24
Der Android Client hat 192.168.100.2
Die Smarthome-Server liegen im 172.16.50.0/24 Subnetz
Was habe ich nicht bedacht? Warum werden die Pakete nicht groutet?
P.S:
Route ist auch gesetzt:
Please also mark the comments that contributed to the solution of the article
Content-ID: 31176643894
Url: https://administrator.de/contentid/31176643894
Printed on: December 4, 2024 at 06:12 o'clock
42 Comments
Latest comment
Du hast vermutlich, wie leider häufig, den Hinweis im MT Wireguard Manual übersehen das das Cryptokey Routing im Mikrotik nicht dynamisch passiert sondern das Routing explizit mit einer statischen Route eingetragen werden muss. Ist u.a. bei der pfSense auch so.
Guckst du hier:
Mikrotik als Wireguard Server
Wireguard mit Mikrotik und pfSense
Guckst du hier:
Mikrotik als Wireguard Server
Wireguard mit Mikrotik und pfSense
Mikrotik kann keine Routen automatisch eintragen...aber du hast in deinem Falle Recht bei einem reinen VPN Client Zugang wie deinem ist das nicht relevant sondern gilt nur für ein Lan zu Lan VPN.
Vielleicht wäre deine WG Client Konfig Datei hilfreich denn die bestimmt massgeblich was wie wohingeht. Die dazu nötigen ToDos findest du auch, wie immer, im Wireguard Tutorial:
Merkzettel: VPN Installation mit Wireguard
Vielleicht wäre deine WG Client Konfig Datei hilfreich denn die bestimmt massgeblich was wie wohingeht. Die dazu nötigen ToDos findest du auch, wie immer, im Wireguard Tutorial:
Merkzettel: VPN Installation mit Wireguard
Ja nee da wird wohl n' Kaffee fällig, der Fehler sind die AllowedIPs auf dem Android, da muss
0.0.0.0/0 stehen nicht 0.0.0.0/32
Wenn du den gesamten IPv4 Traffic über den Tunnel jagen willst
Wenn als Split Tunnel gewünscht gehört da auf dem Androiden das rein
Gruß pp.
0.0.0.0/0 stehen nicht 0.0.0.0/32
Wenn du den gesamten IPv4 Traffic über den Tunnel jagen willst
Wenn als Split Tunnel gewünscht gehört da auf dem Androiden das rein
AllowedIPs = 192.168.100.1/32,172.16.50.0/24
Die übliche RTFM Leier: WG Tutorial nicht gelesen was explizit auf die Subnet Masken (besonders die in den AllowedIPs) und den Unterschied Gateway Redirect und Split Tunneling eingeht!! 😡
Finde den Fehler...
Finde den Fehler...
Zitat von @Spartacus:
Hi aqui,
das war schon mal ein guter Tipp! Zumindest läuft der Ping jetzt vom MT Ping-Tool aus. aber auf den server aus dem 172.16.50.0/24 Netzt komme ich immer noch nicht.
Hi aqui,
das war schon mal ein guter Tipp! Zumindest läuft der Ping jetzt vom MT Ping-Tool aus. aber auf den server aus dem 172.16.50.0/24 Netzt komme ich immer noch nicht.
Firewall auf dem Server checken Winblows lässt ICMP und SMB per Default nur aus dem selben Subnetz zu, das musst du also erst frei schalten!
Blöde Frage:
Muss ich den Traffic nicht auch bidirektional zulassen, also zwischen dem wiregard interface und dem entsprechenden VLAN und umgekehrt?
Nein, bei einer Statefull Firewall wie du sie betreibst nicht, wenn du den Traffic vom Android aus iniziierst, denn dann existiert ja ein Connection Tracking Eintrag in der Firewall der den Rücktraffic automatisch durchlässt.Muss ich den Traffic nicht auch bidirektional zulassen, also zwischen dem wiregard interface und dem entsprechenden VLAN und umgekehrt?
Außer du iniziierst den Traffic vom Server aus auf den Android, dann musst du die Forward-Chain auch für den Server Richtung WG Netz frei schalten!
Für das lokale LAN (172.....) sollte der MK auch das Default GW sein. Wenn nicht musst du dem anderen def GW die Route zum WG Netz mitteilen.
Zumindest läuft der Ping jetzt vom MT Ping-Tool aus
Ping doch mal vom Smartphone dann hast du auch die andere Seite. Die HE.NET Tools sind dazu immer dein bester Freund!https://play.google.com/store/apps/details?id=net.he.networktools&hl ...
Die Route wird tatsächlich automatisch gesetzt.
Nope, nicht bei einer LAN zu LAN Kopplung! Oder es wäre neu in der 7.14.Bei einer reinen Client Kopplung gibt es ja keinerlei Routen die automatisch zu setzen sind, die jibbet nur bei LAN2LAN.
Generell fragt sich warum du nicht einfach den embeddeten L2TP VPN Client nutzt? Erspart dir mit einer externen VPN App rumfrickeln zu müssen. Die internen Clients sind doch viel besser integriert?!
L2TP VPN Server mit Mikrotik
man sagte mir, dass das Wireguard-Protokoll recht flott sein soll!
Nur im Vergleich mit OpenVPN. Mit IPsec ist das egal da gleicher Durchsatz. Guckst du hier. Nie eine gute Idee nach Hörensagen zu gehen... und den ersten Satz verstehe ich schon nicht..
Was ist daran nicht zu verstehen??In der Default Konfig gibt es eine Bridge die die lokalen LAN Interfaces zusammenfasst und eine IP hat.
In eine VLAN Konfig gibt es diese bridge auch aber bekanntlich darf diese im VLAN Setup niemals selber eine IP zugewiesen bekommen. Das ist Tabu und alle MT Tutorial wie auch das hiesige weisen explizit darauf hin. Ohne IP Adresse ist es logischerweise sinnfrei irgendwelche IP Funktionen wie Proxy ARP auf ein Interface zu setzen. Einfache Logik die du als alter Mikrotik Profi doch auch kennst. 😉
Wo muss das "proxy-arp" also hin?? Richtig....auf die VLAN IP Interfaces!!
Daher ist mir nicht klar, welchen IP Adresskreis ich für L2TP anlegen soll,
Komisch...bei Wireguard war dir das auch unklar?? Da hast du ja einfach mir nichts dir nichts die 192.168.100.0/24 für das internen VPN gewählt. Warum war es da für dich klar und jetzt bei L2TP mit dem gleichen Procedere ist dir das unklar? Da kann man dir echt nicht mehr folgen?! 🤔Es ist nur das interne VPN IP Netz. Analog wie bei WG wo es dir ja komischerweise keine Kopfzerbrechen bereitet...
Ich passe aber dennoch die Formulierung im Tutorial etwas an. Danke für den Hinweis..
Das ist ja auch alles ok und verständlich nur warum du dann bei WG alles selbstständig bei L2TP aber nicht obwohl es die gleichen Mechanismen sind bleibt unklar... Aber never mind...
Das ist kinderleicht:
Du nutzt IP Adressen aus dem Netzwerk das du fürs Proxy ARP aktiviert hast. Das sollten natürlichs tunlichst IP Adressen sein die NICHT im Poolbereich des DHCP Servers liegen und NICHT statisch vergeben sind. Logisch, denn die L2TP Clients nutzen IPs dieses Segmentes und da darf sich dann nix überschneiden.
Hier im Tutorial ist der Bereich ab und drüber .200 frei und wird deshalb verwendet.
Dieses Verfahren nutzt eine feste statische Zuweiung von IPs auf L2TP VPN Nutzer. Das hat den großen Vorteil das man Nutzer bezogen Firewall Regeln erstellen kann wenn man bestimmten Nutzern den Zugriff auf Netze oder Endgeräte reglementieren will. Ist ja bei WG nicht anders...
Man muss es aber nicht so machen wenn man z.B. 200 User einrichten will und feste Zuordnungen nicht benötigt könnte das etwas aufwendig werden. Da kann man dann ein Pool Verfahren mit dynamischer IP Verteilung verwenden. Der Link im Tutorial verweist auf diese Lösungs Option.
Fazit:
Bei statischer Zuweisung der Nutzer IPs im Nutzer Setup (das ist die Remote Adress) wird KEIN Pool verwendet.
Im obigen L2TP Nutzer Setup ist Local Adress immer die lokale IP des Mikrotik in dem Proxy ARP VLAN. Die Remote Adress ist die Adresse die dem L2TP User aus diesem Netz userbezogen fest zugewiesen wird und die sollte dort unbenutzt sein. Der User ist quasi wie ein lokaler Client in dem Netz.
Alles geschnallert?? 😉
Ich schaue mal, ob ich das L2TP and Fliegen kriegen
Ist mit WinBox KlickiBunti in 10 Minuten erledigt. soll das folgende UseCases abbilden:
Dialain machst du mit L2TP das LANzuLAN VPN dann mit native IPsec oder WG oder OpenVPN je nach Geschmackssache. Das der MT alles abdeckt ist klarBei WG hast Du ein Interface, welches Du den Adressraum zuweist
Das hast du doch bei L2TP auch...da ich nicht weiß, welche Adressen ich nehmen muss.
🙄 Du meinst die IP Adresszuweisung für die L2TP Clients, oder??Das ist kinderleicht:
Du nutzt IP Adressen aus dem Netzwerk das du fürs Proxy ARP aktiviert hast. Das sollten natürlichs tunlichst IP Adressen sein die NICHT im Poolbereich des DHCP Servers liegen und NICHT statisch vergeben sind. Logisch, denn die L2TP Clients nutzen IPs dieses Segmentes und da darf sich dann nix überschneiden.
Hier im Tutorial ist der Bereich ab und drüber .200 frei und wird deshalb verwendet.
Dieses Verfahren nutzt eine feste statische Zuweiung von IPs auf L2TP VPN Nutzer. Das hat den großen Vorteil das man Nutzer bezogen Firewall Regeln erstellen kann wenn man bestimmten Nutzern den Zugriff auf Netze oder Endgeräte reglementieren will. Ist ja bei WG nicht anders...
Man muss es aber nicht so machen wenn man z.B. 200 User einrichten will und feste Zuordnungen nicht benötigt könnte das etwas aufwendig werden. Da kann man dann ein Pool Verfahren mit dynamischer IP Verteilung verwenden. Der Link im Tutorial verweist auf diese Lösungs Option.
Fazit:
Bei statischer Zuweisung der Nutzer IPs im Nutzer Setup (das ist die Remote Adress) wird KEIN Pool verwendet.
Im obigen L2TP Nutzer Setup ist Local Adress immer die lokale IP des Mikrotik in dem Proxy ARP VLAN. Die Remote Adress ist die Adresse die dem L2TP User aus diesem Netz userbezogen fest zugewiesen wird und die sollte dort unbenutzt sein. Der User ist quasi wie ein lokaler Client in dem Netz.
Alles geschnallert?? 😉
Ist die Frage ob er damit sein PPTP meint was er draufhatte?? Das haben ja alle removed:
https://www.heise.de/hintergrund/Der-Todesstoss-fuer-PPTP-1701365.html
L2TP ist aber keinesfalls entfernt worden, denn das basiert ja auf dem weltweit genutzten und als sicher etabliertem IPsec. Siehst du ja auch daran das iPhones es über sämtliche Generationen und Modelle integriert haben und Windows um MacOS ebenso in allen neusten OS Versionen.
Ein 1,5 Jahre altes XIAOMI lieferte den Screenshot von oben. Ist also da auch noch integriert. Es ist also davon auszugehen das diese Anmerkung sich auf PPTP bezog und mit L2TP nichts zu tun hat.
https://www.heise.de/hintergrund/Der-Todesstoss-fuer-PPTP-1701365.html
L2TP ist aber keinesfalls entfernt worden, denn das basiert ja auf dem weltweit genutzten und als sicher etabliertem IPsec. Siehst du ja auch daran das iPhones es über sämtliche Generationen und Modelle integriert haben und Windows um MacOS ebenso in allen neusten OS Versionen.
Ein 1,5 Jahre altes XIAOMI lieferte den Screenshot von oben. Ist also da auch noch integriert. Es ist also davon auszugehen das diese Anmerkung sich auf PPTP bezog und mit L2TP nichts zu tun hat.
IKEv2 gibt es bei L2TP auch gar nicht. L2TP nutzt prinzipbedingt immer IKEv1 Ganz andere Baustelle also und falsch gegoogelt...
Das IKEv2 generell schon immer fehler- und problemlos mit Android und auch der neuesten Version als Client VPN läuft siehst du an den millionenfach damit genutzen OPNsense und pfSense Lösungen und auch jedem Linux z.B. Raspberry Pi.
IKEv2 ist die etablierteste Client VPN Lösung bei den onboard Clients.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Mit Mikrotik rennt es auch aber die Einrichtung ist etwas aufwendiger als mit den o.a. Firewalls.
https://mum.mikrotik.com/presentations/MY19/presentation_7008_1560543676 ...
https://mum.mikrotik.com/presentations/CN19/presentation_7073_1571797375 ...
Usw.
Wenn sowas öffentlich auf den großen Mikrotik MUM Konferenzen weltweit vorgestellt wird kann man wohl zu Recht sagen das das was du da "gegoogelt" hast sachlich falsch ist!
Das IKEv2 generell schon immer fehler- und problemlos mit Android und auch der neuesten Version als Client VPN läuft siehst du an den millionenfach damit genutzen OPNsense und pfSense Lösungen und auch jedem Linux z.B. Raspberry Pi.
IKEv2 ist die etablierteste Client VPN Lösung bei den onboard Clients.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Mit Mikrotik rennt es auch aber die Einrichtung ist etwas aufwendiger als mit den o.a. Firewalls.
https://mum.mikrotik.com/presentations/MY19/presentation_7008_1560543676 ...
https://mum.mikrotik.com/presentations/CN19/presentation_7073_1571797375 ...
Usw.
Wenn sowas öffentlich auf den großen Mikrotik MUM Konferenzen weltweit vorgestellt wird kann man wohl zu Recht sagen das das was du da "gegoogelt" hast sachlich falsch ist!
ich kann nur noch das unter dem VPN-Menü auswählen und ich habe Android 13.
Nee, du hast eine Samsung Gurke...das ist wohl das Problem. Mit XIAOMI (und iPhone) wär das nicht passiert. Fazit: Falsche Smartphone Hardware beschafft.
Gut, mit der Gurke hast du dann natürlich keine Chance. Die bleibt dann nur IKEv2 oder eben wieder das Gefrickel mit externen VPN Apps ala WG oder OVPN.
Wieder mal ein Grund von Android speziell Samsung die Finger zu lassen...
Und wenn ich dann auch noch Windows 11 connecten will, ja dann geht IKEv2 auch nicht mit Bordmitteln
Sicher kann Windows 11 IKEv2 out of the box!dann geht IKEv2 auch nicht mit Bordmitteln
Ohne Worte in einem Administrator Forum...aber heute ist ja glücklicherweise Freitag! 🐟Steht ja auch hier und hier explizit in allen Tutorials und selbst direkt bei Microsoft!
Aber Handbücher und Tutorials einmal in aller Ruhe lesen und verstehen wird überbewertet. Ganz besonders natürlich von Grobmotorikern an Freitagen 🐟 🤣.
Zitat von @Spartacus:
...es läuft jetzt, irgendwie hatte sich der MT wohl verschluckt. habe alles gelöscht und neu konfiguriert.
wenn jemand eine Idee hat, wie man den Hostname auflösen kann, ohne den FQDN zu verwenden, lasst es mich wissen. Das kriege ich nicht hin.
Dazu muss der DNS Search Suffix entsprechend in der WG Config unter "DNS" gesetzt sein...es läuft jetzt, irgendwie hatte sich der MT wohl verschluckt. habe alles gelöscht und neu konfiguriert.
wenn jemand eine Idee hat, wie man den Hostname auflösen kann, ohne den FQDN zu verwenden, lasst es mich wissen. Das kriege ich nicht hin.
DNS = x.x.x.x, mydomain.internal, myotherdomain.de
https://rakhesh.com/linux-bsd/wireguard-search-domain/
Aber schon wegen Kerberos würde ich zukünftig nur auf FQDNs setzen, diese single-label-Schei.... fällt einem sonst immer wieder mal auf die Füße.
Zitat von @Spartacus:
Hallo,
vielen Dank für den Hinweis! Ich hatte das mit dem Domain Suffix auch gefunden, da stand allerdings, da stand in dem Beitrag, dass das nicht funktioniert. Ich teste es mal aus.
Klappt hier im Test problemlos. Einfach mit den DNS Mechanismen der OSe vertraut machen dann ist das ein Kinderspiel.Hallo,
vielen Dank für den Hinweis! Ich hatte das mit dem Domain Suffix auch gefunden, da stand allerdings, da stand in dem Beitrag, dass das nicht funktioniert. Ich teste es mal aus.
BTW:
ich habe mit der Lösung über 4G massive Probleme.
Welches VPN denn?ich habe mit der Lösung über 4G massive Probleme.
Hier keinerlei Probleme ob, Wireguard oder IKEv2 works like a charm.
Achtung wenn du IKEv2 nutzt und am Mikrotik FastTrack über die Firewall aktiviert hast musst du IPSec Traffic aus dem Fasttracking ausnehmen denn sonst gibt es o.g. Probleme!
Ich kann zwar alles pingen in meinem Netzwerk, aber http bzw. https geht so gut wir gar nicht. Wenn ich irgendwo eine WLAN-Verbindung habe, klappt das.
Einfach mal den Kabelhai anwerfen, evt. MTU Problem.Zitat von @Spartacus:
MTU 1200 läuft mit 4G perfekt. Ich habe fast den Eindruck, dass es schneller ist als im lokalen LAN
MTU 1200 läuft mit 4G perfekt. Ich habe fast den Eindruck, dass es schneller ist als im lokalen LAN
Dann machst du in deinem LAN aber was richtig falsch 😂.
Der Wireguard-Client auf den meisten Plattformen wählt oft einen sehr konservativen MTU Wert. 1200 ist schon sehr niedrig, auf der Android Plattform sind das meist 1280. Lässt sich aber dort auch in der GUI anpassen.
Ich habe hier mit 1420 per Telefonica LTE keinerlei Fragmentierung über den Tunnel. Wenn du auf IPv6 durch den Tunnel verzichten kannst, geht sogar 1440, da der IPv6 Header 20 bytes größer ist.
Wie immer lässt sich das auf das byte prüfen wenn man mittels Ping und dem 'do not fragment' flag die max mögliche MTU ermittelt.
Denn je kleiner die MTU desto mehr Overhead und weniger Durchsatz hast du per TCP weil mehr ACKs gesendet werden müssen.
Zitat von @Spartacus:
ja, keine Ahnung wie man das sehen kann. Das Ping Tool auf meinem Android bietet das nicht an. Ich kann es ja mal auf 1420 hochdrehen...
Mittels Termux kannst du alles wie unter Linux nutzen, auch das allseits bekannte 'ping' Kommando.Ich habe hier mit 1420 per Telefonica LTE keinerlei Fragmentierung über den Tunnel. Wenn du auf IPv6 durch den Tunnel verzichten kannst, geht sogar 1440, da der IPv6 Header 20 bytes größer ist.
ja, keine Ahnung wie man das sehen kann. Das Ping Tool auf meinem Android bietet das nicht an. Ich kann es ja mal auf 1420 hochdrehen...
Habe jetzt wieder 1420 eingestellt, da geht gar bei mir absolut gar nichts. Es wir keine Seite meiner internen Server geladen. Bin dann auf 1500 gegangen und das ist wieder ok.
Also am LAN Interface änderts du als erstes überhaupt nüscht, Finger weg!!Meine Glaskugel sagt : Du hast vermutlich kein durchgängiges ICMP zwischen den Devices , ohne das funktioniert nämlich die automatische PMTU Ermittlung für die Maximalgröße der Paktete nicht ein Fehler den viele begehen wenn sie IMCP per Firewall auf den beteiligten Devices blockieren oder nur "PING" erlauben, ICMP kennt ja mehrere Nachrichten unter anderem zur Ermittlung der PathMTU.
Aber mal für DAUs. Wie testest man das mit ping -f denn am Besten? Ich kann das ja auch von einem Windows Client machen
Test unter Windowsping -f -l 1472 x.x.x.x
ping -4 -s 1472 -M do x.x.x.x
Bedenke das ICMP selbst 28 Bytes nutzt 20 für den IP Header und 8 für ICMP. Die Größenangabe beim Ping ist hier also nur die Nutzlast ohne IP und ICMP Header!
hat das jemand mit Wireguard und Splitting Tunnel am Laufen?
Ja klappt hier einwandfrei, wieso auch nicht sind halt simpelste Netzwerkgrundlagen die man einhalten muss dann klappt das 100% !
Wenn du einen DNS Server angibst dessen IP-Subnetz du nicht in die AllowedIPs schreibst kein Wunder das es bei dir nicht geht 🙃.
Du hast da statt 192.168.100.0/24 oder alternativ auch 192.168.100.1/32 nämlich 192.168.1.0/24 in deine AllowedIPs reingeschrieben 😉. Steht ja eigentlich auch schon gaaanz oben in meinem Post.
AllowedIPs = 192.168.100.0/24, 172.16.10.0/24, 172.16.20.0/24
Works as designed.
Immer das selbe Theater, man muss den Leuten ab und zu nur mal nen Tritt verpassen, manche lernen halt nicht ohne Schmerzen 🤪
Schönen Rest-Sonntag
Oder auch als Grobmotoriker ausnahmweise am Sonntag wirklich einmal das Tutorial lesen was das Ganze haarklein und auch für Laien verständlich erklärt wie sich das alles mit den AllowedIPs und Split Tunneling verhält. 😉
Bidde Bidde. Dann fehlt ja nur noch der ✅