01.02.2024, aktualisiert um 16:02:05 Uhr

2321

Routing Problem OPNsense

Hallo in die Runde.

ich habe mich durchgerungen, meinen alten Mikrotik Router durch eine OPNsense zu ersetzen. Netzwerktopo wie in der Grafik abgebildet.

Die OPNsense soll über ein Transfernetz (172.23.254.0/24) allen Traffic für die 172.22.x.x-Netze an den Switch durchreichen. Dieser macht das Routing für diese Netze.

Die OPNsense routet selbst lediglich das Mgmt-LAN (auf dem LAN-Port) und das DMZ-LAN auf OPT2 (was jetzt erst mal unwichtig ist und noch nicht konfiguriert, weshalb es in der Grafik weggelassen wurde) und natürlich das Transfernetz.

Auf der OPNsense sind die Ports entsprechend konfiguriert. LAN funktioniert. Darüber komme ich ins INet und kann die OPNsense konfigurieren. Ich komme von hier auch auf den Switch.
Vom Switch aus komme ich ebenfalls ins INet.

Aus den Netzten hinter dem Switch geht allerdings nichts in Richtung INet (kein Ping ins INet). Ich bekomme gerade mal einen Ping vom Transfer-Interface des Switches (172.23.254.2) zurück.

Da es mit dem Mikrotik Router vorher problemlos lief, nehme ich an, dass es am Routing oder Firewallregeln auf der OPNsense liegt, finde aber keinen Fehler. Mittlerweile sehe ich aber wahscheinlich auch schon den Wald vor lauter Bäumen nicht mehr...

Ich habe ein Gateway angelegt.
Schnittstelle: OPT1
Adressfamilie: IPv4
Adresse: 172.23.254.2 (die Adresse des Switches im Transfer-Netz)
entferntes GW
Prio: 254
Das Gateway hat eine niedrigere Prio als das Default GW, sollte also vorrangig bedient werden.

Außerdem habe ich Routen in die 172.22.x.x-Netze (die vom Switch geroutet werden) angelegt, welche das o.g. Gateway nutzen.

Irgendetwas fehlt wohl aber noch.

Kann mir bitte jemand auf die Sprünge helfen? Vielen Dank.

Falls noch Fragen offen sind, bitte nachfragen. Ich wollte nur keinen Roman schreiben

VG mhard666

Nachtrag:
Nach einem Neustart der OPNsense bekomme ich einen Ping auch auf die IP-Adressen der OPNsense.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 73067397093

Url: https://administrator.de/en/routing-problem-opnsense-73067397093.html

Ausgedruckt am: 22.12.2024 um 11:12 Uhr

19 Kommentare

Neuester Kommentar

Irgendetwas fehlt wohl aber noch.

Firewall der OPNSense muss die anderen Netze auch durch lassen.
DNS-Port in der FW der OPNSense nicht vergessen falls die als DNS-Proxy per DHCP auf die Clients verteilt wird. Outbound-NAT Regeln für die VLANs angelegt ?

Quote from @abamakabra:

Irgendetwas fehlt wohl aber noch.

Firewall der OPNSense muss die anderen Netze auch durch lassen.
DNS-Port in der FW der OPNSense nicht vergessen falls die als DNS-Proxy per DHCP auf die Clients verteilt wird.

Die Firewallregeln habe ich erst mal sehr großzügig eingestellt (incoming von 172.22.0.0/16 to any und incoming von OPT1-Network to any erlaubt). Im Protokoll geht das auf OPT1 alles grün durch. Lediglich auf dem WAN werden in größerem Maßstab Adressen geblockt.
DNS funktioniert auch.

VG.

Erst mal eine ANY TO ANY Regel anlegen und dann testen dann weist du ob es an deinem Regelwerk liegt oder nicht.

Dann wie üblich n' Trace-Route machen und im Zweifel Traffic-Capture an der Sense dann siehst du wo's klemmt.

Ohne weitere Config-Info zur Sense und Switch Glaskugel...

Aus den Netzten hinter dem Switch geht allerdings nichts in Richtung INet (kein Ping ins INet)

Kann das sein das du die Default Route auf dem L3 Switch vergessen hast und/oder ggf. auch die dazu korrespondierenden statischen Routen deiner VLAN Netze auf der Firewall??
Die Default Route auf dem L3 Switch erwähnst du oben zumindestens mit keinem Wort.

Layer 3 Switching Grundlagen

Eine einzige Summary Route 172.22.0.0 /19 GW: 172.23.254.2 (255.255.224.0) statt all der Einzelrouten wäre eh etwas effizienter.
Bedenke das du das Gateway dafür einrichten musst und den Haken bei

setzen musst!

Da man dein Ruleset am OPT1 Interface nicht kennt muss man hier leider raten. Dort sollten außer dem Transfer Netz noch die Netze 172.22.0.0 /19 erlaubt sein (Alles von 172.22.0.0 bis 172.22.31.0). Es sei denn du hast da eh erstmal eine any any Scheuentorregel wie Kollege @abamakabra schon gesagt hat.
Im Gegensatz zu deinem Mikrotik Router der nach einer Blacklist Logik arbeitet arbeiten Firewalls bekanntlich immer nach einer Whitelist Logik beim Regelwerk. Vermutlich ist hier dein Denkfehler. 🤔

n'Abend,

Danke erst mal für die Antworten.

Ich habe eine Any to Any rule angelegt. Die OPNsense blockt nix mehr seit dem - zumindest wird im Log nix mehr angezeigt.
Der ping geht trotzdem noch nicht ins INet

@aqui
Die Routen auf dem Switch habe ich geflissentlich unter den Tisch fallen lassen, da sie 1. schon mit dem MikroTik funktioniert haben und 2. automatisch erstellt werden, wenn den VLANs IP-Adressen zugewiesen werden.

Der Vollständigkeit halber:

IPv4 Static Routes:
Dst: 0.0.0.0; Type: Remote; Next Hop Router Addr: 172.23.254.1; Metric: Default

IPv4 Forwarding Table:
Dst: 0.0.0.0/0; Type: Remote; Next Hop Router Addr: 172.23.254.1; Route Owner: Static; Distance: 1; IF: VLAN254
Dst: 172.22.10.0/24; Type: Local; Next Hop Router Addr: 172.22.10.1; Route Owner: Directly Connected; IF: VLAN10
Dst: 172.22.11.0/24; Type: Local; Next Hop Router Addr: 172.22.11.1; Route Owner: Directly Connected; IF: VLAN11
Dst: 172.22.20.0/24; Type: Local; Next Hop Router Addr: 172.22.20.1; Route Owner: Directly Connected; IF: VLAN20
Dst: 172.23.254.0/24; Type: Local; Next Hop Router Addr: 172.23.254.2; Route Owner: Directly Connected; IF: VLAN254

In meinem letzten Post, hatte ich geschrieben, dass ich auf OPT1 die entsprechenden Rules gesetzt habe. Jetzt habe ich Any to Any auf allen Ports.

Gateway ist eingerichtet (steht auch in meinem ersten Post)

Bypass firewall rules ... on same IF habe ich für in den erweiterten FW-Einstellungen aktiviert

...aber es lüppt nicht.

Kann es an der Prio des Gateways liegen?

Übrigens: Mein MikroTik nutzt(e) auch ein Whitelisting bei den Firewallregeln. Es wurde erlaubt, was erlaubt war und am Ende wird alles andere gedroppt...

Da ist man beim Mikrotik recht flexibel - man kann es natürlich auch andersherum aufziehen.

VG mhard666

--EDIT--
Ein tracert 8.8.8.8 vom Client aus dem 172.22.10.0/24er Netz bleibt nach dem 2. Hop (172.23.254.1) hängen.

Hallo mbhard666

Dein Setup ist relativ einfach.

1. Firewall Rules für das Transitnetz
2. Den Gateway erfassen
3. Die statischen Routen für das Netz welches der L3 Switches erfassen und zu dem L3 Switch routen
4. Das Outbound Nat auf hybrid schalten und für die Netzte des L3 Switches eine Outbound NAT Rule erstellen.

Nachher sollte es laufen.

Gruss
adminst

Du musst deiner Firewall sagen wie sie in deine Vlan's kommt.

Also Routen einrichten.

Um in dein 172.22.20.0/24 Netz zu gelangen, braucht die Firewall eine Route.

Route: Ziel Netz: 172.22.20.0/24 Next Hope 172.23.254.2(Dein vInterface auf dem L3 Cisco)

Also, dein vInterface am Cisco kennt den weg in all deine Vlan's die am Cisco anliegen.

Für die anderen Routen machst das selbe.

Route: Ziel Netz: 172.22.10.0/24 Next Hope 172.23.254.2(Dein vInterface auf dem L3 Cisco)
Route: Ziel Netz: 172.22.11.0/24 Next Hope 172.23.254.2(Dein vInterface auf dem L3 Cisco)

Regelwerk anpassen, fertig.

LG

und 2. automatisch erstellt werden, wenn den VLANs IP-Adressen zugewiesen werden.

Das ist aber Unsinn, denn in einem reinen Transfer VLAN was man ja mit einem /30er oder /31 Prefix betreibt oder betreiben kann vergibt man doch niemals IP Adressen unnötigerweise mit DHCP. Das wäre bei 2 aktiven IPs ja ziemlicher Quatsch. Mal abgesehen das man einen Router wie deinen L3 Switch niemals mit dynamischen IPs betreibt! Jeder gute und verantwortungsvolle Netzwerk Admin weiss das. 🧐 Folglich ist also die 0.0.0.0/0 Default Route auf dem L3 Switch ein Muss damit der alles was nach Extern geht entsprechend routen kann!

Hilfreich wäre hier ein Traceroute (tracert bei Winblows) aus den Switch VLANs ins Management Netz. Da wo er scheitert ist auch der Fehler. Firewall Log kann auch helfen.

bleibt nach dem 2. Hop (172.23.254.1) hängen.

Bedeutet ja dann das etwas auf der Firewall Seite nicht stimmt. Entweder mit dem Ruleset oder den statischen Routen.
Wenn du hier in die Diagnostics gehst und mit dem Source Interface LAN die jeweiligen L3 Switchadressen 172.23.254.2 und 172.22.10, 11 und 20.1 pingst klappt das?
Das gleiche dann nochmal mit dem OPT1 als Source.

Irgendwas stimmt mit dem Routing oder NAT auf der FW nicht. Metriken muss man bei der Gateway und Routing Konfig in der FW gar nicht angeben und am NAT der FW muss man eigentlich nix fummeln.

Hast du in in dem Gateway die Ziele definieren können?

Statt 3 Routen kannst du diese auch zusammenfassen. 172.22.0.0/22
Dann bracht es nur eine Route auf der FW.

Moin.

Quote from @adminst:

Hallo mbhard666

Dein Setup ist relativ einfach.

1. Firewall Rules für das Transitnetz

hab ich.

2. Den Gateway erfassen

hab ich auch.

3. Die statischen Routen für das Netz welches der L3 Switches erfassen und zu dem L3 Switch routen

hab ich auch.

4. Das Outbound Nat auf hybrid schalten und für die Netzte des L3 Switches eine Outbound NAT Rule erstellen.

Auch wenn aqui der Meinung ist, dass das nicht erforderlich wäre, würde ich diesen Lösungsansatz mal weiter verfolgen...
Outbound NAT habe ich auf hybrid gesetzt. Was sich mir allerdings nicht erschließt ist, wie die Outbound NAT Rule aussehen müsste.

VG.

Statt 3 Routen kannst du diese auch zusammenfassen. 172.22.0.0/22

Wurde dem TO oben ja auch schon gesagt allerdings hast du einen fatalen Freitags 🐟 Fehler begangen❗️

Der TO hat, wie man oben sieht, auch ein .20.0er Subnetz am L3 Switch was dann einen /19er Prefix (255.255.224.0) bei der Firewall Route erfordert.

Zitat von @mhard666:
Outbound NAT habe ich auf hybrid gesetzt. Was sich mir allerdings nicht erschließt ist, wie die Outbound NAT Rule aussehen müsste.

VG.

Source : (deine VLAN Subnetze)
Out-Interface : WAN
Masquerade

dass das nicht erforderlich wäre,

Zumindestens rennt es hier bei einer OPNsense, aktuellstes Image, gleiches Setup wie oben mit einem SG300 vollkommen unauffällig. 😉

Moin.

Quote from @Ueba3ba:

Hast du in in dem Gateway die Ziele definieren können?

Statt 3 Routen kannst du diese auch zusammenfassen. 172.22.0.0/22
Dann bracht es nur eine Route auf der FW.

In dem Gateway definiert man keine Ziele. Dafür setzt man dann die Routen mit dem Gateway. Die wesentlichen Daten für das Gateway, so wie es konfiguriert ist, habe ich ja dargelegt.

Ja, das mit dem Routen zusammenfassen kann man machen... Wenn es geht wird das auch optimiert. Aber erst mal muss es laufen.

VG.

Moin @all.

Ihr Helden

Mit dem NAT funktioniert es!

Also:
NAT -> Ausgehend auf hybrid gesetzt und eine NAT-Regel angelegt:

Schnittstelle: WAN
Quelladresse: 172.22.x.x/x
Übersetzung: WAN-Adresse

Vielen Dank für die Unterstützung.

VG. mhard666

Hallo
Ich habe dir hier kurz ein paar Screenshots. Die Aussage von Aqui kann ich nicht bestätigen.
Mit den Standardrules läuft es beim Outbound NAT nicht. Denn es wird das Transitnetz geroutet (resp. den von der Opnsense verwalteten Netzen). Von Haus aus weiss die Opnsense beim Nat nichts von den vom L3 Switch verwalteten Netzen und wird diese darum nicht natten.

Routen:

Gateway:

NAT:

Gruss
adminst

Jepp, die NATed per Default nur die Netze am WAN die es selbst kennt bzw. die auf der Sense selbst angelegt sind.

⚠️ 👉🏽Für ein Ping ins Internet MUSS die u.a. Regel des Folgekommentars bei der OPNsense zwingend hinzugefügt werden!!

(Transfer Netz ist hier 192.168.111.0/24 ansonsten gleiches Setup wie bei dir)

Gateway und Routing Setup

Ping Check L3 Switch Transfer Netz

Routing Tabelle u. Ping Check Layer 3 VLAN Interfaces am Switch

Fazit

Works as designed.

Klar aber du pingst mit den Netzen die am Switch hängen ja nur intern und nicht ins Internet und darum ging es ja, soweit wie du schilderst war er ja schon.. Die Netze am Switch sind per Default nicht im Outbound NAT enthalten und deswegen ging der Internet-Zugriff nicht weil die Sense diese Netze dann nicht per NAT maskiert sondern ins INET geroutet hat .