porfavor
Goto Top

Opnsense Wireguard Routing Probleme

Guten Abend,

ich habe Wireguard auf opnsense, Site to Site, eingerichtet.
Ich kann nun auch von Standort A die lokale IP der opnsense an Standort B erreichen. Andere IPs im Netz B erreiche ich hingegen nicht. Von einem Gerät an Standort B aus erreiche ich an Standort A nicht einmal die lokale IP der opnsense.

Standort B ist ein VLAN, d.h. ich habe keinen Router als Standartgateway, wo ich Routen setzen könnte. Die Logik sagt mir aber, dass ich auf den weiteren Geräten an Standort B Routen setzen müsste, damit diese wissen, wen sie überhaupt fragen müssen, wenn sie das Subnetz von Standort A erreichen wollen (nämlich die opnsense an Standort B).

In dem anhängenden Schaubild fehlt noch die opnsense VM an Standort A (IP: 192.168.132.32). Die opnsense an Standort B befindet sich auf 192.168.133.1. Das Gerät 192.168.132.2 ist ein Windows-System.

Was muss ich hier tun?
netzwerklayour

Content-ID: 2843918573

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

Ausgedruckt am: 22.11.2024 um 08:11 Uhr

aqui
aqui 19.05.2022 aktualisiert um 22:11:12 Uhr
Goto Top
Was muss ich hier tun?
Erstmal in Ruhe das hiesige WG Tutorial lesen und verstehen:
Merkzettel: VPN Installation mit Wireguard
Dann dein WG Setup hier posten. Ohne das Setup ist alles Raten im freien Fall. Wie sollen wir sonst sehen was du falsch gemacht hast ?! face-sad
Vermutung einer der klassischen Fehler...
  • Deine Allowed IPs sind falsch eingetragen mit falschen Masken
  • Deine Firewall Regeln stimmen nicht auf dem LAN und/oder WG Interface
Nebenbei gesagt versteht man nicht wirklich deine recht kryptischen Zeichnungen.
  • Welche IP Netze sind die lokalen and Standort 1 und 2 ?
  • Welches IP Netz nutzt du für das interne Wireguard Netz ?
Etwas klare Dokumentation und etwas detailiertere Infos würden allen helfen.
Porfavor
Porfavor 19.05.2022 um 23:11:30 Uhr
Goto Top
Vielen Dank für deine Antwort.

Standort A (zuhause) ist das rote Quadrat links, Standort B das rote Quadrat rechts. An Standort A gibt es eine VM mit opnsense, an Standort B ebenfalls (da ist es aber in einem VLAN bei Netcup).

Allowed IPs an Standort A: 10.210.0.0/24 sowie 192.168.133.0/24
Allowed IPs an Standort B: 10.210.0.0/24 sowie 192.168.132.0/24
Die Wireguard IPs der beiden Endpunkte sind 10.210.0.1 (Standort A) und 10.210.0.2 (Standort B)

Firewall Standort A:

- WAN Regel mit Wireguard Port, eingehend, UDP, Gateway: standard
- Wireguard (Group): Quelle Einzelner Host oder Netzwerk 10.210.0.0/24 sowie 192.168.133.0/24

Firewall Standort B:

dasselbe, nur die zweite IP-Range bei der zweiten Regel: 192.168.132.0/24

Ansonsten keine Einschränkungen bei den Regeln. Dort gibt es aber schon die vorkonfigurierte Regel "Default allow LAN to any rule".

Deine Antwort entnehme ich, dass ich auch auf dem LAN-Interface Firewall-Regeln setzen muss.

Ich hoffe, das hilft weiter.
aqui
aqui 20.05.2022 aktualisiert um 08:55:11 Uhr
Goto Top
Deine Masken des Wireguard IP Netzes stimmen nicht! Das müssen /32er Hostmasken der einzelnen Endpunkte sein. (Siehe Tutorial und auch Wireguard Doku Thema Cryptokey Routing)
dass ich auch auf dem LAN-Interface Firewall-Regeln setzen muss.
Nein! Wenn dort eine Scheunentor Regel "Allow LAN to any" definiert ist, ist das nicht erforderlich!
Hast du im Regelwerk am WAN Port darauf geachtet das der WG Port passieren darf auf die WAN IP? Im Default ist das UDP 51820
Hier muss also eine Regel "PASS Protocol:UDP, Source: any, Port: any - Destination: WAN_IP, Port: 51820" auf beiden Standort Seiten definiert sein!
Du arbeitest zudem auch in einer Router Kaskade wenn man das aus der obigen Zeichnung richtig interpretiert?!
Hier musst du zusätzlich das Blocking der privaten RFC1918 Netze ausschalten und die WG Ports am davor kaskadierten Router per Port Forwarding weiterleiten. (Siehe Tutorial zur Router Kaskade).
Porfavor
Porfavor 20.05.2022 um 13:14:18 Uhr
Goto Top
Vielen Dank. Ich schaue mir das Ganze bei Gelegenheit an. Eine Portweiterleitung auf der Fritzbox auf den Wireguard Port an die opnsense ist natürlich eingerichtet. Ich schaue mir dennoch den Link an, da da möglicherweise noch mehr beschrieben war.
Porfavor
Porfavor 20.05.2022 um 14:43:43 Uhr
Goto Top
An dieser Stelle bereits eine Frage: In der Fritzbox kann ich ja keine Notation mit /24 oder /32 angeben, sondern ich mache das mit 255. usw. Wäre es in meiner Konfiguration richtig, beider der Fritzbox-Route vom Wireguard-Netz (10.210.0.0) anstelle von 255.255.255.0 richtigerweise 255.255.0.0 anzugeben?
Porfavor
Porfavor 20.05.2022 um 15:02:19 Uhr
Goto Top
Ich habe nun am Standort A den Haken für die Blockierung privater Netze an der WAN-Schnittstelle entfernt und sowohl in der Firewall als auch an der Endpunkt-Konfiguration in /32 geändert. Das hat aber noch nicht zum Ziel geführt.

Wenn ich von Standort A 192.168.133.2 erreichen will, bleibe ich bei 192.168.132.32 (opnsense-Server Standort A) hängen. Umgekehrt ist es völlig abstrus. Hier geht MTR bei einer IP los, die an der letzten Stelle nicht der öffentlichen IP des Ausgangsservers an Standort B entspricht und springt dann zu einer IP, die ich gar nicht nachvollziehen kann, jedenfalls aber nicht zum opnsense Server an Standort B. Mein laienhaftes Verständnis sagt mir, dass ich da noch irgendetwas an Standort B machen muss.
aqui
aqui 23.05.2022 um 15:37:00 Uhr
Goto Top
Bist du da weitergekommen? Ansonsten check ich das hier mal in einem Testsetup.
Porfavor
Porfavor 23.05.2022 um 15:40:49 Uhr
Goto Top
Ich habe in einem anderen Forum Hinweise bekommen, was noch zu tun ist. Ich werde später versuchen, diese umzusetzen.
Porfavor
Porfavor 23.05.2022 um 17:57:21 Uhr
Goto Top
Das entscheidende Problem war die Windows-Firewall an den weiteren Endgeräten. Diese für die IP-Range zu öffnen, hat die Lösung gebracht. Ich musste aber (wohl) auch noch eine Route auf dem zweiten VPS setzen.
Porfavor
Porfavor 23.05.2022 um 23:29:09 Uhr
Goto Top
Es gibt hier aber noch ein Firewall-Problem. Das Ganze funktionierte nämlich nur ab und an kurz und dann wieder nicht. Ich habe ganz kurz testweise an Standort B die Firewall komplett deaktiviert und das führte zum Erfolg.

Hast du eine Idee, was hier falsch konfiguriert sein könnte? Habe ich da irgendetwas vergessen außer den eingangs beschriebenen Regeln?
Porfavor
Porfavor 24.05.2022 um 00:34:31 Uhr
Goto Top
Nachdem ich nun auf der opnsense an Standort B das Wireguard Interface zugewiesen habe (wie in der Anleitung empfohlen, aber nicht vorausgesetzt), scheint es problemlos zu funktionieren.

Beschreibung dazu:

First, it generates an alias for the tunnel subnet(s) that can be used in firewall rules. Otherwise you will need to define your own alias or at least manually specify the subnet(s)

Second, it automatically adds an IPv4 outbound NAT rule, which will allow the tunnel to access IPv4 IPs outside of the local network (if that is desired), without needing to manually add a rule

Finally, it allows separation of the firewall rules of each WireGuard instance (each wgX device). Otherwise they all need to be configured on the default WireGuard group that OPNsense creates. This is more an organisational aesthetic, rather than an issue of substance


Kannst du sagen, ob hier nun sicherheitstechnisch etwas Relevantes/Problematisches passiert ist? Nach meinem Verständnis ist hier nichts nach innen geöffnet worden. Eine neue Regel konnte ich allerdings generell nicht entdecken. Wo soll diese angelegt worden / ersichtlich sein?
aqui
aqui 24.05.2022 um 08:51:18 Uhr
Goto Top
Nein, da ist nichts Problematisches. Das ist alles Standard was zum Setup gehört. Die Windows interne Firewall zickt deshalb weil die Windows eigene automatische Netzwerk Erkennung fehlschlägt und das Netz dann als Public deklariert wird wo dann per Default alles geblockt ist.

Wenn's das denn war bitte dann nicht vergessen deinen Thread als erledigt zu markieren.