14.03.2024, aktualisiert um 16:06:12 Uhr

2225

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:

/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:

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 31176643894

Url: https://administrator.de/forum/miktrotik-und-wireguard-lan-connection-31176643894.html

Ausgedruckt am: 22.12.2024 um 08:12 Uhr

42 Kommentare

Neuester Kommentar

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

hm, verstehe ich noch nicht ganz, was sollte denn da jetzt in meinem fall rein?
Wie Du oben in meinem Nachtrag siehst, würde eine Route automatisch eingetragen. Was ist daran nicht korrekt?

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

naja auf dem Android steht da nicht sehr viel:

Endpunkt ist die WAN-IP vom MT
und auf dem MT sieht es so aus.

und wie gesagt, diese Route habe ich nicht gesetzt. Das ist automatisch passiert:

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

AllowedIPs = 192.168.100.1/32,172.16.50.0/24

Gruß pp.

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...

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.
Blöde Frage:
Muss ich den Traffic nicht auch bidirektional zulassen, also zwischen dem wiregard interface und dem entsprechenden VLAN und umgekehrt?

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.

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.
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.

Zitat von @aqui:

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...

...auf solche Kleinigkeiten achte ich nicht, bin Grobmotoriker

Spaß bei Seite, danke für den Hinweis, das habe ich übersehen! Komischerweise geht es jetzt, ich musste natürlich in den Zugrifflisten auf die Smart-Homeserver noch die 192.168.100.2 hinzufügen. Wenn mein Handy im lokalen LAN ist, hat es ja logischerweise eine andere "intern" IP als über Wireguard. Ich habe das WireGuard Interface zur Interface-List "LAN" hinzugefügt. Dann ziehen alle meine anderen FW-Regeln, die ich dort definiert habe. Das will ich so aber nicht lassen, muss ich separieren, damit ich die externen Zugriffe besser reglementieren kann. Das war auch jetzt nur erst einmal ein Test.

Wenn ich jetzt zwei MTs koppeln will, dann läuft das doch genau so und ich baue das quasi mit einem zusätlchen Wireguard interface auf um dann die jeweils entfernten Subnetzte zu erreichen, oder )

und btw: Die Route wird tatsächlich automatisch gesetzt.

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

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

ja, man sagte mir, dass das Wireguard-Protokoll recht flott sein soll! Aber wenn das in Punkto Performance nichts ausmacht, sind Bordmittel immer besser. Ist das so, dass das ähnlich flott läuft?

..ikke schon wieder,
versuche das L2TP mal einzurichten und den ersten Satz verstehe ich schon nicht..

ich habe ein VLAN Setup und in der Bridge gibt es diese ARP Einstellung.

wo soll ich arp jetzt aktivieren?

Ich habe alles in VLANs organisiert. Daher ist mir nicht klar, welchen IP Adresskreis ich für L2TP anlegen soll, legt man da ein eigenens VLAN mit eigenem Subnetz an um es dann zu routen?
Danke!

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..

Zitat von @aqui:

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..

Daher ist mir nicht klar, welchen IP Adresskreis ich für L2TP anlegen soll,

aqui, ich bin doch kein Netzwerker und habe den Stoff nicht mit der Muttermilch aufgesaugt, so wie Du! Ich bin DAU und muss mich durchwurschteln und außerdem war das ja mit WG ja nur ein Test, ohne tiefer einzusteigen. Ich schaue mal, ob ich das L2TP and Fliegen kriegen, aber wenn ich da jetzt drangehe, soll das folgende UseCases abbilden:

Einwahl ins Netzwerk vom Android-Handy
Einwahl ins Netzwerk vom Win-PC
Site-to-Site zwischen zwei MT Routern.

Und die L2TP Sache ist schon etwas anders. Bei WG hast Du ein Interface, welches Du den Adressraum zuweist, bei diesem L2TP ist mir das gerade nicht klar, in welchem Schritt das Subnetz an den Adapter gebunden wird... Ich sehe da einen Unterschied.

Nachtrag:
ich komme mit der Anleitung absolut nicht klar, da ich nicht weiß, welche Adressen ich nehmen muss.

Ich habe folgende Subnetzte als VLANS, die intern verfügbar sind.

VLAN10: 172.16.10.0
VLAN20: 172.16.20.0
VLAN40: 172.16.40.0
VLAN50: 172.16.50.0
...
VLAN80: 172.16.80.0
baue ich jetzt ein neues VLAN80 für mein VPN Verbindung und ist dann das GW (172.16.80.1) die lokale Adresse

2024-03-15 12_00_19-scheitern am ipsec vpn mit mikrotik - administrator und 2 weitere seiten - persö

und die Remote Adresse dann eine aus dem Addresspool des VLAN80, was der externe Client dann bekommt?

ich raffe es noch nicht.

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...

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 klar

Bei 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?? 😉

ok,
das war dann wohl ein Schuss in den Ofen!

2024-03-15 12_47_52-l2tp_ipsec psk - samsung community und 5 weitere seiten - persönlich – microsoft

Andere Empfehlung?
Spartacus

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.

..ich habe etwas gegoogelt und mit IKE2 und Android 13 hat das nicht wirklich jemand ans laufen bekommen. Ich denke, ich bleibe bei meinem WG. Das läuft und man kann damit auch die Site-to-Site Sache abdecken.

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!

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.

ich kann nur noch das unter dem VPN-Menü auswählen und ich habe Android 13.

whatsapp bild 2024-03-15 um 13.40.43_3a07c730

ich habe nicht falsch gegoogelt, es gibt unter Android mit Bordmitteln kein IKEv1 mehr.
Das Ziel ist einen VPN Tunnel aufzubauen und das möglichst mit Bordmitteln.

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...

externen VPN Apps ala WG oder OVPN.
Wieder mal ein Grund von Android speziell Samsung die Finger zu lassen...

...einen Tod muss man sterben! Und wenn ich dann auch noch Windows 11 connecten will, ja dann geht IKEv2 auch nicht mit Bordmitteln. Ich frickel dann lieber mit Wireguard. Das klappt dann mit allen 3 Varianten

Windows
Android
Site-to-Site

und aqui, es ist kein Samsung-Problem, sondern eine bewusste Entscheidung von Google!

siehe u.a. hier und hier

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 🐟 🤣.

ist ja auch egal.IKEv2 kommt nicht in Frage! Irgendwo stand, dass es mit Windows Bordmitteln nicht geht.

Ich konzertiere mich jetzt lieber auf das Wireguard Protokoll. Über Android läuft das jetzt auch zuverlässig, aber unter Windows kriege ich das nicht hin. Selbst mit dem gleichen importierten Profil, was ich unter Android angelegt habe.

Was kann das sein?
Der Windows Kollege verbindet sich mit dem Hotspot des Handys. Und dann baue ich den Tunnel via Wireguard auf. Aber ich kann weder das Gateway pingen, noch lässt sich der Vogel vom MT anpingen (Firewall ist aus).

Muss man da unter Windows noch mehr machen als den WireGuard Clienten starten?

...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.

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

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.

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. 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.

Hat da jemand Erfahrungen damit? LTE ist schwierig bei uns obwohl wir nicht auf dem Land leben! War vor ein paar Jahren mal am Polarkreis, da ist LTE in voller Pracht zu empfangen! In Punkto schnelles Internet ist Deutschland offenbar noch ein Entwicklungsland.

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.

BTW:
ich habe mit der Lösung über 4G massive Probleme.

Welches VPN denn?
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.

...mit MTU habe ich noch nicht rumgespielt, das ist überall DEFAULT

meinst Du das bringt etwas es auf dem Wireguard Interface anzupassen

Wireshark bin ich zu dusselig dazu!

MTU 1200 läuft mit 4G perfekt. Ich habe fast den Eindruck, dass es schneller ist als im lokalen LAN

Zitat von @Spartacus:

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.

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...

..ich raff das alles nicht so richtig.

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.

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. Wie stellt man das denn richtig ein, wenn man keinen Wireshark nutzen kann

Zitat von @Spartacus:

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...

Mittels Termux kannst du alles wie unter Linux nutzen, auch das allseits bekannte 'ping' Kommando.

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 Windows

ping -f -l 1472 x.x.x.x

Test analog zu Windows mittels Linux

ping -4 -s 1472 -M do x.x.x.x

Und dann sollte dir die PMTU Ermittlung die Maximalgröße ohne Fragmentierung zeigen, wenn ICMP nicht deaktiviert wurde, ansonsten mit der Größe der Nutzlast nach unten tasten bis die Pakete ohne Fragmentierung durch gehen.

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!

danke für den Hinweis, Heute bin ich durch, morgen werde ich einmal die Einstellungen kontrollieren. Ich habe ping- f unter Win ausgeführt, aber icmp habe ich nicht gesehen,..

bis morgen und danke für den Support!

Zitat von @puderpader:

Dazu muss der DNS Search Suffix entsprechend in der WG Config unter "DNS" gesetzt sein

DNS = x.x.x.x, mydomain.internal, myotherdomain.de

Moin,

musste krankheitsbedingt ne Pause einlegen, aber nun bin ich wieder am Start. Ich habe immer noch ein Problem mit der Namensauflösung der Server. Das Konstrukt funktioniert offenbar nur, wenn man den gesamten Traffic durch den Tunnel schiebt. Ich würde hier aber gerne splitting Tunnel machen um zumindest den Internetverkehr nicht auch noch durch den Tunnel zu schicken. Sobald ich aber die Netze einschränke, läuft die Auflösung der Namen nicht mehr (unter Windows)

Funktioniert:

[Interface]
PrivateKey = geheim
Address = 192.168.100.2/32
DNS = 192.168.100.1, home.domain.de
MTU = 1320

[Peer]
PublicKey = geheim
AllowedIPs = 0.0.0.0/0
Endpoint = x.x.x.x:4711
PersistentKeepalive = 30

Funktioniert nicht:

[Interface]
PrivateKey = geheim
Address = 192.168.100.2/32
DNS = 192.168.100.1, home.domain.de
MTU = 1320

[Peer]
PublicKey = geheim
AllowedIPs = 192.168.1.0/24, 172.16.10.0/24, 172.16.20.0/24
Endpoint = x.x.x.x:4711
PersistentKeepalive = 30

per IP klappt es, per FQDN oder Name nicht.

Hatte das hiergefunden, aber auch das läuft so nicht.

hat das jemand mit Wireguard und Splitting Tunnel am Laufen?

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

Alles was über den Tunnel gehen soll muss auch in die AllowedIPs, auch das Tunnelnetz oder alternativ nur das WG Gateway mit 32er Maske, je nachdem was der Client über den Tunnel erreichen können soll. Das ist Grundvorraussetzung für das Cryptokey Routing 😁.

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. 😉

Moin, Moin,

vielen Dank für den Hinweis und aqui, das Tut kannte ich noch gar nicht! Hätte ich das mal eher gefunden, hätte ich mir viel Arbeit ersparen können.

Danke euch!
Spartacus