Wireguard S2S Tunnel von MikroTik zu GLiNet

Hallo Zusammen,

ich stehe wiedermal auf dem Schlauch.

Ich habe mein Netz mit einem anderen Netz via Wireguard verbunden.
Sowohl Wireguard Server als auch Client stehen jeweils hinter einer Fritzbox.

Hier mal ein grobes Bild, ich habe mich nach Wireguard Site2Site mit Roadwarrior gerichtet:

Nun zum Problem:
Ich habe hinter meinem Mikrotik ein VLAN (Netz 10.83.70.0/24), von diesem aus möchte ich die Gegenseite erreichen.
Das funktioniert so aber nicht, s. hier:

Vom MT direkt:

ping 192.168.1.2 
  SEQ HOST                                     SIZE TTL TIME       STATUS                                                                                  
    0 192.168.1.2                                56  64 41ms56us  

 ping 192.168.1.2 src-address=10.83.70.1
  SEQ HOST                                     SIZE TTL TIME       STATUS                                                                                  
    0 192.168.1.2                                                  timeout

Auch vom Client in dem Netz mit IP 10.83.70.5 geht es nicht.
Die Pings vom MT auf die 3.4 (seine WG IP) und auf die 3.1 (WG IP vom GLiNet) funktionieren auch.
Sprich vom MT direkt erreiche ich die Gegenseite und sogar das Netz (was WAN-seitig liegt) auch.
Nur nicht von meinem 70er Netz.

Vom GLiNet aus erreiche ich die 3.4 ohne Probleme, der Ping geht durch.
Wenn ich von dort aber zum 10.83.70.5 will kommen Timeouts.

NAT ist auf beiden Geräten (MT / GLiNet) abgeschalten.

Wenn die allerdings am MT den Tunnel abschalte und an meinem Client (z.B. im 10.83.30.0/24) via Windows WG Client den Tunnel starte funktioniert es ohne Probleme. Dann habe ich auch das Verhalten wie vom MT direkt aus.

Mir ist zumindest noch aufgefallen dass der WG-Server am GLiNet irgendwie komisch ist.
Sollte da nicht eine Route auf Basis der Allowed-IPs zur Gegenseite sein?
Sprich ein Eintrag zum 10.83.70.0/24?

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.10    0.0.0.0         UG    10     0        0 eth0
192.168.1.0     *               255.255.255.0   U     10     0        0 eth0
192.168.3.0     *               255.255.255.0   U     0      0        0 wgserver
192.168.8.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.9.0     *               255.255.255.0   U     0      0        0 br-guest

Was habe ich übersehen damit es vom 70er Netz auch funktioniert?
Habt ihr einen Tipp?

Hinweis:
Als bisherige Lösung bzw. "Backup" kann der Mikrotik noch einen IPSec-Tunnel zur FBox der Gegenseite aufbauen.
Ich kann dort im Notfall auch schnell hinlaufen.

Danke schonmal im Voraus!

Please also mark the comments that contributed to the solution of the article

Content-Key: 4725958243

Url: https://administrator.de/contentid/4725958243

Printed on: July 27, 2024 at 14:07 o'clock

6 Comments

Latest comment

Servus,

Check mal deine AllowedIPs auf beiden Seiten!

LG

Zitat von @Epixc0re:

Servus,

Check mal deine AllowedIPs auf beiden Seiten!

LG

Guter Hinweis, manchmal sieht man den Wald vor lauter Bäumen nicht.
Lt. UI sind die korrekt eingetragen, via SSH sieht es anders aus:

peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  endpoint: XXXXXX:14780
  allowed ips: 192.168.3.4/32
  latest handshake: 11 seconds ago
  transfer: 732.84 KiB received, 4.66 MiB sent
  persistent keepalive: every 25 seconds
...

Habe gerade via SSH die Allowed-IPs auf die 3.4 und das 70er-Netz gesetzt und eine statische Route eingetragen, jetzt funktioniert es auch.
Ich schäme mich schon

Ist das Absicht bei GLiNet? Wie löse ich das dauerhaft? Die Route hab ich im LuCI auch eingetragen, die wird aber nicht übernommen! Nur per SSH funktioniert es.

Update: Die Route hab ich gelöst bekommen, die habe ich in der normalen UI unter VPN eingetragen. Die steht jetzt in der Datei /etc/config/wireguard_server und wird übernommen. Jetzt ist nur noch die Frage was sein Problem mit den Allowed-IPs ist.

Du gehst per PuTTY etc. über den SSH Shell Zugang auf den GL.inet und passt dort manuell die wg0.conf Datei an.
Siehe dazu auch das hiesige WG Tutorial:
Merkzettel: VPN Installation mit Wireguard

Zitat von @aqui:

Du gehst per PuTTY etc. über den SSH Shell Zugang auf den GL.inet und passt dort manuell die wg0.conf Datei an.
Siehe dazu auch das hiesige WG Tutorial:
Merkzettel: VPN Installation mit Wireguard

Hallo aqui,

ich konnte zwischenzeitlich nachforschen.
Im Script /etc/init.d/gl_s2s wird das aus meiner Sicht erfasst, die Methode "wireguard_setup_peer" enthält u.a.

for allowed_ip in ${allowed_ips}; do
    echo "AllowedIPs = ${allowed_ip}" >> "${wg_cfg}"  
done

Das landet dann in der Datei "/tmp/wireguard/wgserver.conf"

Die Quelle der Daten ist "/etc/config/wireguad_server", dort steht:

option allowed_ips '192.168.3.4/32,10.83.70.0/24'

Ich bin kein Shell-Experte, aber dann passt doch der Code nicht?
Das hört sich alles so nach Bug an, allerdings bin ich auf v4.1 und das Verhalten ist leider so wie festgestellt.

D.h. für mich solange der GL.inet nicht angefasst wird durch Änderungen, Updates usw. kann ich es ja in der Datei ändern. Oder via wg-CLI durch ein Startscript einfügen.

Falls es niemand anders sieht hake ich das als GL.inet-Problem ab. Oder sehe ich das falsch?

aber dann passt doch der Code nicht?

Da hast du recht! Das Setup berücksichtigt dann lediglich einen VPN Client Access aber keine Site-to-Site Kopplung, denn dafür müsste dort natürlich zwingend auch das remote Netz unter den allowed IPs stehen. Siehe Wireguard Tutorial.
Vermutlich wärst du mit einem kleinen Mikrotik hAP lite Router oder einem schlichten Raspberry Pi als WG VPN Hardware deutlich besser gefahren?!

OK, dann wird das Teil als WG-Server rausfliegen und als Roadwarrior eingesetzt.
Danke an alle für die Hilfe, das urspr. Problem ist ja nun definitiv gelöst!

German solved Question MikroTik Routers, Routing