Opnsense Wireguard (Routing) Probleme

[Porfavorio]

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.

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

Allowed IPs an Standort A: 10.210.0.0/24 (Nach Hinweis in anderem Forum geändert auf /32) sowie 192.168.133.0/24
Allowed IPs an Standort B: 10.210.0.0/24 (Nach Hinweis in anderem Forum geändert auf /32) 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.


Blockierung privater Netze in WAN Schnittstelle Standort A ist deaktiviert.

Wo kann das Problem liegen?

 

[gaym0r]

Standort B ist ein VLAN, d.h. ich habe keinen Router als Standartgateway, wo ich Routen setzen könnte.

Die Aussage versteh ich nicht. Warum sollte es in einem VLAN keinen Router geben?

 

[Porfavorio]

Die Aussage versteh ich nicht. Warum sollte es in einem VLAN keinen Router geben?

Das soll einfach bedeuten, dass ich zwei VPS habe, die per VLAN über die jeweils zweite Netzwerkkarte verbunden sind. Was seitens der Hosters genau geschieht, weiß ich nicht und darauf habe ich auch keinen Einfluss. Ich kenne mich hiermit überhaupt nicht aus und weiß daher auch nicht, ob oder wo ich hier Routen setzen müsste oder ob ich auf der zweiten VM die opnsense als Standardgateway eintragen müsste oder was auch immer.

 

[gaym0r]

Eine statische Route auf vServer 2 nach 192.168.132.0/24 mit next-hop 192.168.133.1 braucht es in dem fall mindestens.

 

[TheCadillacMan]

Allowed IPs an Standort A: 10.210.0.0/24 (Nach Hinweis in anderem Forum geändert auf /32) sowie 192.168.133.0/24
Allowed IPs an Standort B: 10.210.0.0/24 (Nach Hinweis in anderem Forum geändert auf /32) sowie 192.168.132.0/24

Wenn man richtigerweise /32 verwendet muss die IP des jeweiligen Peers eingetragen sein:
A: 10.210.0.2/32,192.168.133.0/24
B: 10.210.0.1/32,192.168.132.0/24

 

[Raijin]

Ich kenne mich hiermit überhaupt nicht aus und weiß daher auch nicht, ob oder wo ich hier Routen setzen müsste oder ob ich auf der zweiten VM die opnsense als Standardgateway eintragen müsste oder was auch immer.

Eine vorsichtige Frage: Kennst du dich denn generell mit Server, Routing, Firewalls und allgemein Sicherheit aus? Oder baust du gerade das nächste Mitglied im Botnetz der nächstbesten Hackergruppe?

In dem anhängenden Schaubild fehlt noch

Das ist natürlich beliebig unpraktisch. Wenn du den status quo in einer Zeichnung darstellst, was grundsätzlich löblich ist, da Wall-Of-Text-Beschreibungen von Netzwerken die Hölle sind, dann solltest du dennoch alles einzeichnen und ggfs nachbessern. Kombinationen aus unvollständigen Zeichnungen mit Textergänzungen sind fast schlimmer als Text-only.





Wenn man zwischen verschiedenen Netzwerken/Subnetzen routet, müssen einige Dinge beachtet werden:

Sofern man kein (S)NAT an den VPN-Endpunkten konfiguriert, müssen alle Teilnehmer der beiden Netzwerke eine Route ins jeweils andere Subnetz haben. Wenn der VPN-Endpunkt gleichzeitig das Standardgateway ist, werden keine weiteren Routen benötigt. Sind Standardgateway und lokaler VPN-Endpunkt unterschiedlich (zB Internetouter + separates VPN-Gerät wie zB ein Raspberry PI) benötigen die Netzwerkteilnehmer entweder allesamt eine eigene separate Route ins gegenüberliegende Subnetz über das VPN-Gateway, was sich zB bei SmartTVs und ähnlichen Geräten schwierig gestaltet, oder aber das Standardgateway bekommt diese Route. Das Endgerät nutzt dann unverändert das Standardgateway, aber dieses routet weiter zum lokalen VPN-Endpunkt, der wiederum ins gegenüberliegende Netzwerk routet.

Darüber hinaus muss natürlich die Firewall der VPN-Endpunkte jeweils die Verbindung ins andere Netzwerk erlauben und auch die Firewalls der Endgeräte selbst müssen Datenverkehr von/zum jeweils anderen Subnetz erlauben. So blockt die Windows-Firewall beispielsweise standardmäßig eingehende Verbindungen, die nicht aus dem eigenen lokalen Subnetz kommen. Dies muss man in der Firewall bei der entsprechenden Regel explizit freigeben (Bereich => Quell-IP = beliebig bzw. Subnetze/IPs eingeben).

 

[Porfavorio]

Ich habe nun sowohl den Hinweis von gaym0r als auch den von TheCadillacMan umgesetzt. Nun sagt mir tracert an Standort B zwar, dass die dortige opnsense erreicht wird, weiter geht's aber nicht.

Kann es sein, dass die Wireguard-Firewallregeln auch auf 10.210.0.1/32 und 10.210.0.2/32 lauten müssen (derzeit: 10.210.0.0/32)?

@Raijin, danke für den Hinweis. Das muss ich gleich noch einmal prüfen. Daran könnte es auch liegen. Ich hatte das zwar angesichts einer anderen Lösung schon einmal gemacht, aber ggf. war das vor einer Änderung des heimischen IP-Adressbereiches.

Ergänzung (23. Mai 2022)

Tausend Dank an Raijin. Das war's - die Firewall am zweiten VPS. Jetzt geht tracert in beide Richtungen durch. Ich teste gleich einmal, ob auch sonst alles funktioniert.

Noch zu deiner Frage: Grundlegende Kenntnisse sind schon vorhanden. Daher soll auch nur die opnsense fürs Internet geöffnet werden (eben für VPN). Kann ich da so viel falsch machen, wenn ich nur die Wireguard Einrichtung vornehme und sonst nichts verändere?

Ergänzung (23. Mai 2022)

Ich verstehe gerade die Welt nicht mehr. Gerade eben ging noch alles und nun - ohne, dass ich noch etwas verändert hätte - nicht mehr. Tracert bleibt wieder an der jeweiligen opnsense hängen.

Ergänzung (23. Mai 2022)

Jetzt geht's wieder - könnte fehlendes "keepalive" die Ursache sein?

 

[Bob.Dig]

Jetzt geht's wieder - könnte fehlendes "keepalive" die Ursache sein?

Wenn der Tunnel nur von einer Seite aufgemacht werden kann, definitiv.

 

[Porfavorio]

Wenn der Tunnel nur von einer Seite aufgemacht werden kann, definitiv.

Er kann von beiden Seiten aufgemacht werden.

 

[Bob.Dig]

Er kann von beiden Seiten aufgemacht werden.

Dafür muss es aber auch auf beiden Seiten richtig konfiguriert sein... 😉

 

[riversource]

Jetzt geht's wieder - könnte fehlendes "keepalive" die Ursache sein?

Hängt denn einer der beiden Knoten hinter einem NAT ohne Portforwarding?

 

[Porfavorio]

Hängt denn einer der beiden Knoten hinter einem NAT ohne Portforwarding?

Wenn es kein Portforwarding gäbe, dann würde doch gar keine Verbindung zustande kommen? Am Standort A ist der Wireguard Port geforwarded, an Standort B ist nichts geforwarded, da habe ich - wie gesagt - keinen Einblick in das, was der Hoster genau macht.

 

[Raijin]

Kann ich da so viel falsch machen, wenn ich nur die Wireguard Einrichtung vornehme und sonst nichts verändere?

Ja. Ein VPS wird je nach Hoster bzw. je nach eingespieltem Image entweder mit einer halbwegs vernünftigen Vorabkonfiguration installiert oder aber komplett nackt und offen.
Es reicht nicht aus, sinngemäß auf "Install OS" zu klicken, anschließend "Install WireGuard" einzutippen und sich dann darauf zu verlassen, dass das schon irgendwie stimmen wird. Du musst zwingend die Firewall prüfen, bei Linux durch iptables/nftables und bei Windows entsprechend über die Windows-Firewall.

Ein Server im www ist wirklich kein Spaß, da musst du wirklich aufpassen. Wie gesagt, genau solche Server sind es, die am Ende als Bot dazu dienen, dass eine Hackergruppe mittels DDoS Behörden lahmlegt oder auch das PSN oder was weiß ich...

 

[Porfavorio]

Auf dem VPS läuft doch opnsense. Muss ich da wirklich noch das dahinterliegende FreeBSD prüfen? Was wäre denn im Hinblick auf einen Windows VPS besonders zu beachten? Könnte ich den nicht komplett vom Internet abkapseln, sodass er nur noch über die zweite NIC (VLAN) erreichbar ist?

 

[riversource]

Auf dem VPS läuft doch opnsense. Muss ich da wirklich noch das dahinterliegende FreeBSD prüfen?

Du musst zumindest prüfen, was OpenSense da macht. Denn bei netcup sind die Server standardmäßig komplett offen. Auch die Windows Server. Die sind genau so gefährlich.

Könnte ich den nicht komplett vom Internet abkapseln, sodass er nur noch über die zweite NIC (VLAN) erreichbar ist?

Das ist die übliche Empfehlung im Netcup Forum für Windows Server. Aber das erfordert natürlich ebenfalls eine geeignete Konfiguration der Firewall des vorgeschalteten Linux Servers.

 

[Raijin]

Auf dem VPS läuft doch opnsense. Muss ich da wirklich noch das dahinterliegende FreeBSD prüfen?

Nein, aber eben die Einstellungen von opnsense. Unter der Haube konfiguriert man darüber ja das eigentliche OS.

Die Sicherheit einer Firewall kommt nicht durch ihre bloße Existenz, sondern durch die Konfiguration. Du musst also sicherstellen, dass die Firewall alles blockt außer den erforderlichen Ports für das VPN.

Selbst sowas vermeintlich harmloses wie ein offener DNS kann großen Schaden anrichten, weil eine DNS Amplification Attack zu den effektivsten DoS-Attacken überhaupt zählt. Sowas wie "Ich nutze pihole auf einem offenen VPS" kann tatsächlich sogar Post von der BundesNetzAgentur nach sich ziehen, nur um mal ein Beispiel zu nennen.

 

[Porfavorio]

Ich war wohl fälschlich davon ausgegangen, dass die Grundinstallation von opnsense erst einmal alles von außerhalb blockt, sofern ich es nicht explizit öffne. Dann muss ich mich damit wohl noch eingehender befassen.

 

[Raijin]

Selbst wenn dem so ist, musst du das IMMER überprüfen. Bedenke, dass ein von dir falsch eingerichteter Server anderen Schaden zufügen kann, wenn du nicht weißt was du da tust. Nur weil ein VPS mit 2 Klicks gemietet und mit einem 3. Klick installiert ist, heißt das noch lange nicht, dass die Administration damit abgeschlossen ist. Damit fängt es erst an. Firewall, ssh und ggfs Dinge wie fail2ban oder dergleichen.

 

[Porfavorio]

Also irgendetwas stimmt da immer noch nicht. Aus irgendeinem Grund fragt der entfernte Server am Standort nicht die opnsense, sondern irgendeine seltsame IP (wie die öffentliche IP des VPS, nur eine andere letzte Ziffer).

Ergänzung (23. Mai 2022)

Das habe ich (wahrscheinlich) mit Veränderungen an der Metrik der beiden NICs gelöst bekommen, sodass nun die jeweilige opnsense erreicht wird. Allerdings hängt es nun da wieder, obwohl der Wireguard-Tunnel aktiv sein sollte.

 

[Raijin]

Die Metrik spielt nur eine Rolle, wenn es zwei gleichwertige Routen zum selben Ziel gibt. Beispielsweise wenn es 2 Schnittstellen gibt und bei beiden ein Standardgateway bzw daraus folgend eine Standardroute gibt, also 2x 0.0.0.0 / 0.0.0.0 via gw1 bzw gw2 Ich vermute stark, dass da irgendwas grundlegendes nicht richtig konfiguriert ist. Ehrlich gesagt kann ich dein Setup weder aus der unvollständigen Zeichnung noch aus deiner Beschreibung wirklich nachvollziehen.