[Gelöst] OPNsense 23.7.8 / Wireguard / Windows-Client => Kein I-Net, kein Gateway, kein lokales Netz

[r371769]

Hallo zusammen,

ich bin neu an der OPNsense-Front und habe mich an die Einrichtung von Wireguard herangetraut.

In meinem Homelab hab ich zunächst folgendes Test-Szenario aufgebaut:
Ich habe die OPNsense mit dem WAN-Interface bei mir ins Haus-LAN gehängt, d.h. mein LAN soll der OPNsense als WAN dienen. Einen Windows-Client habe ich ans LAN-Interface der OPNsense gehängt.

Ich habe noch mehrere ähnliche Anleitungen im Netz gefunden, da alle bei mir zum gleichen Problem geführt haben.

Mein Problem ist dabei leider, dass ich auf dem Windows-Client kein Internet bekomme. In den Netzwerk-Parametern (ipconfig) sehe ich auch kein Gateway. Ping an die OPNsense funktioniert nicht, dementsprechend auch kein Ping ins Internet. Ins lokale Netz komme ich auch nicht. Nach meinem Gefühl ist dies ein DNS-Problem. Mit einem Android-Client habe ich die gleichen Probleme.

Was läuft in meiner Konfig falsch?

Hier nochmal meine Konfiguration der OPNsense mit Wireguard:
- Installation des os-wireguard Plugins. Konfig mit 10.10.10.1/24 als Tunnel-Address und 51820 als Listen Port
- Einrichtung des Peers mit 10.10.10.2/32, Einrichtung des Peers im Wireguard-Server
- Einrichtung des Wireguard-Windows-Clients mit Address = 10.10.10.2/32, AllowsIPs = 0.0.0.0/0, Endpoint = LAN-IP des WAN-Interfaces (bei mir 192.168.178.20) mit Port = 51820
- Zuweisung des Wireguard-Interfaces (=WireguardClientServer) und Aktivierung des Interfaces
- Einrichtung einer Firewall-Regel: Quick: Aktiviert, Interface: WAN, Direction: In, TCP/IP-Version: IPv4, Protocol: UDP, Source/Invert: Deaktiviert, Source: Any, Destination/Invert: Deaktiviert, Destination: WAN address, Destination Port Range: 51820
- Einrichtung einer zweiten Firewall-Regel: Quick: Aktiviert, Interface: WireguardClientServer, Direction: In, TCP/IP Version: IPv4, Protocol: Any, Source/Invert: Deaktiviert, Source: WireguardClientServer net, Destination/Invert: Deaktiviert, Destination: Any, Destination Port Range: Any

Viele Grüße
Frank

 

[tiermutter]

Moin,
wird die Verbindung zum WG Server denn hergestellt? Das auf der Sense prüfen oder im Log vom Client. Wireguard hat nämlich die ekelhafte Angewohnheit, dass es immer anzeigt dass die Verbindung steht, auch wenn das nicht der Fall ist.
Der Client ist am LAN der Sense natürlich auch etwas fehl am Platz, sollte aber keinen Abbruch tun.

Außerdem besser Screenshots von der Konfig (wireguard Server und Client) sowie Regeln posten, ist übersichtlicher als Text.

Ein dns Problem wird es nicht sein, da der ping ja auch nicht funktioniert.
Wurde auf dem wg Interface eine Regel erstellt, die etwas erlaubt? Sonst ist prinzipiell ja alles verboten...

 

[r371769]

Hallo, vielen Dank, dass ihr mir helfen möchtet .

Hier die Screenshots der Konfig:
Wireguard-Server:

Wireguard-Client:

Wireguard-Interface:


Firewall-WAN-Rule:


Firewall-Rule-Wireguard-Server:


... weitere Screenshots im nächsten Post

 

[r371769]

Windows-Client-Konfiguration:


Log des Windows-Clients:


Ich habe sonst keine Regel eingerichtet ... Ich habe mich an das Kochrezept vom ersten Post gehalten

 

[tiermutter]

Die Regel auf dem WAN ist obsolet, da der Client ja vom LAN verbindet. Da hier (wahrscheinlich) aber ohnehin alles erlaubt ist, ist das kein Problem. Die Verbindung steht laut Log ja auch.

Ich habe sonst keine Regel eingerichtet ... Ich habe mich an das Kochrezept vom ersten Post gehalten

Ohne Regel die etwas auf dem WG Interface erlaubt geht halt nix. Weder Internet noch irgendwas.
Von wo stammt denn dieses Rezept?

Beim Winclient auch AllowedIPs = 0.0.0.0/1, 128.0.0.0/1 nehmen... Windows mag es nicht gerne die default route überschreiben zu lassen.

Ansonsten sieht das alles korrekt aus.

 

[blurrrr]

Mein Problem ist dabei leider, dass ich auf dem Windows-Client kein Internet bekomme.

Was sagt denn die Firewall dazu? Wenn die Verbindung steht, aber nix geht, wird eine Firewall-Regel blockieren. Am einfachsten dürfte es wohl sein, eine Floating-Rule anzulegen (die steht über den anderen und greift somit auch zuerst), welche als Quelle das Netz der Wireguards-Clients hat (darf dann halt erstmal "alles") und dazu noch das Logging für diese Regel einschalten.

Dazu kommt noch, dass - sofern die *sense kein NAT für das WG-Clients-Netz macht - dass der vorgelagerte Router das Netz auch kennen muss. Alternativ muss mit der WAN-IP der *sense maskiert werden.

Generell gilt: Wenn was nicht tut, wie es soll -> Logging einschalten und nachgucken

 

[tiermutter]

sofern die *sense kein NAT für das WG-Clients-Netz macht

Für IPv4 wird automatisch eine Regel für das outbound NAT erstellt, für IPv6 (ULA) muss diese manuell angelegt werden, aber das ist hier ja (erstmal) irrelevant.

 

[blurrrr]

aber das ist hier ja (erstmal) irrelevant.

Geht so, Internet soll es ja vermutlich auch geben, also gehört das (wohl oder übel) schon mit dazu.

Was ich aber als problematisch erachte: Pakete am WG-Interface dürfen "rein", aber "wo" dürfen sie denn wieder "raus"? Alternativ halt: "Ich darf vom Arbeitszimmer in den Flur, aber niemand hat mir erlaubt, auch nur einen Fuss ins Wohnzimmer zu setzen.", ich bleibe einfach mal bei: "Logging einschalten und nachgucken"... Zum Testen kann man ja ggf. auch eine Regel setzen á la: "WG-Client-Netz darf überall hin" (als Floating-Rule und auch dort das Logging einschalten)

 

[tiermutter]

Geht so, Internet soll es ja vermutlich auch geben, also gehört das (wohl oder übel) schon mit dazu.

Es geht um v6 ULA was erstmal irrelevant ist (zumindest ist WG hier nicht für v6 konfiguriert)... v4 NAT braucht es selbstredend schon, aber das wird ja automatisch erstellt...

Was ich aber als problematisch erachte: Pakete am WG-Interface dürfen "rein", aber "wo" dürfen sie denn wieder "raus"?

Sag ich ja:

Ohne Regel die etwas auf dem WG Interface erlaubt geht halt nix. Weder Internet noch irgendwas.

 

[tiermutter]

Wenigstens die gelb markierte Regel muss es geben:

 

[r371769]

Wenigstens die gelb markierte Regel muss es geben:
Anhang anzeigen 5698

Ist das nicht diese Regel?



Was bewirkt die 27er-Maskierung bei Dir?

 

[blurrrr]

Das ist nur "eingehend" am WG-Interface, aber irgendwo müssen die Pakete ja auch wieder "raus". Was das "/27" angeht, guckste hier: CIDR (da weisste dann auch direkt, wieviele IP-Adressen in einem oftmals genutzten /24 verfügbar sind)

 

[r371769]

Juhu, es geht! Ich danke Euch sehr .

Ich habe die Regel mit "meiner" IP 10.10.10.1 eingefügt und nun funktioniert es. Da wäre ich nie alleine draufgekommen . Gibt es aus Eurer Sicht ein besserer Rezept, als das was ich gefunden habe, wo alle notwendigen Schritte enthalten sind?

Dann versuche ich mich an dem nächsten Thema: AdGuard.

 

[blurrrr]

Gibt es aus Eurer Sicht ein besserer Rezept, als das was ich gefunden habe, wo alle notwendigen Schritte enthalten sind?

Klar, jenes, welches Du Dir selbst (mit eigenen Worten) geschrieben hast - da hast Du auch direkt den Vorteil, dass Du Dir das "wieso weshalb warum" dazu notieren kannst

Dann versuche ich mich an dem nächsten Thema: AdGuard.

Viel Erfolg!

 

[r371769]

Viel Erfolg!

Danke

 

[tiermutter]

Die Regel habe ich ob des Interface Namen wohl nicht als solche betrachtet...

Also hast du effektiv das source=WG server net durch die IP des subnet ersetzt, damit es funktioniert?

Das 27er Netz nutze ich, weil ich mehrere VPN habe und möchte, dass alle 10.13.18.x als IP haben.

 

[r371769]

Also hast du effektiv das source=WG server net durch die IP des subnet ersetzt, damit es funktioniert?

Nein, ich habe diese Regel noch zusätzlich hinzugefügt.


Ist das so ok? oder gibt es Einwände?

 

[tiermutter]

Die erste Regel ist dann überflüssig. Sie sagt quasi dasselbe, aber funktioniert offensichtlich nicht.
Tatsächlich verwende ich diese automatischen Aliase (INTERFACENAME net) so gut wie nie, vermutlich eben weil das oft nicht wie gewünscht funktioniert.

Mit dem Inspect Button oben rechts solltest Du bei aktiver Verbindung aber sehen, welche Regel verwendet wird.

Wird die Regel verwendet, sind dort Zahlen >0, wenn States, Packets und Bytes =0 sind, dann wird die Regel (momentan) nicht benötigt, was in Deinem expliziten Fall bedeutet, dass die Regel unnötig ist.

 

[r371769]

Die erste Regel ist dann überflüssig. Sie sagt quasi dasselbe, aber funktioniert offensichtlich nicht.
Tatsächlich verwende ich diese automatischen Aliase (INTERFACENAME net) so gut wie nie, vermutlich eben weil das oft nicht wie gewünscht funktioniert.

Mit dem Inspect Button oben rechts solltest Du bei aktiver Verbindung aber sehen, welche Regel verwendet wird.
Anhang anzeigen 5707
Wird die Regel verwendet, sind dort Zahlen >0, wenn States, Packets und Bytes =0 sind, dann wird die Regel (momentan) nicht benötigt, was in Deinem expliziten Fall bedeutet, dass die Regel unnötig ist.

Danke, schon wieder was gelernt . Du hast Recht durch deinen Tipp konnte ich jetzt sehen, dass die alte Regel nicht funktioniert hat. Ich habe sie rausgenommen.

 

[tiermutter]

Wunderbar
Nicht vergessen: Die bisherige Konfig nur testweise verwenden und nicht in die Produktion übernehmen, da sämtliche Schlüssel hier gepostet wurden...