IP Weiterleitung/Tunneln OPNSense

Weiß jemand, wie ich meinen WireGuard-IP-Transitpool so erweitern kann, dass ich mehrere Endpunkte habe und die IP-Bereiche sowohl bei mir lokal als auch auf den Gegenstellen nutzbar sind?
Ich möchte dabei insgesamt drei Punkte verwenden:

  • meinen zentralen Knoten,

  • sowie zwei Gegenstellen (wobei Gegenstelle 1 die wichtigste ist).

Außerdem frage ich mich, ob es sinnvoll wäre, das Ganze über VXLAN innerhalb des WireGuard-Site-to-Site-Tunnels zu realisieren, um die Netzwerke sauber zu trennen oder zu erweitern.

Zusätzlich würde ich das Traffic-Limit bzw. die Kontrolle gerne über OPNsense regeln.
Hat das jemand schon umgesetzt oder kann Tipps geben, welcher Ansatz dafür am besten geeignet ist?

Danke! :raising_hands:

Wie meinst du? Den wireguard-transitpool?

Ich verstehe noch nicht so ganz was du meinst. Was willst du tun? Willst du Netze verbinden oder trennen? Oder ein Netz auf beiden Seiten haben?

Das Ziel ist, einen öffentlichen IPv4-Adresspool auf zwei Standorte aufzuteilen. Am Hauptstandort steht mir ein /24-Netz zur Verfügung, das ich gerne so splitten möchte, damit beide Standorte jeweils einen Teil davon nutzen können.
Momentan habe ich allerdings Probleme mit dem Gateway, da sich dieses nicht sauber aufteilen lässt.

Grundsätzlich wäre es für mich in Ordnung, die Nutzung über Routing zu trennen – also dass jeder Standort einen eigenen Teil des Adressraums erhält.
Es wäre aber ebenfalls akzeptabel, wenn sich das Netz nicht routen lässt und jede einzelne Adresse standortübergreifend frei genutzt werden könnte.

Naja, das Netz aufzuteilen in zwei gleich große Netze ist ja kein Problem.

  • 192.168.111.0/25
  • 192.168.111.128/25

Das geht natürlich analog auch mit öffentlichen IPv4 Adressbereichen und kann via Gateway entsprechend geroutet werden.

1 „Gefällt mir“

Jetzt verstehe ich👍

Und was genau geht da jetzt nicht? Wohin wird dieses öffentliche Subnetz denn vom Provider geroutet? Zu einer der OPNsensen oder wohin?

Und was geht mit dem GW nicht richtig? Wie sieht überhaupt der bisherige Aufbau aus?

1. Provider → Hauptstandort (WireGuard-IP-Transit)
Der Provider liefert mir einen WireGuard-Tunnel, über den der gesamte IP-Transit läuft.

WG-Transit auf der OPNsense: wg_transit
Transit-IP lokal (Beispiel): X.X.X.130
Gateway beim Provider: X.X.X.129
Das komplette Netz X.X.X.128/27 wird vom Provider an X.X.X.130 geroutet.
Es gibt nur einen Gateway vom Provider, und der ist nur am Hauptstandort erreichbar.
(Ich habe 2 Gateways gemacht könnte ein Fehler sein. Also habe ich es rausgenommen)

2. Weitere Standorte → Hauptstandort (Site-to-Site-WireGuard)
Die anderen zwei Standorte hängen per eigenen WG-Site-to-Site-Tunneln am Hauptstandort:

Tunnel 1: Hauptstandort ↔ Büro_Standort
(z.B. Tunnel-IP: 10.10.10.1 ↔ 10.10.10.2)

Tunnel 2: Hauptstandort ↔ Halle_Standort
(z.B. Tunnel-IP: 10.10.20.1 ↔ 10.10.20.2)

Über diese zwei Tunnel werden später einzelne /32 geroutet.

4. Routing auf der Haupt-OPNsense
Die Haupt-OPNsense weiß:

„Alle Public-/32 für Shared gehen über Tunnel 1“
„Alle Public-/32 für Standort 3 gehen über Tunnel 2“

Beispiel:

Route zu Büro:
X.X.X.134/32 → Gateway: 10.10.10.2
X.X.X.135/32 → Gateway: 10.10.10.2

Route zu Halle:
X.X.X.136/32 → Gateway: 10.10.20.2
X.X.X.137/32 → Gateway: 10.10.20.2
X.X.X.138/32 → Gateway: 10.10.20.2
X.X.X.139/32 → Gateway: 10.10.20.2
X.X.X.140/32 → Gateway: 10.10.20.2

Wenn dann Traffic aus dem Internet kommt, z.B. an X.X.X.137, sieht die Haupt-OPNsense:
„Diese IP gehört Standort Halle → über Tunnel 10.10.20.x weiterleiten“.

5. Remote-OPNsense am Standort Büro

Am Büro-Standort sieht es so aus:
Loopback-Interface LOOP_PUB
Public-IP z.B. X.X.X.134/32
Gateway Default-Route oder Policy-Routing über den Tunnel (10.10.10.1)
Die OPNsense dort weiß also:
„Alle Pakete mit dieser Public-IP müssen über den Tunnel zurück zum Hauptstandort“.

6. Remote-OPNsense am Standort Halle

Genauso, aber mit eigener Public-/32 oder mehreren:
LOOP_PUB3 hat z.B.:
X.X.X.136/32
X.X.X.137/32
usw.

Gateway zum Hauptstandort: 10.10.20.1

7. Ergebnis

So bekommt jeder Standort echte, routbare öffentliche IPv4-Adressen – ohne NAT, sauber geroutet, und ohne dass der Provider mehrere Gateways bereitstellen müsste.

Internet ↔ A1 Business Cloud ↔ Hauptstandort ↔ Tunnel ↔ Remote-Standorte

Standort Büro:
RX: 1000 Mbit/s
TX: 800 Mbit/s

Standort Hallo:
RX: 2100 Mbit/s
TX: 1100 Mbit/s

Hauptstandort:
RX: 4000 Mbit/s
TX: 2000 Mbit/s

Der Hauptstandort muss immer Upstream + Downstream bewältigen, weil er „relay“ spielt.

Die Remote-Standorte müssen nicht schneller sein als ihr Bedarf, aber der Hauptstandort muss mindestens so schnell sein wie alle Standorte zusammen.

So sollte es gehen nur da blockiert was.

grundsätzlich ist es natürlich möglich, ein /24-Netz in zwei Hälften zu splitten – z. B. analog zu

192.168.111.0/25
192.168.111.128/25

und das entsprechend über die Gateways zu routen.

In meinem Setup lässt mich die aktuelle Vorgabe bzw. die Konfiguration des Providers jedoch nicht direkt ein /24-Netz auf zwei Standorte aufteilen. Daher habe ich mich entschieden (vom Provider einen Transit beantragt aka bekommen. Einzige Change momentan.), daraus ein /28 zu machen und dieses sauber über Site-to-Site-Routing zu den Remote-Standorten zu verteilen.

Das bedeutet:

  • Jeder Standort bekommt einen eindeutigen, routbaren Bereich

  • Keine NAT nötig

  • Routing erfolgt über die Haupt-OPNsense als zentralen Relay-Punkt

  • Die Gateways werden sauber auf die Tunnel aufgeteilt

So ist sichergestellt, dass jeder Standort echte, öffentliche IPv4-Adressen nutzen kann, ohne Konflikte und ohne dass der Provider mehrere Gateways bereitstellen müsste.

Mit dieser Lösung bleibt das Netz kontrolliert, sauber geroutet und skalierbar, auch wenn das ursprüngliche /24-Netz nicht direkt aufgeteilt werden kann.

Und wo genau hängt es jetzt?

Was genau hast du dafür bereits konfiguriert?

Nur denn Master tunnel

Was heißt das? Also die S2S-Tunnel stehen noch gar nicht?

Exakt, habe sie zwar Probiert aber er konnte keine Verbindung aufbauen.

Was genau hast du da versucht? Hast du das noch?