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:
Vielen Dank
Gruß
Jonas
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:
Vielen Dank
Gruß
Jonas
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
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
11 Kommentare
Neuester Kommentar
Zitat von @radiogugu:
Allerdings sehe ich keine Chance einen einzelnen Client von Site A dies tun zu lassen,
Mit Policy-Routing kein Problem.Allerdings sehe ich keine Chance einen einzelnen Client von Site A dies tun zu lassen,
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
Zitat von @pixelmatrix:
Hallo,
Danke, für die Antworten.
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 🙂.Hallo,
Danke, für die Antworten.
Ich könnte noch einen Wireguard Server für den PC erstellen oder ich packe ihn ein ein VLAN was zum Standort B geht.
Wo lege ich das Gateway Objekt an (Standort B?)
Natürlich an Standort Aund wie muss es aussehen?
Neues GW Object mit Nexthop 10.2.2.2Beim 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.
Zitat von @gastric:
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
Zitat von @radiogugu:
Allerdings sehe ich keine Chance einen einzelnen Client von Site A dies tun zu lassen,
Mit Policy-Routing kein Problem.Allerdings sehe ich keine Chance einen einzelnen Client von Site A dies tun zu lassen,
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.
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 schriebZu ergänzen ist, dass auf Seite B beim Breakout dann noch eine Outbound NAT Rule für das Source Netz erforderlich ist.
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.
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.
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:
fertig
Auch für einige wenige Clients kann man das gut so machen. Der erfahrene Netzwerker findet das natürlich zu Recht dirty
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
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
Auch für einige wenige Clients kann man das gut so machen. Der erfahrene Netzwerker findet das natürlich zu Recht dirty
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