godlie
Mar 28, 2024, updated at 12:47:09 (UTC)
view1400
view18
0
Goto Top

Wireguard Jumphost Split Tunnel Routingtroubles

GermansolvedQuestionVPNRouters, Routing
Hallo,

ich hadere gerade mit einem Wireguard Setup, 1 Server 2 Hosts 2 Netzwerke welche sich erreichen sollten.

Ich kann mich sauber verbinden, bekomme von den Clients aus auch vom WG Server 10.13.13.1 eine Antwort,
aber sobald ich von der 192.168.0.0 in die 192.168.123.0 oder umgekehrt was pinge bekomme ich nur noch einen timeout.

Ich kann auch vom Server aus die Netzwerke nicht erreichen, also muss wahrscheinlich hier der Hund vergraben sein.

Übersicht:
wgjumphopst

Server wg.conf:
[Interface]
Address = 10.13.13.1/24
ListenPort = 51820
PrivateKey = ----
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth+ -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth+ -j MASQUERADE

[Peer]
# peer_srv
PublicKey = ---
AllowedIPs = 10.13.13.2/32
PersistentKeepalive = 25

[Peer]
# peer_cl1
PublicKey =  ----
AllowedIPs = 10.13.13.3/32, 192.168.123.0/24
PersistentKeepalive = 25

[Peer]
# peer_cl2
PublicKey = ----
AllowedIPs = 10.13.13.4/32, 192.168.0.0/24
PersistentKeepalive = 25

Server IP Route:
default via 192.168.64.1 dev eth0 
10.13.13.0/24 dev wg0 proto kernel scope link src 10.13.13.1 
192.168.0.0/24 dev wg0 scope link 
192.168.64.0/20 dev eth0 proto kernel scope link src 192.168.64.2 
192.168.123.0/24 dev wg0 scope link

ClientConfigs

PL1
config_pl1

PL2
config_pl2

Für mein Verständniss sollte das eig. so passen oder übersehe ich was?

grüße
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 11148167456

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

Printed on: April 27, 2024 at 07:04 o'clock

18 Comments
Latest comment
Goto Top
Member: aqui
aqui Mar 28, 2024 updated at 13:14:10 (UTC)
Goto Top
Wie üblich das überflüssige NAT im VPN Tunnel (iptables). Damit ist kein transparentes Routing über die Netze möglich wegen der NAT Firewall. (Siehe auch WG Tutorial was explizit auf diesen Fehler hinweist!)

Im Mikrotik fehlt der Screenshot mit dem statischen Wireguard Routing Eintrag auf die remoten Netze welcher auch bei dir fehlt und die Verbindung deshalb scheitert! ⚠️ Beachte immer das der Mikrotik kein automatisches Cryptokey Routing supportet!
wgrou

Keepalives in einem WG Server (VPN Responder, Endpoint) sind unsinnig und solltest du entfernen. Sie gehören ausnahmslos immer nur auf die WG Clients (VPN Initiator)!
Member: godlie
godlie Mar 28, 2024 at 13:41:51 (UTC)
Goto Top
Hallo @aqui,

danke erstmla für den Tipp bzgl. dem NAT, müsste es reichen wenn ich aus dem postUp / postDown dies hier entferne?
iptables -t nat -A POSTROUTING -o eth+ -j MASQUERADE 
respektive 
iptables -t nat -D POSTROUTING -o eth+ -j MASQUERADE

Ich hab hier noch die Routing Einträge: was komisch ist, dass das Interface unknown ist, obwohol das wireguard interface up ist
bildschirmfoto 2024-03-28 um 14.34.29
bildschirmfoto 2024-03-28 um 14.34.36

grüße
Mitglied: 12168552861
12168552861 Mar 28, 2024 updated at 14:08:31 (UTC)
Goto Top
Server Config

[Interface]
Address = 10.13.13.1/24
ListenPort = 51820
PrivateKey = ----
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT;

[Peer]
# peer_cl1
PublicKey =  ----
AllowedIPs = 10.13.13.3/32, 192.168.123.0/24

[Peer]
# peer_cl2
PublicKey = ----
AllowedIPs = 10.13.13.4/32, 192.168.0.0/24

Config Client CL1

[Interface]
Address = 10.13.13.3/24
PrivateKey = ----

[Peer]
PublicKey =  ----
AllowedIPs = 10.13.13.0/24, 192.168.123.0/24
Endpoint = 192.168.68.1:51820
PersistentKeepalive = 25

Config Client CL2

[Interface]
Address = 10.13.13.4/24
PrivateKey = ----

[Peer]
PublicKey =  ----
AllowedIPs = 10.13.13.0/24, 192.168.0.0/24
Endpoint = 192.168.68.1:51820
PersistentKeepalive = 25

Für die Routen auf den Clients dann als GW die 10.13.13.1 eintragen, der kennt ja alle anderen Netze dann bereits.
heart1
Member: aqui
Solution aqui Mar 28, 2024 updated at 14:11:10 (UTC)
Goto Top
müsste es reichen wenn ich aus dem postUp / postDown dies hier entferne?
Ja das reicht und sollte immer erste Amtshandlung sein. face-wink
was komisch ist, dass das Interface unknown ist, obwohol das wireguard interface up ist
Du hast hier vermutlich fälschlicherweise das eigene IP Interface als Gateway eingegeben was natürlich dann in die Hose geht. Dort muss logischerweise, wie bei statischen Routen immer üblich, das next Hop Gateway stehen und das ist natürlich dann die interne WG IP Adresse deines Servers (Responder, Endpoint) also 10.13.13.1!
Kollege @puderpader hat es oben schon gesagt. Daher rührt auch die fehlerhafte Anzeige im MT.
Member: godlie
godlie Mar 28, 2024 updated at 14:25:32 (UTC)
Goto Top
Achja wenn man zulange reinschaut, sieht man gewisses einfach nicht mehr, das mit den Routes und hab ich jetzt angepasst.

Ich kann jetzt die Clients im WG-Net 10.13.13.0/24 untereinander pingen, aber wenn ich versuche auf das jeweils andere Lan Netz zu pingen, geht das in einen Timeout.

Interface ist auf wireguad1 gesetzt und die SourceIp war einmal die wg Adresse einmal die des jeweiligen devices selbst.

Sollte ich hier nicht auch theoretisch in der Lage sein vom Server aus ein Ziel, in einem der LAN Segmente, zu pingen?

grüße
Member: aqui
Solution aqui Mar 28, 2024 updated at 14:35:34 (UTC)
Goto Top
aber wenn ich versuche auf das jeweils andere Lan Netz zu pingen, geht das in einen Timeout.
Hier wie immer, die übliche Administrator.de Frage, ob das Winblows Clients sind??
Wenn ja hast du sicher nicht auf dem Radar das deren lokale Windows Firewall generell IP Pakete aus fremden Netzen blockt und ganz besonders ICMP Traffic (Ping etc.) der generell geblockt ist!
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...

Tip:
Ping immer die lokalen LAN Port IP Adressen deiner Router (Mikrotik, Server etc.) dort wütet in der Regel keine Winblows Firewall. Klappt das verifiziert das dein Routing.

Das Mikrotik Ping Tool lässt dich sogar die Absender IP angeben im Reiter "Advanced". Hier kannst du dann abwechselnd einmal seine interne WG IP und seine lokale LAN IP angeben um so das Routing aus unterschiedlichen IP Netzen wasserdicht z.B. zum Server usw. zu testen! face-wink
Member: godlie
godlie Mar 28, 2024 at 14:39:16 (UTC)
Goto Top
Nein es handelt sich nicht um MS-Clients, ich versuche direkt von einem Mikrotik LTE Router zum Mikrotik Swtich zu pingen
Das schlägt fehl, der Ping auf die Wireguard Adrressen funktioniert aber, ja ich hab im Mikrotik Ping, auch die SourceIp gesetzt und das Interface auf wg1
Member: godlie
godlie Mar 28, 2024 at 14:50:22 (UTC)
Goto Top
Ich hab jetzt mal ein Traceroute gemacht vom Swtich zum Router, es scheint als würde der Server nicht forwarden?
bildschirmfoto 2024-03-28 um 15.49.26
bildschirmfoto 2024-03-28 um 15.49.00
Mitglied: 12168552861
Solution 12168552861 Mar 28, 2024 updated at 15:01:00 (UTC)
Goto Top
Hatte die Subnetze vertauscht, sorry ist korrigiert.
Auch sicherstellen das das IP-Forwarding auf dem Server aktiviert ist.
heart1
Member: aqui
Solution aqui Mar 28, 2024 updated at 15:08:11 (UTC)
Goto Top
Sprich dein WG Client rennt auf dem CRS-326 Switch, richtig?
Mit dessen lokaler LAN IP 192.168.0.250 als Absender IP (Source) im MT Ping Tool sollte im ersten Step alle internen WG Adressen: 10.13.13.1 (Server) und 10.13.13.4 (SXTR) pingbar sein. Ist dem so?

Im zweiten Step (gleiches Source Setting im Ping Tool) sollte auch die lokale LAN IP des SXTR 192.168.123.1 pingbar sein!
Klappt das nicht fehlt ggf. auch hier die statische Route im SXTR auf das 192.168.0.0/24 Netz mit 10.13.13.1 als next Hop. Hast du das geprüft?

Den identischen Test machst du dann ebenso auf der SXTR Seite.
Falls du in den MTs Firewall Settings hast oder iptables, nftables auf dem Debian aktiv ist beachte auch diese.
IP Forwarding (Routing) im Debian Host hast du in der /etc/sysctl.conf mit net.ipv4.ip_forward=1 aktiviert? 🤔
Member: godlie
godlie Mar 28, 2024 at 15:13:55 (UTC)
Goto Top
Ja der Switch sowie der Router sind meine Mikrotik Peers auf den Server.
Die Route ist im SXTR hinterlegt.

Ein ping innerhalb des WG Netzes (10.13.13.0) ist möglich, alles erreichbar.

So ein bisschen am Server nachgeshen, er scheint mal zu wissen wohin er muss, d.h. ich hab evtl. in der Firewall noch ein Problem, wobei aber am Switch ist diesbezüglich gar nichts eingestellt hm
root@29ac8579170b:/# ip route
default via 192.168.64.1 dev eth0 
10.13.13.0/24 dev wg0 proto kernel scope link src 10.13.13.1 
192.168.0.0/24 dev wg0 scope link 
192.168.64.0/20 dev eth0 proto kernel scope link src 192.168.64.2 
192.168.123.0/24 dev wg0 scope link 
root@29ac8579170b:/# cat /etc/sysctl.conf 
# content of this file will override /etc/sysctl.d/*
net.ipv4.ip_forward = 1
root@29ac8579170b:/# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
root@29ac8579170b:/# ping 192.168.0.250
PING 192.168.0.250 (192.168.0.250) 56(84) bytes of data.
^C
--- 192.168.0.250 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

root@29ac8579170b:/# traceroute 192.168.0.1
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 46 byte packets
 1  10.13.13.4 (10.13.13.4)  52.377 ms  48.535 ms  49.944 ms
 2  *^C
root@29ac8579170b:/# traceroute 192.168.123.1
traceroute to 192.168.123.1 (192.168.123.1), 30 hops max, 46 byte packets
 1  10.13.13.3 (10.13.13.3)  17.313 ms  17.346 ms  17.086 ms
 2^C
root@29ac8579170b:/#
Mitglied: 12168552861
12168552861 Mar 28, 2024 updated at 15:19:03 (UTC)
Goto Top
Beim Ping auf dem Server immer die Quelladresse/Interface angeben.
Und die Firewalls der Zieldevices customizen wenn diese ICMP aus fremden Subnetzen blocken, Winblows macht das nämlich per Default.
heart1
Member: godlie
godlie Mar 28, 2024 at 15:19:13 (UTC)
Goto Top
Hier noch die Config vom Switch
# 2024-03-28 16:16:32 by RouterOS 7.11.2
# software id = JU4F-S0BF
#
# model = CRS326-24G-2S+
# serial number = HE808XEND0M
/interface bridge
add admin-mac=48:A9:8A:7E:B3:06 auto-mac=no comment=defconf name=bridge
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/ip pool
add name=OVN ranges=192.168.99.10-192.168.99.20
add comment=Unif name=Unif ranges=192.168.0.10-192.168.0.12
/port
set 0 name=serial0
/ppp profile
add local-address=192.168.99.1 name=OVPN remote-address=OVN
/interface bridge port
add bridge=bridge comment=defconf interface=ether1
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether9
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=ether11
add bridge=bridge comment=defconf interface=ether12
add bridge=bridge comment=defconf interface=ether13
add bridge=bridge comment=defconf interface=ether14
add bridge=bridge comment=defconf interface=ether15
add bridge=bridge comment=defconf interface=ether17
add bridge=bridge comment=defconf interface=ether18
add bridge=bridge comment=defconf interface=ether19
add bridge=bridge comment=defconf interface=ether20
add bridge=bridge comment=defconf interface=ether21
add bridge=bridge comment=defconf interface=ether22
add bridge=bridge comment=defconf interface=ether23
add bridge=bridge comment=defconf interface=ether24
add bridge=bridge comment=defconf interface=sfp-sfpplus1
add bridge=bridge comment=defconf interface=sfp-sfpplus2
add bridge=bridge interface=ether16
/interface ovpn-server server
set auth=sha1,md5,sha512 certificate=VPN_SRV cipher=\
    blowfish128,aes128-cbc,aes192-cbc,aes256-cbc,aes192-gcm,aes256-gcm \
    default-profile=OVPN enabled=yes port=443
/interface wireguard peers
add allowed-address=10.13.13.0/24,192.168.123.0/24 endpoint-address=\
    - endpoint-port=51820 interface=wireguard1 \
    persistent-keepalive=30s public-key=\
   -
/ip address
add address=192.168.0.250/24 comment=defconf interface=bridge network=\
    192.168.0.0
add address=10.13.13.3/24 interface=wireguard1 network=10.13.13.0
/ip dns
set servers=1.1.1.1
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=192.168.0.254 routing-table=\
    main suppress-hw-offload=no
add disabled=no distance=1 dst-address=192.168.123.0/24 gateway=10.13.13.1 \
    pref-src="" routing-table=main scope=30 suppress-hw-offload=no \  
    target-scope=10
/ppp secret
add name=ppp1 profile=OVPN
/system clock
set time-zone-name=Europe/Vienna
/system note
set show-at-login=no
/system ntp client
set enabled=yes
/system ntp client servers
add address=0.at.pool.ntp.org
add address=1.at.pool.ntp.org
/system routerboard settings
set boot-os=router-os
Mitglied: 12168552861
12168552861 Mar 28, 2024 updated at 15:24:39 (UTC)
Goto Top
Des weiteren sollte auf dem Default GW des 192.168.0.0/24 Netzes eine statische Route zum Switch gesetzt werden wenn dieser nicht Default GW für die Clients ist.

Netz 192.168.123.0/24
GW 192.168.0.250
Member: aqui
aqui Mar 28, 2024 updated at 18:32:41 (UTC)
Goto Top
Des weiteren sollte auf dem Default GW des 192.168.0.0/24 Netzes eine statische Route zum Switch gesetzt werden wenn dieser nicht Default GW für die Clients ist.
Guter Punkt! 👍
Das ist sicher relevant, da der CRS Switch das .0.0er LAN laut Zeichnung Layer 2 technisch durchreicht an den RB780 und nicht routet.
Im RB780 müssen dann zwingend 2 statische Routen auf das 10.13.13er und das .123.0er Netz konfiguriert sein sofern er das Default Gateway im .0.0er Netz ist.
Das würde man auch merken wenn man von einem .0.0er Client einmal die lokale Wireguard IP des CRS pingt. Scheitert das, fehlen die Routen!

Allerdings müsste ein o.a. Ping von der SXTR Seite auf die CRS LAN IP .0.250 immer klappen, denn der CRS kennt ja alle remoten Routen. Es würde nur Endgeräte im lokalen .0.0er Netz am CRS betreffen und auch den RB780.
Member: godlie
godlie Mar 29, 2024 at 06:41:06 (UTC)
Goto Top
Zitat von @aqui:

Allerdings müsste ein o.a. Ping von der SXTR Seite auf die CRS LAN IP .0.250 immer klappen, denn der CRS kennt ja alle remoten Routen. Es würde nur Endgeräte im lokalen .0.0er Netz am CRS betreffen und auch den RB780.

Hier steig ich auch mit ein, der Swtich selbst sollte immer erreichbar sein, da er als Peer selber, keine Rückroute über den Router brauch, da er es selbst über das WG Interface leiten kann / könnte.

Es klappt leider kein Ping weder vom 0.0 oder 123.0, im 123 steht der SXT alleine im 0.0.0 steht der Router davor , ohne Rückroutenkonfiguration, was aber das "pingbarsein" des Grundgerätes nicht verhindern sollte, da der Switch ja über die WG IP erreichbar ist, aber nicht auf seiner eignen 192.168.0.250/24, da werd ich nicht so ganz schlau draus
Member: godlie
godlie Mar 29, 2024 at 12:21:57 (UTC)
Goto Top
Jetzt ist es am laufen, die Allowed IPs hab ich nun ausgetauscht, sodass jeder peer sein subnet als Allowed hat und nicht das subnet des gegenüber.

Danke für die Hilfe
Member: aqui
aqui Mar 29, 2024 updated at 18:42:28 (UTC)
Goto Top
sodass jeder peer sein subnet als Allowed hat und nicht das subnet des gegenüber.
Das ist aus Wireguard Konfigsicht FALSCH! face-sad
Dort MUSS in den Peers bei beiden Mikrotiks als Allowed IPs IMMER die IP des Serves stehen: 10.13.131! Und analog beim den Mikrotik Server Peers immer die des jeweiligen Mikrotik Peer Gegenübers! So wird ein (Wireguard) Schuh draus...

Du warst jetzt schneller aber wir lassen deine ToDos hier stehen....

OK, rekapitulieren wir noch einmal das Ping Verhalten:
  • CRS Seite: Ping Tool mit Absender IP .0.250 kann erfolgreich auf alle 10.13.13er WG Interfaces pingen. Ein Ping auf die SXT LAN IP .123.1 scheitert.
  • SXT Seite: Ping Tool mit Absender IP .123.1 kann ebenso erfolgreich auf alle 10.13.13er WG Interfaces pingen. Ein Ping auf die CRS LAN IP .0.250 scheitert.
  • Server Seite: Ping auf alle 10.13.13er WG Interfaces klappt. Ping auf die SXT LAN IP .123.1 klappt. Ein Ping auf die CRS LAN IP .0.250 scheitert.
Ist das so richtig?
Verdächtig ist das der Server selber zwar die SXT LAN Seite .123.1 pingen kann, nicht aber die LAN Seite des CRS. 🤔

Hier solltest du sicherheitshalber nochmals die Peer Einträge aller Beteiligten checken.
Server:
[Interface]
Address = 10.13.13.1/24
ListenPort = 51820
PrivateKey = ----

[Peer]
# peer_SXT
PublicKey =  ----
AllowedIPs = 10.13.13.3/32, 192.168.123.0/24

[Peer]
# peer_CRS
PublicKey = ----
AllowedIPs = 10.13.13.4/32, 192.168.0.0/24
Wenn du hier Änderungen vorgenommen hast immer ein systemctl restart wg-quick@wg0.service ausführen damit die neue Konfig aktiv wird!
Ein wg show zeigt dann die aktiven Peers

Die statischen Routing Einträge auf den Mikrotiks zum jeweiligen remoten LAN IP Netz müssen beide auf die 10.13.13.1er IP des Servers zeigen. Checke das in der Routing Tabelle IP --> Routes.
Führe auch einmal ein Ping mit dem Ping Tool aus indem du die jeweilige WG IP Adresse als Source nimmst und pingst dann das jeweils remote LAN IP Interface.
  • CRS Peer: AllowedIPs = 10.13.13.1/32, 192.168.123.0/24
  • SXT Peer: AllowedIPs = 10.13.13.1/32, 192.168.0.0/24

Sollte das dann wider Erwarten immer noch nicht gehen kann es ggf. nur eine Firewall Problematik sein.
Verdächtig ist das der Server das CRS LAN Interface nicht pingen aber das SXT LAN Interface sehr wohl.
Das lässt vermuten das irgendetwas auf dem Tunnel Peer CRS <-> Server nicht korrekt ist?! 🤔
GermansolvedQuestionVPNRouters, Routing