Wireguard Traffic (Gateway redirect)
Hey.
ich brächte nochmal eure Hilfe. Zwischen Router A (mikrotik ROS7) und Router B (mikrotik ROS7) habe ich eine funktionierende LAN - LAN Wireguard aufgebaut.
Nun wie kann ich den gesamten Trafic vom Router B zum Router A schicken.
danke
ich brächte nochmal eure Hilfe. Zwischen Router A (mikrotik ROS7) und Router B (mikrotik ROS7) habe ich eine funktionierende LAN - LAN Wireguard aufgebaut.
Nun wie kann ich den gesamten Trafic vom Router B zum Router A schicken.
danke
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator colinardo am 13.07.2022 um 14:08:44 Uhr
Titel korrigiert und mehr auf die Frage bezogen
Content-ID: 3328636950
Url: https://administrator.de/contentid/3328636950
Ausgedruckt am: 22.11.2024 um 08:11 Uhr
10 Kommentare
Neuester Kommentar
Und Du willst uns nicht mit weitergehenden Informationen überfordern?!
Also kurz: Mit angepasstem Routing
Also kurz: Mit angepasstem Routing
Servus.
WG Gateway IP und Interface bzw. Source-Subnet an eigene Bereiche anpassen.
Lokale und Remote-Firewall natürlich wie immer nicht vergessen! Entsprechendes Forwarding muss passen und freigeschaltet sein. Wenn die lokale Seite über die andere ins Internet soll dann muss auch das Masquerading am WAN Ports des Remote-Standorts das Quellnetz SRC-NATen falls dort nicht sowieso schon alles geNATet wird was aus dem WAN fliest.
Durch de-/aktivieren der oben sichtbaren Routing-Rule lässt sich dann festlegen ob der Traffic über das WG Netz fließt oder das Default GW der main Table für den outbreak genutzt wird.
Einfaches Policy Base Routing halt .
Grüße Uwe
WG Gateway IP und Interface bzw. Source-Subnet an eigene Bereiche anpassen.
Lokale und Remote-Firewall natürlich wie immer nicht vergessen! Entsprechendes Forwarding muss passen und freigeschaltet sein. Wenn die lokale Seite über die andere ins Internet soll dann muss auch das Masquerading am WAN Ports des Remote-Standorts das Quellnetz SRC-NATen falls dort nicht sowieso schon alles geNATet wird was aus dem WAN fliest.
Durch de-/aktivieren der oben sichtbaren Routing-Rule lässt sich dann festlegen ob der Traffic über das WG Netz fließt oder das Default GW der main Table für den outbreak genutzt wird.
Einfaches Policy Base Routing halt .
Grüße Uwe
Naja das ist mal wieder eine Bäcker-Antwort. "Klappt nicht" ohne jegliche weiteren Infos . Hier kennt keiner deine Config deiner beiden Geräte geschweige denn deine Infrastruktur. Ein
Da aber selbst das eine Hürde zu sein scheint hier mal eine ganz simple lauffähige Config zwischen zwei Mikrotiks (wurde wie obiges einwandfrei getestet). Firewall wurde bis auf das NAT ausdrücklich weg gelassen da diese bei jedem andere Anforderungen hat. Ich gehe davon aus das du weist wie die einzelnen CHAINS INPUT/FORWARD arbeiten. Wenn nicht dann solltest du mal einen Grundkurs mit einer IPTABLES oder NFTABLES Firewall machen dann ist die Mikrotik Firewall auch kein Buch mit sieben Siegeln mehr.
Kurz in der Firewall muss der Traffic des Client-Netzes in der FORWARD-CHAIN erlaubt werden falls er das nicht schon ist.
Für das Beispiel wird sämtlicher Traffic von vlan100 von Router B über Wireguard zu Router A geleitet also auch Internet-Traffic
Ein Trace von einem Client hinter Router B sollte zeigen das der Traffic über das Wireguard Interface von Router A ins Internet fliest, wie es hier im Test auch läuft
Wichtig ist auch das du nicht vergisst die statische Rückroute auf Router A zu setzen die den Client-Traffic zurück über Wireguard an Router B schickt und die AllowedIPs auf Router A auch dieses Subnetz (vlan100) beinhaltet.
Faustregel: Folge den Paketen nach den allgemein gültigen Routing-Regeln und du findest evt. Fehler sofort. Im Zweifel hilft ein kurzer Wireshark Trace an den beteiligten Geräten.
Fazit: Works as designed!
Viel Erfolg.
Grüße Uwe
export hide-sensitive
von beiden Geräten sollte man zumindest doch schon mal hinbekommen um uns hier nicht gänzlich im Regen stehen zu lassen!Da aber selbst das eine Hürde zu sein scheint hier mal eine ganz simple lauffähige Config zwischen zwei Mikrotiks (wurde wie obiges einwandfrei getestet). Firewall wurde bis auf das NAT ausdrücklich weg gelassen da diese bei jedem andere Anforderungen hat. Ich gehe davon aus das du weist wie die einzelnen CHAINS INPUT/FORWARD arbeiten. Wenn nicht dann solltest du mal einen Grundkurs mit einer IPTABLES oder NFTABLES Firewall machen dann ist die Mikrotik Firewall auch kein Buch mit sieben Siegeln mehr.
Kurz in der Firewall muss der Traffic des Client-Netzes in der FORWARD-CHAIN erlaubt werden falls er das nicht schon ist.
Testumgebung:
ROUTER A: (receives all traffic from ROUTER B via Wireguard)
========================
ether1 = WAN "ROUTER_A.DOMAIN.TLD"
ether2 = LAN 192.168.200.1/24 (vlan200)
wg0 = Wireguard LAN 10.80.0.1/24
ROUTER B: (with GW redirect to ROUTER A via Wireguard)
========================
ether1 = WAN "ROUTER_B.DOMAIN.TLD"
ether2 = LAN 192.168.100.1/24 (vlan100)
wg0 = Wireguard LAN 10.80.0.2/24
Für das Beispiel wird sämtlicher Traffic von vlan100 von Router B über Wireguard zu Router A geleitet also auch Internet-Traffic
ROUTER A (receives all traffic from ROUTER B via Wireguard)
# ============================================================
# ROUTER A (receives all traffic from ROUTER B via Wireguard)
# ============================================================
/interface bridge
add ingress-filtering=no name=bridgeLocal protocol-mode=none vlan-filtering=yes
/interface wireguard
add listen-port=55555 mtu=1420 name=wg0
/interface vlan
add interface=bridgeLocal name=vlan200 vlan-id=200
/ip pool
add name=pool_vlan200 ranges=192.168.200.10-192.168.200.254
/ip dhcp-server
add address-pool=pool_vlan200 interface=vlan200 name=server_vlan200
/interface bridge vlan
add bridge=bridgeLocal tagged=bridgeLocal vlan-ids=200
/interface bridge port
add bridge=bridgeLocal interface=ether2 pvid=200
/interface wireguard peers
add allowed-address=192.168.100.0/24,10.80.0.2/32 endpoint-address=ROUTER_B.DOMAIN.TLD endpoint-port=55555 interface=\
wg0 public-key="V8f2UM3mkhyzcxy7I44zbyLAEiXJBo4C+ESW0AV8IHo="
/ip address
add address=192.168.200.1/24 interface=vlan200 network=192.168.200.0
add address=10.80.0.1/24 interface=wg0 network=10.80.0.0
/ip dhcp-client
add interface=ether1
/ip dhcp-server network
add address=192.168.200.0/24 dns-server=192.168.200.1 gateway=192.168.200.1 netmask=24
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1 comment="NAT all out eth1"
/ip route
add disabled=no dst-address=192.168.100.0/24 gateway=10.80.0.2
ROUTER B (with GW redirect to ROUTER A via Wireguard)
# ======================================================
# ROUTER B (with GW redirect to ROUTER A via Wireguard)
# ======================================================
/interface bridge
add ingress-filtering=no name=bridgeLocal protocol-mode=none vlan-filtering=yes
/interface wireguard
add listen-port=55555 mtu=1420 name=wg0
/interface vlan
add interface=bridgeLocal name=vlan100 vlan-id=100
/interface list
add name=LAN
add name=WAN
/ip pool
add name=pool_vlan100 ranges=192.168.100.10-192.168.100.254
/ip dhcp-server
add address-pool=pool_vlan100 interface=vlan100 lease-time=1h name=dhcp_vlan100
/routing table
add disabled=no fib name=viaWG
/interface bridge port
add bridge=bridgeLocal interface=ether2 pvid=100
/interface bridge vlan
add bridge=bridgeLocal tagged=bridgeLocal vlan-ids=100
/interface list member
add interface=ether2 list=LAN
add interface=ether1 list=WAN
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=ROUTER_A.DOMAIN.TLD endpoint-port=55555 interface=wg0 public-key=\
"IaQXia6gCT6E8x83+Zi2LFXPVMN3RLqKIuRc1vD7+2E="
/ip address
add address=192.168.100.1/24 interface=vlan100 network=192.168.100.0
add address=10.80.0.2/24 interface=wg0 network=10.80.0.0
/ip dhcp-client
add interface=ether1
/ip dhcp-server network
add address=192.168.100.0/24 dns-server=192.168.100.1 gateway=192.168.100.1 netmask=24
/ip dns
set allow-remote-requests=yes
/ip firewall nat
add action=masquerade chain=srcnat comment="NAT all out eth1" ipsec-policy=out,none out-interface=ether1
/ip route
add gateway=10.80.0.1 routing-table=viaWG
/routing rule
add action=lookup disabled=no interface=vlan100 table=viaWG
Ein Trace von einem Client hinter Router B sollte zeigen das der Traffic über das Wireguard Interface von Router A ins Internet fliest, wie es hier im Test auch läuft
Wichtig ist auch das du nicht vergisst die statische Rückroute auf Router A zu setzen die den Client-Traffic zurück über Wireguard an Router B schickt und die AllowedIPs auf Router A auch dieses Subnetz (vlan100) beinhaltet.
Faustregel: Folge den Paketen nach den allgemein gültigen Routing-Regeln und du findest evt. Fehler sofort. Im Zweifel hilft ein kurzer Wireshark Trace an den beteiligten Geräten.
Fazit: Works as designed!
Viel Erfolg.
Grüße Uwe
Die eingebundenen Netzwerkordner hinter Router A sind nicht sichtbar
Kannst du die Rechner die diese Shares freigeben anpingen.Automatisch "sehen" kannst du die Ordner nicht, denn wenn du ohne DNS arbeitest werden die per Broadcast verteilt was bekanntlich prinzipbedingt nicht über geroutete Netze übertragen wird.
Kannst du die Ordner manuell mit \\<Ziel_IP>\<Share> mounten ?
Wenn du einen lokalen DNS nutzt um lokale Hostnamen aufzulösen musst du das nicht bzw. solltest zuerst den lokalen DNS als DNS an den Clients eingeben der dann eh eine Weiterleitung auf einen Internet DNS oder DNS Caching Router hat wie z.B. den MT.
Wenn du keinen lokalen DNS betreibst bleiben die Broadcasts hängen wie oben schon gesagt. Dann kannst du die Namen statisch in die hosts oderlmhosts Datei eintragen.
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Wenn du keinen lokalen DNS betreibst bleiben die Broadcasts hängen wie oben schon gesagt. Dann kannst du die Namen statisch in die hosts oderlmhosts Datei eintragen.
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Serie: Windows 11
Wireguard Traffic (Gateway redirect)10