4
Routing Probleme - Wireguard
Hallo,
ich versuche nun schon seit ein paar Tagen folgendes zum laufen zu bekommen. Allerdings finde ich mein Problem einfach nicht.
Zur Ausgangslage:
auf der linken Seite läuft ein Raspberry Pi und rechts eine Debian 10 VM der Tunnel läuft stabil und ich kann von den Gateways selbst auch ins jeweils andere Netz zugreifen.
Von der Linken Seite kann ich auch Problemlos auf das andere Netz zugreifen. Hier läuft alles wie erwartet.
Mein Problem ist allerdings die rechte Seite. Hier hab ich ganz merkwürdiges Verhalten. Wenn ich kann von einem Client aus dem Netzwerk alles auf der anderen Seite anpingen. Das funktioniert ohne Probleme allerdings kann ich keine TCP Ressourcen erreichen also HTTP/HTTPS Seiten. Das komische ist das es manchmal einfach funktioniert für ein paar Minuten und dann gehts wieder nicht mehr.
Ich weis mometan nicht mehr so recht weas das noch sein könnte evtl könnt ihr mir ja noch eine Idee liefern was das Problem sein könnte.
ich versuche nun schon seit ein paar Tagen folgendes zum laufen zu bekommen. Allerdings finde ich mein Problem einfach nicht.
Zur Ausgangslage:
auf der linken Seite läuft ein Raspberry Pi und rechts eine Debian 10 VM der Tunnel läuft stabil und ich kann von den Gateways selbst auch ins jeweils andere Netz zugreifen.
Von der Linken Seite kann ich auch Problemlos auf das andere Netz zugreifen. Hier läuft alles wie erwartet.
Mein Problem ist allerdings die rechte Seite. Hier hab ich ganz merkwürdiges Verhalten. Wenn ich kann von einem Client aus dem Netzwerk alles auf der anderen Seite anpingen. Das funktioniert ohne Probleme allerdings kann ich keine TCP Ressourcen erreichen also HTTP/HTTPS Seiten. Das komische ist das es manchmal einfach funktioniert für ein paar Minuten und dann gehts wieder nicht mehr.
Ich weis mometan nicht mehr so recht weas das noch sein könnte evtl könnt ihr mir ja noch eine Idee liefern was das Problem sein könnte.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665407
Url: https://administrator.de/contentid/665407
Ausgedruckt am: 22.11.2024 um 11:11 Uhr
4 Kommentare
Neuester Kommentar
Kontrolliere mal die MTU und konfiguriere notfalls über die Firewall-Regeln "MSS-Clamping".
Das Verhalten, was du beschreibst, klingt verdächtig nach "zu große Pakete versuchen durch den Tunnel zu kommen, der die Größe nicht transportieren kann".
Das Verhalten, was du beschreibst, klingt verdächtig nach "zu große Pakete versuchen durch den Tunnel zu kommen, der die Größe nicht transportieren kann".
Hi,
ich denke die richtig passt. Allerdings hab ich mit MTU Einstellungen noch nie groß was zu tun gehabt. Bis heute lief immer alles im Default problemlos.
Ich hab nun mal auf beiden Wireguard Gateways die Konfiguration angepasst:
Ich habe auch schon mit kleineren Werten getestet bis 1280 runter da die Endpoints über IPv6 laufen.
Allerdings kann ich von meinem Client über das Netzwerk immer noch keine Stabile Verbindung herstellen. Ich hab auch mal auf dem Client verschiedene MTUs am Adapter ausprobiert aber bekomm eigentlich keine wirkliche Verbesserung
ich denke die richtig passt. Allerdings hab ich mit MTU Einstellungen noch nie groß was zu tun gehabt. Bis heute lief immer alles im Default problemlos.
Ich hab nun mal auf beiden Wireguard Gateways die Konfiguration angepasst:
[Interface]
Address = 192.168.89.2/24
MTU = 1420
PostUp = iptables -A FORWARD -i %i -m state --state RELATED,ESTABLISHED -j ACCEPT
PostUp = iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuIch habe auch schon mit kleineren Werten getestet bis 1280 runter da die Endpoints über IPv6 laufen.
Allerdings kann ich von meinem Client über das Netzwerk immer noch keine Stabile Verbindung herstellen. Ich hab auch mal auf dem Client verschiedene MTUs am Adapter ausprobiert aber bekomm eigentlich keine wirkliche Verbesserung
Das Problem ist das beidseitige NAT im Tunnel. Das ist überflüssiger Unsinn im internen Netz, denn dort sollte man nie NAT machen. Damit wird auch dein Routing ausgehebelt, denn mit der dann aktiven NAT Firewall ist das immer nur eine Einbahnstraße. Entferne das NAT also vollständig das ist im internen wie bereits gesagt völlig Netz unnötig und auch kontraproduktiv !
Danach wird das auch fehlerlos laufen. Das hiesige Wireguard Tutorial weist ebenfalls darauf hin und beschreibt dir dann alle restlichen ToDos:
Merkzettel: VPN Installation mit Wireguard
Die grundsätzliche Frage die sich ja stellt ist warum du den ganzen, eigentlich überflüssigen Kasperkram mit dem WireGuard eigentlich überhaupt machst ?
Viel sinnvoller und effizienter wäre es ja in deinem o.a. Setup einen IPsec VPN Tunnel direkt zwischen Sophos XG und Mikrotik hEX zu machen und sich den überflüssigen und unnötig Strom- und Performance fressenden Frickelkram mit WG zu sparen.
Ein IPsec Tunnel zw. Sophos und Mikrotik rennt fehlerlos und ohne jegliche Probleme !
Danach wird das auch fehlerlos laufen. Das hiesige Wireguard Tutorial weist ebenfalls darauf hin und beschreibt dir dann alle restlichen ToDos:
Merkzettel: VPN Installation mit Wireguard
Die grundsätzliche Frage die sich ja stellt ist warum du den ganzen, eigentlich überflüssigen Kasperkram mit dem WireGuard eigentlich überhaupt machst ?
Viel sinnvoller und effizienter wäre es ja in deinem o.a. Setup einen IPsec VPN Tunnel direkt zwischen Sophos XG und Mikrotik hEX zu machen und sich den überflüssigen und unnötig Strom- und Performance fressenden Frickelkram mit WG zu sparen.
Ein IPsec Tunnel zw. Sophos und Mikrotik rennt fehlerlos und ohne jegliche Probleme !
Ich konnte das Problem mittlerweile lösen.
IPSEC war leider keine Option, weil ich zwar auf einer Seite IPv6 von Providerseite aus nutzen konnte. Auf der anderen Seite musste ich allerdings auf eine 4to6 Lösung von Hurricane Electric setzen, weil der Provider einfach keine IPv6 bereitstellt. Dort wird allerdings IPSEC Traffic komplett rausgefilteret.
Die Lösung war am Ende eigentlich recht simple. Die beiden Endpunkte durften kein Interface in dem zu routenden Netzwerk haben. Mir ist irgendwann aufgefallen das Pakete zwar immer ankommen aber nie zurück. Also wenn ich von Netz A eine Ping an ein Gerät in Netz B gesendet habe, wurde das dann über Firewall -> VPN Gateway -> Netz B gesendet aber zurück kamen die Pakete dann über VPN Gateway -> Netz A.
Ich habe nun also für jeden Standort eine neues Subnetz angelegt in dem das VPN Gateway und die Firewall ein Interface haben, sodass nun alle Pakete auf hin und Rückweg immer über die Firewall laufen müssen. Seit dem funktioniert alles wie gewollt.
Evtl. hätte ich das auch anders lösen können allerdings bin ich auf keine andere Lösung gekommen. Falls ihr also noch eine Idee habt wie man das eleganter lösen könnte dann immer her da mit.
IPSEC war leider keine Option, weil ich zwar auf einer Seite IPv6 von Providerseite aus nutzen konnte. Auf der anderen Seite musste ich allerdings auf eine 4to6 Lösung von Hurricane Electric setzen, weil der Provider einfach keine IPv6 bereitstellt. Dort wird allerdings IPSEC Traffic komplett rausgefilteret.
Die Lösung war am Ende eigentlich recht simple. Die beiden Endpunkte durften kein Interface in dem zu routenden Netzwerk haben. Mir ist irgendwann aufgefallen das Pakete zwar immer ankommen aber nie zurück. Also wenn ich von Netz A eine Ping an ein Gerät in Netz B gesendet habe, wurde das dann über Firewall -> VPN Gateway -> Netz B gesendet aber zurück kamen die Pakete dann über VPN Gateway -> Netz A.
Ich habe nun also für jeden Standort eine neues Subnetz angelegt in dem das VPN Gateway und die Firewall ein Interface haben, sodass nun alle Pakete auf hin und Rückweg immer über die Firewall laufen müssen. Seit dem funktioniert alles wie gewollt.
Evtl. hätte ich das auch anders lösen können allerdings bin ich auf keine andere Lösung gekommen. Falls ihr also noch eine Idee habt wie man das eleganter lösen könnte dann immer her da mit.
