Wireguard Site-to-Site Firewall-Regeln

Hi,

ich hab mal eine Frage wegen Firewall-Regeln und Wireguard Site-to-Site.

Ich hab meine Firewall-Regeln nun nach der Anleitung 2.0 aus dem Wiki aufgebaut.

Funktioniert auch soweit super. Nur nicht für das entfernte Netz, das per Wireguard verbunden ist.

Ich hab in einer VM Wireguard laufen, da Unifi ja noch keine Site-to-Site Verbindungen über Wireguard unterstützt.

Mein Setup:

• entferntes Netz: 192.168.2.0/24
• Wireguard-Server: 192.168.1.254
• Wireguard-Config: kein NAT / kein Masquerade
• statische Route in UniFi: 192.168.2.0/24 via 192.168.1.254

In der Firewall hab ich das Netz 192.168.2.0/24 und den Gateway 192.168.2.1 genauso geblockt wie lokale VLANs.

Aus dem entfernten Netz 192.168.2.0/24 kann ich aber weiterhin auf alles im lokalen Netz zugreifen.

Die Firewall-Regeln greifen also nicht.

Was muss ich nun machen, dass die Firewall-Regeln greifen?

Danke schonmal für die Hilfe.

Hmmm...aber die Clients aus dem entfernten Netz (192.168.2.0/24) sind doch durch die Kopplung per Wireguard Site-to-Site nicht Teil des lokalen Netzes (192.168.1.0/24).

Hier wird doch meiner Ansicht nach nur wie in ein anderes VLAN geroutet.

Ich möchte ja nur, dass Pakete aus dem entfernten Netz vom Wireguard-Server an die UDM-Pro geleitet werden, damit diese das lokale Routing macht und die Firewall-Regeln greifen.

Die sind ganz normal über 192.168.2.x ansprechbar. Die haben die IP-Adressen aus dem entfernten Netz.

Zitat von Networker

Ich mache mal ein Beispiel für Client-To-Side:

Mein Endgerät befindet sich im Netz 192.168.111.0/24, hat also auch eine entsprechende IP-Adresse.

Der entfernte Standort hat folgende Konfiguration:

Hauptnetz: 10.0.0.0/24

VPN-Netz: 10.222.222.0/24

Mein Endgerät erhält bei Einwahl über VPN als eine IP-Adresse im Bereich 10.222.222.0/24 - völlig egal, wie die Konfiguration des lokalen Netzes aussieht.

Wenn mein VPN-Zugriff auf das Hauptnetz 10.0.0.0/24 eingeschränkt werden soll, müssen die entsprechenden Firewallregeln sich auf die Quelle 10.222.222.0/24 beziehen - und eben nicht auf 192.168.111.0/24.

Ich bin mir mangels eigener Erfahrung nicht sicher, ob es bei Site-To-Site Besonderheiten gibt, aber prinzipiell ist das Schema sicherlich dasselbe.

Alles anzeigen

Für Client-to-Site hast du Recht. Hier wird ein eigenes lokales Netz für die VPN-Clients angelegt.

Bei Site-to-Site verhält sich das aber anders.

Zitat von razor

Hallo zwelch82 ,

pinge oder lasse von einem Client aus 192.168.2.0/24 eine Maschine in Deinem lokalen Netz (192.168.1.0/24) anpingen und schaue auf der Zielmaschine, wer sie anpingt. Dann müsstest / solltest Du sehen wer da kommt.

Ich habe das gerade bei meinem Setup (großes USG <-> kleines USG mit WG S-2-S und Transfer-Netz) geprüft: ich sehe auf meinem NAS die echte Quell-IP:

Quelle (RasPi):

Code

$ ping -c 4 10.10.101.10
PING 10.10.101.10 (10.10.101.10) 56(84) bytes of data.
64 bytes from 10.10.101.10: icmp_seq=1 ttl=62 time=10.5 ms
64 bytes from 10.10.101.10: icmp_seq=2 ttl=62 time=10.4 ms
64 bytes from 10.10.101.10: icmp_seq=3 ttl=62 time=10.4 ms
64 bytes from 10.10.101.10: icmp_seq=4 ttl=62 time=9.60 ms

--- 10.10.101.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 9.596/10.219/10.465/0.374 ms

Ziel (Synology):

Code

# tcpdump -i eth1 -p icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes

01:25:49.595182 IP 192.168.2.2 > 10.10.101.10: ICMP echo request, id 10, seq 1, length 64
01:25:49.595236 IP 10.10.101.10 > 192.168.2.2: ICMP echo reply, id 10, seq 1, length 64
01:25:50.596820 IP 192.168.2.2 > 10.10.101.10: ICMP echo request, id 10, seq 2, length 64
01:25:50.596865 IP 10.10.101.10 > 192.168.2.2: ICMP echo reply, id 10, seq 2, length 64
01:25:51.598857 IP 192.168.2.2 > 10.10.101.10: ICMP echo request, id 10, seq 3, length 64
01:25:51.598902 IP 10.10.101.10 > 192.168.2.2: ICMP echo reply, id 10, seq 3, length 64
01:25:52.599599 IP 192.168.2.2 > 10.10.101.10: ICMP echo request, id 10, seq 4, length 64
01:25:52.599643 IP 10.10.101.10 > 192.168.2.2: ICMP echo reply, id 10, seq 4, length 64

Alles anzeigen

Alles anzeigen

Ich hab Adguard Home im lokalen Netz (192.168.1.0/24) laufen und hier melden sich die entfernten Clients mit den IPs des entfernen Netzes (192.168.2.0/24):

Zitat von swag

Dein WireGuard läuft auf einen eigenen Host ?

Mal einen traceroute probiert ob der Traffic vom 192.168.2 überhaupt über die dmp geht. (Der WG Server ist ja im 192.168.1)

Ja, mein Wireguard läuft in einer eigenen VM.

Genau, das ist mein Problem. Wie kann ich die Wireguard-VM zwingen, die Pakete direkt an die UDM-Pro zu leiten?

Zitat von swag

Ich selber hab den wireguard nur auf der FW aber meine Vermutung ist den WG in ein eigenes Netz zu stellen.

(Auch wenn es dann die traffic regeln komplexer macht. )

Das ist auch meine Vermutung.

Dadurch müssen die Pakete über die UDM-Pro geroutet werden.