Konfiguration: WAN von Provider-Gateway-Router mit ganzen Subnet ins LAN bringen

[Varix]

Hallo, ich bin Frischling und habe mir im Vorfeld etliche Videos bei Youtube zu OPNsense angeschaut. Aber nun wo es live los gehen soll, gibt es natürlich doch Probleme. Da ich leider nicht zu lange die Verbindung zum Provider mit meinen Experimenten vom LAN trennen darf, muss ich jetzt doch einige Fragen stellen.

Ich habe zwei Bilder angehängt. Der erste zeigt mein Szenario. Der Router des Providers stellt das IP Netz 84.84.84.xx/24 bereit und hat die IP 84.84.84.254 (Gateway) und ist dem WAN Port des OPNsense Routers verbunden. Von dort geht es ins LAN 10.1.1.0/8, wo der OPNsense Router die IP 10.1.1.1 hat.

Alle Geräte im LAN sollen aus dem Internet erreichbar sein (zunächst) und zurück ins Internet senden können (so wie vorher ohne OPNsense).

Das zweite Bild zeigt mehrere Screenshots von OPNsense. Das Gateway ist Online (grün) (nicht wie auf dem Bild) und funktioniert. Ich kann in OPNsense Updates und Plugins laden und der Provider-Router kann per OPNsense Webinterface PING 84.84.84.254 angepingt werden.

Allerdings kann der PING nicht die PC und Server im LAN erreichen und von dort kann man 84.84.84.254 ebenfalls nicht erreichen.

Ich vermute, dass Roles/Loopback noch fehlen, aber ich will zuerst mal hier fragen um nicht so lang rumzupfuschen.

Vielen Dank für die Hilfe.

[Varix]

Screenshots (Bild 2)

[Monviech (Cedrik)]

Soll die Opnsense eine transparente Bridge sein, oder soll ein 1:1 NAT zwischen internem und externem Netz gemacht werden?

Mich interessiert warum die Server am LAN Port die externen IP Adressen im Schaubild haben. Falls die Opnsense Router und NAT machen soll benötigen die Server am LAN interface IP Adressen aus dem Netz 10.1.1.0/16.

Falls die Opnsense transparente Bridge sein soll müssen 2 Interfaces als Bridge konfiguriert werden und der Provider Router und der interne Switch an getrennen Ports in der Bridge angeschlossen werden. Dann könnten die externen IPs so weiterverwendet werden wie vorher.

[Varix]

> 1:1 NAT zwischen internem und externem Netz

Ja, die öffentlichen IPs (84.84.84.xxx) sollten direkt zu den Servern und zurück.

> Falls die Opnsense transparente Bridge sein soll müssen 2 Interfaces als Bridge konfiguriert werden und der Provider Router und der interne Switch an getrennen Ports in der Bridge angeschlossen werden. Dann könnten die externen IPs so weiterverwendet werden wie vorher.

Das verstehe ich jetzt nicht ganz: Also der Provider-Router steckt auf eth0, das als WAN konfiguriert ist, und das LAN auf eth2 am OPNsense-Gerät. Der Traffic soll 1-zu-1 durchlaufen, aber natürlich mit der Möglichkeit Regeln zu definieren. Kein NAT wie bei der Fritzbox.

[Monviech (Cedrik)]

Ich glaube du willst dieses Ziel erreichen:
https://docs.opnsense.org/manual/how-tos/transparent_bridge.html

[Varix]

Bin mir nicht sicher, ob das 100% das richtige Löschung ist, da steht:

5. Disable Block private networks & bogon
For the WAN interface we nee to disable blocking of private networks & bogus IPs.

...und die privaten Netzwerk-IPs sollten doch weiterhin auf dem WAN geblockt sein.

[Monviech (Cedrik)]

Im Schaubild haben alle Server externe IPs. Das geht mit der transparenten Bridge in der Anleitung. Ich denke dass die Bogon und Privaten Netze weiterhing geblockt bleiben sollen weil es eine WAN Bridge ist. Ich habe diese Konfiguration noch nie getestet, da müsste hier jemand anderes übernehmen.

[Varix]

Ich habe jetzt noch einige Stunden rumgegoogelt und das was @Monviech als Möglichkeit angeführt hat, könnte eine Lösung sein - vielleicht aber nicht die beste. Man müsste dann die eingehenden Firewallregeln für die öffentlichen IP Adressen auf der definierten Bridge anlegen.

Allerdings wäre doch auch zwei statische Routen (also Routing) eine Lösung z.B. so:

1. WAN-Port IN-Traffic: alles an Adressen 84.84.84.* weiterrouten an LAN-Port
2. LAN-Port IN-Traffic: alles an Adresse 84.84.84.254 (Gateway-IP des Provider-Routers) weiterrouten an WAN-Port.

Evtl. muss dafür am LAN-Port eine virtuelle IP 84.84.84.254 definiert werden (damit Pakete ankommen können auf der IP)?!

Das wäre doch die sauberere Lösung als so eine Bridge?

Ich hoffe, es äußert sich noch jemand dazu, der das schon gemacht hat. Das ist schließlich nichts ungewöhnliches.

Vielleicht nochmal als Textbeschreibung um was es geht:
Über den Provider-Router kommt öffentlicher IP-Traffic an (256er-Subnetz), der soll in den WAN-Port der OPNsense, dann sollen Firewall-Regeln abgearbeitet werden aus dem WAN-Port und der Traffic weiter auf den LAN-Port fließen an die Server/Geräte dort, die auf die öffentlichen IP-Adressen konfiguriert sind. Umgekehrt soll vom LAN-Port alles mit diesen öffentlichen IP-Adressbereich zurück um Provider-Router.
Also: 84.84.84.254 -> WAN:OPNsensen -> Firewallregeln -> LAN:OPNsensen -> Zielgerät 84.84.84.xxx

[Monviech (Cedrik)]

Wenn du routen willst musst du dein öffentliches /24 Netz in kleinere Netze subnetten. Du brauchst dann nämlich ein Transfernetz vom Providerrouter zur Opnsense. Der Providerrouter muss dann auch konfigurierbar sein, oder von deinem Provider angepasst werden da er eine statische Route zur Opnsense benötigt.

Möglichkeiten als Liste:
1. Transparente Bridge - Vorteil: Ganzes Subnet, Provider und Netzwerk muss nicht angepasst werden - Nachteil: EDIT: Performance von Bridge wahrscheinlich unterdurchschnittlich wenn Virtualisierung oder nicht kompatible Hardware verwendet wird. - Siehe unten

2. Routing mit NAT - Vorteil: Gleiche wie 1. - Nachteil: NAT, alle Server müssen auf interne IPs umkonfiguriert werden

3. Routing mit Subnetting - Vorteil: Kein NAT - Nachteil: Netz muss gesubnettet werden, Provider muss Router anpassen

4. Routing mit extra Transfernetz - Es kann auch ein extra /30 Transfernetz vom Provider bereitgestellt werden um das /24 Netz ganz zur Opnsense zu bekommen.

[Varix]

Zu Punkt 1: Das könnte gehen, aber ist dass das richtig Vorgehen hierfür...?

Zu Punkt 2: Umkonfigurieren will ich auf keinen Fall

Zu Punkt 3: Dieses Subnetz-Splitting will ich auch nicht, mir ist nicht klar, warum das sein muss. Es ist doch nur ein zusammenhängendes Subnetz mit 256 IPs, also 0-255

Zu Punkt 4: Transfernetz dürfte der falsche Weg sein. Der Provider-Router steht direkt neben dem OPNsense-Router am WAN Port angeschlossen. Das funktioniert ja sogar schon, weil die OPNsense dafür ihre Update geladen hat.

[Monviech (Cedrik)]

Die Opnsense hat gerade Internet und kann Updates machen weil sie wie ein Host (Also wie einer deiner Server) fungiert. Aber sie kann nichts vom LAN in das WAN routen, ohne dass dort verschiedene Netzwerke anliegen.

Verschiedene Netzwerke wären z.b

Mit Subnetting:

Server:
LAN: 84.84.84.131/25
Default Route: 0.0.0.0/0 next hop 84.84.84.129

Opnsense:
LAN: 84.84.84.129/25
WAN: 84.84.84.2/25
Default Route: 0.0.0.0/0 next hop 84.84.84.1

Provider Router
WAN: 84.84.84.1/25
Statische Route: 84.84.84.128/25 next hop 84.84.84.2
Default Route: 0.0.0.0/0 next hop PROVIDER UPSTREAM


Mit Transfernetz:

Server:
LAN: 84.84.84.2/24
Default Route: 0.0.0.0/0 next hop 84.84.84.1

Opnsense:
LAN: 84.84.84.1/24
WAN: 77.77.77.2/30
Default Route: 0.0.0.0/0 next hop 77.77.77.1

Provider Router:
WAN: 77.77.77.1/30
Statische Route: 84.84.84.0/24 next hop 77.77.77.2
Default Route: 0.0.0.0/0 next hop PROVIDER UPSTREAM

Fürs bessere Verständnis probiere mal den tracert oder traceroute Befehl aus. Dort siehst du die Hops die ein Paket nimmt bis es beim Ziel ankommt. Jeder Hop ist ein eigenständiger Router, an dem verschiedene Netzwerke anliegen. Es gibt an keinem Punkt einen Router der zwischen komplett gleichen Netzen routet. Denn dann würde es einen Routing Loop geben weil der Router sich selbst als Ziel sieht und beim Paket die TTL abläuft.

[max1284]

Hallo zusammen,

ich freue mich über den Thread, da ich im Prinzip die gleiche Ausgangssituation habe.

1. Transparente Bridge - Vorteil: Ganzes Subnet, Provider und Netzwerk muss nicht angepasst werden - Nachteil: Performance von Bridge wahrscheinlich unterdurchschnittlich

Nach dem Lesen der Dokumentation scheint Transparent Firewall Bridging (https://docs.opnsense.org/manual/how-tos/transparent_bridge.html) der sinnvollste Weg zu sein. Mich überrascht jedoch sehr, dass du als Nachteil "wahrscheinlich unterdurchschnittlich [Performance]" annimmst. Das ist interessiert mich sehr, da das natürlich zum KO dieser Lösungsvariante führen könnte. Wie kommst auf die Annahme zur Performance? Wovon hängt der Grad der Performance aus deiner Sicht ab? Netzwerk-Chip?

Vielen Dank und viele Grüße,
max1284

[Monviech (Cedrik)]

Ich bin mir hier gar nicht sicher, da fehlen mir Tests und zusätzliches Wissen.
Es kommt wahrscheinlich auf die Hardware und die Netzwerkkarte an, und welche Features die Netzwerkkarte unterstützt. Es kann auch durch Virtualisierung der Opnsense ein Performanceverlust passieren.

Beispiel Routing: Ist in der Virtualisierung langsamer als auf Bare Metal. Das ist messbar bei höheren Geschwindigkeiten wie 10Gbit/s Brutto Übertragungsrate, wo bei Virtualisierung im Routing 7Gbit/s Netto Übertragungsrate sind. Ich weiß nicht ob Switching, was ja auf einem anderen Netzwerklayer als Routing läuft, die gleichen oder schlechtere Performance Werte hat. https://forum.opnsense.org/index.php?topic=35184.msg170587#msg170587

Vielleicht gibt es bei 1Gbit/s full duplex Switching nicht sehr viel Performanceverlust, aber bei 10Gbit/s full duplex Switching schon.

Das müsse man mal mit iperf testen, ich habe aber keine freie Hardware hier rumliegen, mit der ich 10Gbit Switching über die Opnsense testen kann. Wäre aber echt interessant, wenn man L2 Firewall mit der Opnsense machen will.

EDIT:
https://forums.freebsd.org/threads/can-a-freebsd-bridge-outperform-off-the-shelf-switches.83312/

https://wiki.freebsd.org/Networking/10GbE/Router
"Minimum hardware requirements
Before tuning, to be able to reach the minimum requirement of a 10Gb/s router, the CPU must have 8 cores minimum, Intel Xeon or equivalent class.

NIC manufacturers known to take care of their FreeBSD drivers: Chelsio, Intel and Mellanox."

Vielleicht ist das übertragbar auf Switching Performance. Man sollte also ordentliche Hardware ohne Virtualisierung verwenden und dann sollte es theoretisch keine Probleme geben. Ich habe meine Aussage oben editiert und eingeschränkt.

[Varix]

Eine erste Erfolgsmeldung: Es klappt ... teilweise!

Ich habe jetzt doch gleich die Bridge-Lösung probiert. Dafür benötigt man 3 LAN Ports, einen fürs LAN (u.a. für das Web-Interface der OPNsense), einen für die DMZ (öffentliche IPs) und einen für das WAN zum Provider-Router.

Bin nach dieser Anleitung vorgegangen:
https://azizozbek.ch/blog/2018/08/opnsense-stealth-bridge-firewall/
bzw. ist ähnlich der Originalanleitung:
https://docs.opnsense.org/manual/how-tos/transparent_bridge.html#change-system-tuneables

Für den DMZ- und WAN-Port muss keine IP oder Subnetz eingestellt werden. Dafür muss eine Bridge angelegt werden und der dann der DMZ- und WAN-Port hinzugefügt wird.

Damit die OPNsense über ihren LAN-Port Updates und Plugins laden kann, muss ein Gateway angelegt werden und diesen in den LAN-Port-Einstellungen eingetragen werden. Das Gateway kann auch im LAN sich befinden, z.B. ein anderen Router (DSL).

Die Firewall-Regeln greifen entgegen der oben verlinkten deutschen Anleitung von azizozbek.ch nur, wenn man sie auf dem neuen BRIDGE-Interface definiert. Für WAN und DMZ sind sie wirkungslos in Bezug auf eingehenden Traffic über die öffentlichen IPs.

ABER! Ein Problem habe ich noch:

Meine Server sind zwar jetzt erreichbar und der eingehende Traffic vom Provider-Router lässt sich per FW-Regeln steuern und z.B. Webseiten usw. funktionieren. Aber wenn der Server von sich aus im Internet etwas abrufen will, z.B. Browser auf dem Server oder Ping auf eine externe IP, dann wird das geblockt (oder die Antwortpakete kommen nicht zurück bzw. werden geblockt!

Außer ich mache eine FW-Regel die alles eingehend erlaubt! Dann sind die Server aber auch wieder nicht geschützt. Also es scheint so, dass die Server ins Internet senden können z.B. eine Ping oder eine Browser-URL anfrage, aber dann der rückläufige Traffic nicht durch kommt.

Was tun?

[Monviech (Cedrik)]

Hast du für die Server auf der Bridge eine Regel gemacht die so aussieht? Sie sollte an letzter Stelle sein und somit das ausgehende Internet für die Server erlauben.

Action: Pass
Direction: In
Protocol: Any
Source IP: 84.84.84.0/24
Source Port: 1024-65535
Destination IP: ! (Invert) 84.84.84.0/24
Destination Port: Any
Description: Erlaube Server ins Internet

EDIT:
Was auch noch helfen kann, ist Intra Zonen Traffic zu erlauben. Diese Regel kann zusätzlich vor der Internet Regel sein.

Direction: In
Action: Pass
Protocol: Any
Source IP: 84.84.84.0/24
Source Port: Any
Destination IP: 84.84.84.0/24
Destination Port: Any
Description: Erlaube Intra Zonen Traffic