Regel für Wireguard client zu anderem wireguad Netz

[bforpc]

Hallo,

keiner eine Idee?


Bfo

[johnsmi]

Zugriff erlaubt, Route unbekannt?


Verstehe ich das richtig so:

Hausnetz 192.168.1.0/24 mit 10.10.10.0/24 WireGuard Clients.

Ein besonderer Client 10.10.10.2/32
kommt aus dem "entfernten" Netz 192.168.2.0/24
und bildet die einzige Verbindung zwischen den Netzen.

d.h.
das Netz 192.168.2.0/24 ist dem Netz 192.168.1.0/24 und der Default-Route nicht bekannt.


Gibt es eine Route 192.168.2.0/24 mit Gateway 10.10.10.2 im Hausnetz?


1.
System: Gateways: Single
10.10.10.2

2.
System: Routes: Configuration
192.168.2.0/24

[bforpc]

Moin,

Ja, du hast alles richtig verstanden.

Noch eine Frage:
Ich bin mir immer noch nicht sicher, was in "allowed IP's" vom Wireguard auf der Firewall und auf dem entfernten Wireguard Client stehen soll.

>1.
>System: Gateways: Single
>10.10.10.2

Code: [Select]

The gateway address "10.10.10.2" does not lie within one of the chosen interface's IPv4 subnets.
Ich habe als Interface nur LAN und WAN.

>2.
>System: Routes: Configuration
>192.168.2.0/24

habe ich jetzt auf GW_WAN gesetzt.

Bfo

[johnsmi]

Moin,

wenn alle WG-Clients im Hausnetz 10.10.10.0/24 auf alles im 192.168.2.0/24-Netz zugreifen dürfen:
Firewall: Rules: wireguard_wg0
Source "wireguard_wg0 net"
Destination "192.168.2.0/24"
ggf. Hosts und Ports einschränken.



Das Gateway 10.10.10.2 mit Interface wireguard_wg0 erstellen.

Vom Hausnetz 192.168.1.0/24 führt die Route in das 192.168.2.0/24-Netz nur durch das neu erstellte Gateway 10.10.10.2. Das WAN-GW kennt den Weg dorthin nicht, nur der Client der in beiden Netzen ein Bein hat kennt das Netz.

[bforpc]

Hallo johnsmi,

zuerstmal danke für deine Hilfe (die bist bisher der einzige der etwas produktives geschrieben hat):
Leider kann ich dir nicht ganz folgen.

• Ich kann kein "System: Gateways: Single , 10.10.10.2" erstellen wegen diesem Fehler:
  The gateway address "10.10.10.2" does not lie within one of the chosen interface's IPv4 subnets.
• Ich habe eine zweite FW Regel erstellt, die erste existierte bereits (siehe Bild)
• In den Schnittstellen existiert ein Interfaces Namens OPT1 (lässt sich nicht umbenennen) mit der MAC Adresse 6*00 und der
  internen Bezeichnung "wg0"

Im wiregurd Client 10.10.10.2 / 192.168.2.1 habe ich in AllowedIPs = 10.10.10.0/24,192.168.1.0/24
Auf opnSense Seite dieses Clients (endpoint) habe ich in AllowedIPs = 10.10.10.2/32,192.168.1.0/24, 192.168.2.0/24


Könntest du bitte mir (und allen die das gleiche Problem haben) etwas genauer erklären, was ich wo und auch in welcher Reihenfolge eingeben muss?


Nfo

[johnsmi]

OK, Ich versuche es nochmal.


=== Routing ===
Mein Fehler: Die Route auf das wg0-Interface wird automatisch erstellt. Die Definition erfolg über den Tunnel-Endpoint.

Das, was nicht automatisch erstellt wurde bitte wieder entfernen. Sorry. Die Route gibt es schon.

Am Ende unter "System: Routes: Status" kontollieren dass in der Spalte Gateway "wg0" auftaucht. Dort steht dann Destination "192.168.2.0/24".



=== Firewall ===
OK, wenn das auch schon da war, dann ist es jetzt doppelt. Die zweite Regel ist in der ersten bereits enthalten: 10.10.10.0/24 ist das Wireguard-Netz und "nach überall" schließt 192.168.2.0/24 mit ein.

Die Regeln funktionieren erstmal. Sobald alles funktioniert kann man das Feintuning später erledigen. Welcher Client wohin darf usw.



=== WireGuard ===
https://wiki.opnsense.org/manual/how-tos/wireguard-client.html
https://wiki.opnsense.org/manual/how-tos/wireguard-s2s.html


Wir haben ein WireGuard-Netz 10.10.10.0/24 mit dem WireGuard-Server 10.10.10.1/24 (Local -> Tunnel Address).

Z.B. ein Client 10.10.10.20/32 aus einem fremden, unverschlüsselten WLAN lässt/schickt ALLES 0.0.0.0/0 in den Tunnel. Der Server akzeptiert das, was vom Client selbst kommt.
* Allowed IPs Server Endpoint: 10.10.10.20/32
* Allowed IPs Client Endpoint: 0.0.0.0/0
Am Client: DNS-IP-Adresse (z.B. 10.10.10.1)
Wenn das lokale Netz des Clients nicht gebraucht bzw. gewollt ist, dann geht ganz einfach alles durch den Tunnel ins Heimnetz.

Ein Client 10.10.10.30/32 z.B. aus dem Büro-Netz lässt das in den Tunnel, was für die Netze 192.168.1.0/24 und 10.10.10.0/24 bestimmt ist, der Rest bleibt im lokalen Client-Netz. Der Server lässt nur das aus dem Tunnel in sein Netz, was vom Client selbst kommt.
* Allowed IPs Server Endpoint: 10.10.10.30/32
* Allowed IPs Client Endpoint: 192.168.1.0/24, 10.10.10.0/24

Ein Client 10.10.10.40/32 aus einem weiteren Netz schickt das in den Tunnel, was für die Netze 192.168.1.0/24 und 10.10.10.0/24 bestimmt ist, der Rest bleibt im lokalen Client-Netz. Der Server lässt das durch den Tunnel, was für das Netz 192.168.2.0/24 und den Client selbst bestimmt ist.
* Allowed IPs Server Endpoint: 10.10.10.40/32, 192.168.2.0/24 - aus dem Tunnel in die Firewall und Gegenrichtung
* Allowed IPs Client Endpoint: 192.168.1.0/24, 10.10.10.0/24 - vom Client in den Tunnel

Also: 192.168.1.0/24, 192.168.2.0/24, 10.10.10.0/24.2/32 auf der Firewall für den Verbindungsclient als Allowed IPs.

Damit ist festgelegt wohin etwas geschickt wird und von wem es akzeptiert wird.

In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table, and when receiving packets, the list of allowed IPs behaves as a sort of access control list.

https://www.wireguard.com/#conceptual-overview


Ich hoffe mal das ist jetzt nicht noch verwirrender als nötig.

[bforpc]

Hallo johnsmi,

vielen Dank für die sehr wertvollen Infos. Die "allowed IP's" habe ich jetzt so gesetzt wie im 3. Beispiel von dir.
Also:
Serverseitig 10.10.10.2/32 und 192.168.2.0/24, Clientseitig 10.10.10.0/24 und 192.168.1.0/24

Soweit habe ich jetzt alles gemacht, bzw. eigentlich habe ich garn nicht so viel gemacht, denn alles wurde automatisch erstellt.
In der Anlage sende ich die das Bild der aktuellen Routingtabelle, gefiltert auf das wg0 Interface. Das sieht für mich soweit alles richtig aus.

Ich komme vom WG Clienten auf das 192.168.1.0/24 Netz (war vorher auch so), und - neu - ich komme aus dem Heimnetz (192.168.1.0/24) auf die 10.10.10.2 (der WG Client des Netzes 192.168.2.0/24).

Ich komme aus meinem Heimnetz aber nicht auf das 192.168.2.0/24 Netz oder den WG Clienten 192.168.2.1
Das heisst, hier stimmt die Route noch nicht.

Noch eine Info:
Ein tracert auf 192.168.2.1 geht "jetzt" an die FW, bzw. das GW (also die opnsense). Vorher versuchte er das im INternet auf zu lösen (was ja falsch ist).

Jan

[johnsmi]

Das Routing stimmt, tracert geht ja zum Tunnel.


Was läuft denn auf 10.10.10.2 so als Firewall und OS? Antwortet der Client auf ping?

Ich meine Windows beantwortet nur Pings aus dem direkt verbundenen Netz.
Also auf 10.10.10.2 ICMPv4 inbound aus den Netzen 192.168.0.0/16 172.16.0.0/20 und 10.0.0.0/8 erlauben.



Auf der opnsense beobachten was ankommt bzw. durchgeht beim ping von den Clients aus den verschiedenen Netzen.
Interfaces: Diagnostics: Packet Capture

Interface: wg0
Address Family: IPv4
Protokoll: ICMP

[start]

... ping, tracert ...
10.10.10.2
192.168.2.1
192.168.2.x

[stop]

[View Capture]


Dort sollten dann ICMP echo request und idealerweise ICMP echo reply mit den Addressen auftauchen.

[bforpc]

Moin,

auf dem WG Client ist ein Debian 10 im Einsatz, welches hinter einer Fritzbox liegt. Auf dem Debian selbst sind keine iptables Regeln aktiv. Der Port für den Wireguad Tunnel ist an der Fritzbox natürlich offen (sonst würde der Tunnel ja zur opnSense nicht gehen). Der Debain antwortet auf Pings.

In "Interfaces: Diagnostics: Packet Capture" habe ich keine Schnittstelle "wg*", nur LAN und WAN.
Somit kann ich dieses Interface gar nicht belauschen.

Ich habe weiter in den Interfaces nach dem WireGuard Interface geschaut. Dieses war deaktiviert.
Wenn ich es aktiviere, haben die Wireguard Clients keine Verbindung mehr zur openSense und dem Netz 192.168.1.0/24 (dem Heimnetz).
Wenn ich es dann wieder deaktiviere, muss ich den WIreguad Dienst auf der opnSense und die Clients neu starten, damit wieder eine Verbindung besteht.


Wenn ich WAN & LAN belausche und ein Ping sende (von Host 192.168.1.1 hinter der opnSense Firewall), bekomme ich das:

Code: [Select]

LAN
vtnet0 07:29:00.620898 IP 192.168.1.1 > 192.168.2.1: ICMP echo request, id 10649, seq 16, length 64


Bfo

[johnsmi]

OK, wg0 ist das Interface, [Wireguard] ist die Gruppe bei den Firewll-Regeln.



Die Baustelle ist eher Debian.


Wenn das Debian-Wireguard-Interface wg0 ist, dann auf der debian-shell:
$ sudo tcpdump -n -i wg0 icmp

Dann ping auf:
10.10.10.2
192.168.2.1




iptables oder nftables?

icmp ACCEP wäre scho mal hilfreich. Dazu FORWARD von wireguard ins Netzwerk.

[bforpc]

Moin,

also dass das wg Interfave in der opnSense deaktiviert ist, ist wirklich korrekt?
OK, hier die tcpdumps / pings:
Auf 192.168.2.1 / 10.10.10.2
tcpdump -n -i wg0 icmp

Code: [Select]

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
07:08:23.785880 IP 192.168.1.1 > 10.10.10.2: ICMP echo request, id 18012, seq 1, length 64
07:08:23.785937 IP 10.10.10.2 > 192.168.1.1: ICMP echo reply, id 18012, seq 1, length 64
07:08:24.787613 IP 192.168.1.1 > 10.10.10.2: ICMP echo request, id 18012, seq 2, length 64
07:08:24.787665 IP 10.10.10.2 > 192.168.1.1: ICMP echo reply, id 18012, seq 2, length 64

Von 192.168.1.1 Ping an 10.10.10.2 ging (siehe oben), auf 192.168.2.1 keine Antwort

Bfo

[johnsmi]

Bei mir habe ich eine feste MTU vorgegeben, das geht nur auf dem Interface. Die Firewall-Regeln habe ich auch auf dem interface.

also dass das wg Interfave in der opnSense deaktiviert ist, ist wirklich korrekt?

Keine Ahnung. "Eigentlich" funktioniert das mit der Firewall-Gruppe ja auch mit den Default-Einstellungen. Wie das exakt im Hintergrund abläuft weiß ich nicht.

Ausprobieren?

Firewall Regel "any to any" anlegen
* auf dem wg0-Interface
* in der WireGuard-Fruppe
* Floating mit den beiden wireguards

Ping ist eh inbound auf dem LAN-Interface und zurück statefull. Geht ja auch mit dem Endpoint.



Ich vermute wie gesagt eher, daß die debian-Box nicht mitspielt. Die antwortet auf dem wg-Interface nicht auf pings auf das LAN-Interface. Das Routing zwischen den beiden Interfaces muß auch ja irgendwo konfiguriert sein.