pixelmatrix
Goto Top

Zwei OPNSense, ein VLAN, ein Internetzugang

Guten Tag zusammen,

Bin hier ein stiller Mitleser gewesen und habe mich nun angemeldet, da ich eine Frage habe.

Habe mir durch das lesen im Internet und hier im Forum etwas wissen zum Thema Internet und VPN angeeignet.

Mein Ergebnis ist: 2x OPNsense an je einem Standort, mehrere VLAN, Wireguard VPN für Smartphones und einen Wireguard VPN Site 2 Site.
Alles Funktioniert ohne Probleme.

Nun habe ich einen Anwendungsfall wo ein PC der an Standort A steht, dass Internet von Standort B versenden soll.
Leider weis ich überhaupt nicht wie ich das machen soll. Habe mal gelesen das ich es über das Gateway nach Standort B schicken muss.

Würde gerne dafür ein eigenes VLAN anlegen.

- In der Fritzbox von Standort B sind die Statischen Routen eingetragen und in der OPNsense das Outbound NAT deaktiviert.
- Wireguard Server liegen auf den OPNsensen
- Es gibt ein Wireguard Server für die Clients und einen Wireguard Server für die Side 2 Side Verbindung

Könnte mir jemand helfen?

Hier eine kleine Skizze:
home v2

Vielen Dank

Gruß
Jonas

Content-ID: 670489

Url: https://administrator.de/forum/zwei-opnsense-ein-vlan-ein-internetzugang-670489.html

Ausgedruckt am: 06.01.2025 um 19:01 Uhr

radiogugu
radiogugu 04.01.2025 um 22:16:42 Uhr
Goto Top
Nabend.

Es gibt die Möglichkeit den gesamten Traffic von Site A über den Tunnel zu Site B zu leiten.

Allerdings sehe ich keine Chance einen einzelnen Client von Site A dies tun zu lassen, außer du lässt diesen einen eigenen Tunnel etablieren.

Gruß
Marc
StefanKittel
StefanKittel 04.01.2025 um 23:02:01 Uhr
Goto Top
Hallo,
wie wäre es mit einem Proxy an Standort B. Den konfiguriert man im Browser eines PCs und fertig.
Eine kleine Linux VM mit Squid z.B. oder auch in der xSense konfigurierbar.
Stefan
gastric
gastric 05.01.2025 aktualisiert um 12:57:29 Uhr
Goto Top
Zitat von @radiogugu:
Allerdings sehe ich keine Chance einen einzelnen Client von Site A dies tun zu lassen,
Mit Policy-Routing kein Problem.
https://docs.opnsense.org/manual/firewall.html
Dazu legt man ein GW-Object der anderen Seite an und weist dieses dem Client per Firewall Rule mit DEST (!)RFC1918 Adressliste zu.
Zusätzlich muss man an Standort A in den Wireguard AllowedIPs 0.0.0.0/0 eintragen und man muss das automatische Anlegen der Routen per Wireguard deaktivieren und die gegenüberliegenden Subnetze von Hand anlegen damit nicht sämtlicher Traffic der Site über den Tunnel geht. Beachtet man das dann geht auch nur der Internet-Traffic des einen Clients über den anderen Standort. 😉

Gruß gastric
pixelmatrix
pixelmatrix 05.01.2025 um 13:31:52 Uhr
Goto Top
Hallo,

Danke, für die Antworten. face-smile

Ich könnte noch einen Wireguard Server für den PC erstellen oder ich packe ihn ein ein VLAN was zum Standort B geht.

@gastric
Danke, für den Link.
Glaube das ist noch etwas hoch für mich. Bin noch nicht der Profi face-smile

Wo lege ich das Gateway Objekt an (Standort B?) und wie muss es aussehen?
Beim Standort A vom Peer der Side 2 Site Verbindung lösche ich die freigegebenen Subnetze und trage 0.0.0.0/0 für alle IP Adressen erlauben ein.

Grüße
Jonas
gastric
gastric 05.01.2025 aktualisiert um 14:16:43 Uhr
Goto Top
Zitat von @pixelmatrix:

Hallo,

Danke, für die Antworten. face-smile

Ich könnte noch einen Wireguard Server für den PC erstellen oder ich packe ihn ein ein VLAN was zum Standort B geht.
Überflüssig wenn das Routing doch sowieso schon steht 🙂.
Wo lege ich das Gateway Objekt an (Standort B?)
Natürlich an Standort A
und wie muss es aussehen?
Neues GW Object mit Nexthop 10.2.2.2
Beim Standort A vom Peer der Side 2 Site Verbindung lösche ich die freigegebenen Subnetze und trage 0.0.0.0/0 für alle IP Adressen erlauben ein.
  • In der Site2Site an Standort A 0.0.0.0/0 hinterlegen und das automatische Erstellen der Routen deaktivieren.
  • Für die Netze die es in Standort B gibt statische Routen an Standort A anlegen welche auf die 10.2.2.2 als GW zeigen.
  • Dann noch eine Firewall Adressliste erstellen die alle privaten Netze nach RFC1918 beinhaltet.
  • Dann eine Firewall Regel erstellen die vor allem anderen steht und als SRC die IP des Clients beinhaltet, als DST die RFC1918 Adressliste aber Haken bei "Inverted" setzen, und als GW das angelegte GW-Objekt in der Regel hinterlegen.
  • Dann noch sicherstellen daß auf der Fritte an Standort B eine Route zum LAN Subnetz von Standort A hinterlegt ist.
  • Fertig.
Spirit-of-Eli
Spirit-of-Eli 05.01.2025 um 14:48:24 Uhr
Goto Top
Zitat von @gastric:

Zitat von @radiogugu:
Allerdings sehe ich keine Chance einen einzelnen Client von Site A dies tun zu lassen,
Mit Policy-Routing kein Problem.
https://docs.opnsense.org/manual/firewall.html
Dazu legt man ein GW-Object der anderen Seite an und weist dieses dem Client per Firewall Rule mit DEST (!)RFC1918 Adressliste zu.
Zusätzlich muss man an Standort A in den Wireguard AllowedIPs 0.0.0.0/0 eintragen und man muss das automatische Anlegen der Routen per Wireguard deaktivieren und die gegenüberliegenden Subnetze von Hand anlegen damit nicht sämtlicher Traffic der Site über den Tunnel geht. Beachtet man das dann geht auch nur der Internet-Traffic des einen Clients über den anderen Standort. 😉

Gruß gastric

Genau so. Policy Based geht das z.B auch mit nur einer IP oder gar einem Alias.

Zu ergänzen ist, dass auf Seite B beim Breakout dann noch eine Outbound NAT Rule für das Source Netz erforderlich ist.
gastric
gastric 05.01.2025 aktualisiert um 15:16:34 Uhr
Goto Top
Zitat von @Spirit-of-Eli:
Zu ergänzen ist, dass auf Seite B beim Breakout dann noch eine Outbound NAT Rule für das Source Netz erforderlich ist.
Wenn er dort zur Fritzbox routet und auf der Fritzbox sämtliche statische Routen hinterlegt hat ist das nicht nötig, denn er schrieb

In der Fritzbox von Standort B sind die Statischen Routen eingetragen und in der OPNsense das Outbound NAT deaktiviert.

Wenn es auf der Fritze also auch eine Route für das Netz an Standort A gibt läuft es auch ohne überflüssiges NAT.
Spirit-of-Eli
Spirit-of-Eli 05.01.2025 um 15:59:58 Uhr
Goto Top
Sicher das ne Fritte das kann? Dann müsste die Fritte ja automatisch für statische Routen natten.
Das wage ich zu bezweifeln. Das NAT ist nur bei IPv6 überflüssig!
gastric
gastric 05.01.2025 aktualisiert um 16:10:05 Uhr
Goto Top
Zitat von @Spirit-of-Eli:

Sicher das ne Fritte das kann?
Logisch, statische Routen kann sie problemlos ...
Dann müsste die Fritte ja automatisch für statische Routen natten.
Ausgehend ins WAN NATed sie alle Netze die sie kennt. Und ja das klappt einwandfrei, bei nem Kollegen schon so umgesetzt.
Spirit-of-Eli
Spirit-of-Eli 05.01.2025 um 16:10:14 Uhr
Goto Top
Ja da bin ich dann mal gespannt..
commodity
commodity 05.01.2025 um 16:41:29 Uhr
Goto Top
Prinzipiell ist policy based routing der korrekte Weg, das universell einzurichten. Da (wenn) es sich hier aber nur um einen einzelnen Client handelt und der Tunnel schon steht, sollte das Ziel des TO fürs erste auch sehr einfach über ein im Client angelegtes Routing realisiert werden können:

Beispiel:

Lokales Netz (Standort A): 192.168.1.0/24
Gateway im lokalen Netz: 192.168.1.1 (OPNsense)
entferntes Netz (Standort B): 192.168.20.0/24
WG-Gateway im entfernten Netz: 10.2.2.2

Auf dem Client:

# Hautproute = prinzipiell alles zum entfernten Gateway
route -p add 0.0.0.0 mask 0.0.0.0 10.2.2.2
# Route für das lokale LAN (da diese Route spezifischer ist, wird sie bevorzugt)
route -p add 192.168.1.0/24 mask 255.255.255.0 192.168.1.1

# Überprüfung
route print

fertig face-smile

Auch für einige wenige Clients kann man das gut so machen. Der erfahrene Netzwerker findet das natürlich zu Recht dirty face-big-smile
Nachteil ist insbesondere, dass der Traffic nicht mehr über die Firewall läuft, sondern sozusagen an dieser vorbei. Man kann das aber in der Firewall der Gegenstelle berücksichtigen. Auch beim Debuggen ist diese dirty-Lösung nicht unbedingt förderlich. Aber als Hilfe, bis policy based routing erarbeitet wurde oder für einfache kleine Netze mag es genügen.

Viele Grüße, commodity