18
Wireguard Jumphost Split Tunnel Routingtroubles
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:
Server wg.conf:
Server IP Route:
ClientConfigs
PL1
PL2
Für mein Verständniss sollte das eig. so passen oder übersehe ich was?
grüße
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:
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 = 25Server 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 linkClientConfigs
PL1
PL2
Für mein Verständniss sollte das eig. so passen oder übersehe ich was?
grüße
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: 11148167456
Url: https://administrator.de/contentid/11148167456
Ausgedruckt am: 25.11.2024 um 11:11 Uhr
18 Kommentare
Neuester Kommentar
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!
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)!
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!
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)!
Hallo @aqui,
danke erstmla für den Tipp bzgl. dem NAT, müsste es reichen wenn ich aus dem postUp / postDown dies hier entferne?
Ich hab hier noch die Routing Einträge: was komisch ist, dass das Interface unknown ist, obwohol das wireguard interface up ist
grüße
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 MASQUERADEIch hab hier noch die Routing Einträge: was komisch ist, dass das Interface unknown ist, obwohol das wireguard interface up ist
grüße
Server Config
Config Client CL1
Config Client CL2
Für die Routen auf den Clients dann als GW die 10.13.13.1 eintragen, der kennt ja alle anderen Netze dann bereits.
[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/24Config 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 = 25Config 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 = 25Für die Routen auf den Clients dann als GW die 10.13.13.1 eintragen, der kennt ja alle anderen Netze dann bereits.
1müsste es reichen wenn ich aus dem postUp / postDown dies hier entferne?
Ja das reicht und sollte immer erste Amtshandlung sein. 
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.
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
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
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!
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
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
Ich hab jetzt mal ein Traceroute gemacht vom Swtich zum Router, es scheint als würde der Server nicht forwarden?
Hatte die Subnetze vertauscht, sorry ist korrigiert.
Auch sicherstellen das das IP-Forwarding auf dem Server aktiviert ist.
Auch sicherstellen das das IP-Forwarding auf dem Server aktiviert ist.
1
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? 🤔
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? 🤔
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
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:/#
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.
Und die Firewalls der Zieldevices customizen wenn diese ICMP aus fremden Subnetzen blocken, Winblows macht das nämlich per Default.
1
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
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
Netz 192.168.123.0/24
GW 192.168.0.250
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.
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.
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
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
Danke für die Hilfe
sodass jeder peer sein subnet als Allowed hat und nicht das subnet des gegenüber.
Das ist aus Wireguard Konfigsicht FALSCH! 
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.
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 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?! 🤔
