Wireguard routing ins Heimnetz

[bdb]

Ich verzweifle gerade ein wenig am Wireguard routing, bzw. bin mir relativ sicher das es an meinem Unverständnis liegt.

Hab in meinem Heimnetz eine opnsense firewall auf der ein Wireguard VPN und Adguard home laufen sollen. Diese hängt an einem Router. Dieser soll auch weiterhin die Einwahl ins Internet erledigen. Möchte opnsense nur nutzen um mit Wireguard von ausserhalb ins lokale Netz zu kommen und den Adblocker verwenden.

Zusammengefasst soll opnsense als Unterbau für den Wireguard VPN und Adguard home dienen.

So nun zur Frage:

Das lokale Netz ist 192.168.1.0 (wobei der Router die 192.168.1.1 hat und opnsense 192.168.1.2). Die Wireguard Schnittstelle ist 10.168.0.1, die clients bekommen dementsprechend 10.168.0.2 usw.

Vom Client kann ich mit der ip 10.168.0.1 opnsense öffnen. Ich bekomme allerdings keine Zugriff auf das 192.168.1.0 netz. Kann also nicht auf den Router und das NAS zugreifen welches sich in diesem netz befinden.

Kann mir jemand spontan sagen wo mein Denkfehler ist?

Vielen Dank!

 

[nitech]

Ich kenne opensense nicht so gut, aber es muss irgendwo dann ein routing von 10.168.0.0 nach 192.168.1.0 erstellt sein, übrlicherweise sollte das beim Einrichten des Wireguard automatisch gemacht werden?
mfg

 

[Masamune2]

Routing musst du keins einstellen da der OpnSense alle Netze bekannt sind und alles andere ans Default Gateway gehen. Was du aber machen musst ist die Firewall entsprechend öffnen sonst wird der Traffic halt gedroppt.

Ansonsten solltest du noch auf deinem Internet Router eine Route 10.168.0.0/24 zu Gateway 192.168.1.2 eintragen damit die Pakete von deinem Heimnetz auch in den Tunnel kommen wenn das relevant sein sollte.

 

[spcqike]

Du musst deine OPNSense Firewall natürlich auch so einstellen, dass der Traffic zwischen den Netzen "Wireguard" und "WAN" entsprechend erlaubt ist.

Um zu analysieren, was passiert, oder auch nicht passiert, guck einfach mal im Reiter Firewall bei den Logs im Live-View, was passiert
https://jrs-s.net/wp-content/uploads/2020/01/opnsense-firewall-live-view.png

Einfach mal nach Quell-IP oder Ziel-IP filtern und gucken, was mit den Paketen passiert.
Wenn deine Firewallregeln stehen und der eingehende und ausgehende Traffic auf den Interfaces erlaubt ist, sollte eigentlich alles passen. OPNSense maskiert in der Regel auf seinem WAN Interface (so wie jede Firewall). Damit sollte das Paket, das bei der 192.168.1.10 ankommt, so aussehen, als wäre es von der 192.168.1.2 abgeschickt. die Rückroute ist dann ja bekannt.

Maskiert OPNSense hier nicht, kommt das Paket ja von der 10.168.0.2. Mit der IP kann die 192.168.1.10 aber nichts anfangen. Dann brauchst du tatsächlich noch die statische Route auf deiner ersten Firewall.


Frage am Rande. Warum 2 Firewalls? Ich kann verstehen, dass du den ersten Router als Modem weiter verwenden willst (mache ich auch). Man kann doch aber OPNSense als exposed Host eintragen und nur OPNSense als Firewall für das Netzwerk nutzen. ansonsten finde ich eine OPNSense Firewall, nur als WireGuard Gateway zu nutzen, irgendwie überdimensioniert und kompliziert einzurichten.

 

[bdb]

Danke an alle für die Hilfe.

@spcqike

Meine erste idee war ein ubuntu server mit Wireguard VPN und Adblock home. Ich muss zugeben das meine Linux Kenntnisse eher bescheiden sind. Dort die Firewall regeln in der Konsole eingeben waren wenig erfolgreich. Da bin ich auf OPNSense gekommen. Aber im Prinzip korrekt, ich benötige die Firewall eigentlich nicht.

Die firewall lässt einen zugriff ins andere Netz zu, siehe live log (steht bei allow):

WG1 2022-10-06T10:52:29 10.168.0.2:65400 192.168.1.1:53 udp

mein Browser sagt aber:

ERR_NETWORK_ACCESS_DENIED

ein Ping zu 192.168.1.1 bringt einen "allgemeinen Fehler"

 

[spcqike]

welchen allgemeinen Fehler soll ein Ping denn bringen? mehr als ein Timeout bzw. 100% package loss kann es ja nicht werden.
was sagt denn ein traceroute?

und wie gesagt, behalte, solange du dir nicht sicher bist, dass alle Firewallregeln korrekt stehen, den Live-View im Auge. nur weil UDP Port 53 (DNS) erlaubt ist,heißt das nicht, dass automatisch auch alles andere erlaubt ist.


Ich verwende OPNSense als primäre Firewall für mein Netzwerk. davor geschalten ist die Fritzbox als Modem und Telefon. (meine OPNSense Firewall ist der exposed Host, der alles ungefiltert aus dem Internet bekommt) Das geht aber nur, wenn man kein WLAN braucht oder andere Access Points hat.

Solltest du die Einrichtung von OPNSense nicht hinbekommen, kannst du dir ja noch einmal PiVPN angucken.
https://docs.pivpn.io/
das sollte eigentlich alle notwendige Konfiguration für dich übernehmen. Tutorials gibt es sicherlich auch zu Hauf.

 

[bdb]

tracert zu 192.168.1.1 bringt eben den "Allgemeiner Fehler"

Mit aktivem VPN "kennt" er die 192.168.1.1 aber:

Routenverfolgung zu heise.de [193.99.144.80]
über maximal 30 Hops:

1 1 ms 1 ms 1 ms 10.168.0.1
2 2 ms 2 ms 2 ms DD-WRT [192.168.1.1]
3 3 ms 1 ms 2 ms XXX
4 2 ms 2 ms 2 ms XXX
5 5 ms 5 ms 6 ms cr-han2-pwether10245.x-win.dfn.de [188.1.245.17]
6 13 ms 11 ms 11 ms cr-fra2-be12.x-win.dfn.de [188.1.144.133]
7 14 ms 14 ms 15 ms be100.c350.f.de.plusline.net [80.81.193.132]
8 15 ms 17 ms 15 ms 82.98.102.83
9 15 ms 16 ms 15 ms 82.98.102.40
10 14 ms 14 ms 15 ms 82.98.102.65
11 15 ms 14 ms 15 ms 212.19.61.13
12 14 ms 13 ms 16 ms redirector.heise.de [193.99.144.80]

Danke für den Tipp mit PiVPN aber im prinzip läuft ja alles. wireguard baut ne verbindung auf. Der adblocker läuft.

Mir fällt es schwer da jetzt aufzugeben

EDIT

Live-View zeigt für den client der VPN Verbindung nichts geblocktes an.

 

[Raijin]

Grundsätzlich und unabhängig vom vorliegenden Problem möchte ich dir dringend raten, das Subnetz für dein Heimnetzwerk zu ändern. 192.168.1.0/24 ist neben 192.168.0.0/24 das mit großem Abstand am weitesten verbreitete private Subnetz überhaupt, weil diese beiden Subnetze auf gefühlt 90% aller Router am Markt das Standardsubnetz ist. Die Wahrscheinlichkeit, dass du unterwegs in einem fremden Netz eben dieses Subneth vorfindest, ist relativ hoch. In diesem Fall wirst du dann große Probleme bekommen, über das VPN auf dein Heimnetzwerk zuzugreifen, weil lokales Subnetz und Heim-Subnetz identisch sind und dann eben nicht zum Heimnetzwerk geroutet wird, sondern lokal...

Wenn man mit VPN arbeitet sollte man sich daher nicht künstlich auf so ein Standardsubnetz beschränken, sondern kreativ sein und ein ungewöhnliches Subnetz wählen, um die Wahrscheinlichkeit eines Konflikts mit dem lokalen Netzwerk des VPN-Clients zu minimieren.

RFC1918 sieht folgende Bereiche für private Netzwerke vor:

192.168.0.0 - 192.168.255.255
172.16.0.0 - 172.31.255.255
10.0.0.0 - 10.255.255.255

Sei kreativ und bau beispielsweise ein Subnetz anhand eines Geburtrtags, zB 172.23.4.0/24 für den 23.4.



Auch wenn die Fehlermeldung "Allgemeiner Fehler" eigentlich nicht unbedingt auf einen derartigen Konflikt hindeutet, solltest du dennoch mal überprüfen in welchem lokalen Subnetz sich der VPN-Client befindet.

Ergänzung (6. Oktober 2022)

Mit aktivem VPN "kennt" er die 192.168.1.1 aber:

Das ist ein Trugschluss. Traceroute ist ein Ping mit begrenzter Lebensdauer in Form von Anzahl an Hops. Es mag so aussehen als wenn du mit tracert die 192.168.1.1 "siehst", aber das ist rein passiv. Der Ping hat als Ziel 193.99.144.80 und sonst nix. Dass man die einzelnen Hops sieht - auch die 192.168.1.1 - liegt lediglich daran, dass bei einem Trace die Lebensdauer des Pings begrenzt wird damit ihm ganz bewusst mittendrin die Puste ausgehen soll, um eine Reaktion des Hops an dieser Stelle zu provozieren. Es wird KEIN PING an 192.168.1.1 gesendet und somit ist ein Trace auf heise.de auch in keinster Weise aussagekräftig in Bezug auf das Routing zu 192.168.1.0/24.

 

[spcqike]

192.168.1.0/24 ist neben 192.168.0.0/24 das mit großem Abstand am weitesten verbreitete private Subnetz überhaupt

Da ist AVM aber nicht mit einverstanden haben die nicht angeblich 70% Anteil und nutzen sie nicht 192.168.178.0/24?

@bdb bist du sicher dass Maskieren an ist und falls nicht, hast du die statische Route im ersten Router eingetragen? Bzw kannst du irgendein Gerät aus dem 192.168.1.0/24 Netzwerk erreichen? Der tracert sieht ja so aus als würdest du den Router erreichen und als könntest du nach extern durch das VPN kommen.

Vielleicht hilft es auch, wenn du mal Screenshots bzw. deine configs teilst. Wie sehen die Firewall regeln in opnsense aus? Im interface WireGuard Und WAN. Wie deine ausgehende NAT regeln? Welche config hast du für WireGuard überhaupt. Welche allowedips?

 

[Raijin]

AVM ist quasi Deutschland only. Jenseits deutscher bzw deutschsprachiger Grenzen spielt AVM keine Rolle. Wenn ich von 90% der privaten Subnetze spreche, dann meine ich damit die ganze Welt mit ihren 7,5 Milliarddn Bewohnern

Aber natürlich zählt auch das Standard-Fritzbox-Subnetz zu den (in DACH) am weitesten verbreiteten Subnetzen - so wie mutmaßlich auch 192.168.2.0/24, das von Speedports und wenn ich mich nicht irre auch von O2 easyboxxen verwendet wird.

Ergänzung (6. Oktober 2022)

Zur Untersuchung des vorliegenden Problems würde ich in der OPNsense in den Diagnostics ein Packet Capture / tcpdump starten und auf ICMP filtern. Anschließend vom VPN-Client aus die 192.168.1.1 pingen - nein, kein traceroute auf heise.de. Kommt am Wireguard Interface der Ping vom Client an, ist das Routing des Clients ok. Geht der Ping aber am lokalen Interface der OPNsense nicht raus, routet OPNsense nicht richtig. Geht der Ping hingegen am lokalen Interface Richtung 192.168.1.1 raus, aber der Reply kommt nicht wieder rein, blockt bei 192.168.1.1 dessen Firewall oder es gibt keine Rückroute für die Antwort.

 

[cbmik]

Grundsätzlich und unabhängig vom vorliegenden Problem möchte ich dir dringend raten, das Subnetz für dein Heimnetzwerk zu ändern. ..... Die Wahrscheinlichkeit, dass du unterwegs in einem fremden Netz eben dieses Subneth vorfindest, ist relativ hoch. In diesem Fall wirst du dann große Probleme bekommen, über das VPN auf dein Heimnetzwerk zuzugreifen, weil lokales Subnetz und Heim-Subnetz identisch sind und dann eben nicht zum Heimnetzwerk geroutet wird, sondern lokal...

Gibt es dafür nicht NAT ?

 

[Raijin]

Jein. Wie definierst du NAT? Die meisten meinen bei NAT eigentlich SNAT (SourceNAT), weil es das ist, was der Router daheim mit der Internetverbindung macht (hier meist in Form von "masquerade").

Das hilft in diesem Fall aber nicht, weil das Problem bereits bei der Quelle entsteht, dem VPN-Client. Wenn man die Problematik der identischen Subnetze lokal und remote mit NAT lösen möchte, muss man DNAT (DestinationNAT) am VPN-Server einrichten. Dabei wird quasi ein Fake-Subnetz verwendet und der VPN-Server (D)NATtet dieses in das richtige Subnetz. Statt 192.168.1.x für das heimische NAS gibt man am VPN-Client dann beispielsweise 10.11.12.x ein und der VPN-Server übersetzt das bzw. leitet korrekt an das NAS weiter..

NAT ist aber in den meisten Fällen nur als Workaround anzusehen und ersetzt kein sauberes Subnetzdesign. Wer also mit VPN arbeitet, sollte sich generell angewöhnen, möglichst ungewöhnliche Subnetze zu verwenden, um Konflikte im Keim zu ersticken und einen NAT-Workaround gar nicht erst notwendig zu machen.

Allerdings möchte ich an dieser Stelle nicht weiter ins Detail gehen, weil das den Rahmen des Threads sprengen und nur Verwirrung stiften würde. Einfach die goldene Regel beachten, kein Standard-Subnetz zu verwenden, und man muss keinen Gedanken an NAT verschwenden. Das Ändern des Subnetzes kann auch Otto Normal bewerkstelligen, indem er am Router die lokale IP und den DHCP-Server ändert. Einmal alle Geräte neustarten und ggfs für Drucker, o.ä. eine neue Reservierung erstellen und gut ist. NAT für VPN? Klar, man kann blind Tutorials abtippen und irgendwelche kryptischen iptables Kommandos eingeben und wundert sich dann, dass es trotzdem nicht klappt, weil die Kommandos eben nicht 1:1 passen.