16.03.2022, aktualisiert um 08:29:15 Uhr

3486

Routing Probleme OpnSense Mikrotik

Hallo,

ich habe hier glaub ich einen schönen Knoten im Kopf, bzw. weis ich aufgrund der nicht einsehbaren Konfig des Cisco Routers nicht was hier los ist.

Vorab: Eine Umstellung der Netzwerkadressen ist aufgrund der Abhängigkeit von einer Drittfirma nicht möglich.

Die Opensense hat 3 Lan Schnittstellen:

LAN 172.31.0.0/16
OPT 192.168.45.0/16
WAN .....

Der Mikrotik Router ist mit 2 Schnitstellen eingebunden:

Ether1 172.20.20.254/8
Ehter2 192.168.45.123/16

Der VPN Endpoint ist mit 2 Schnittstellen eingebunden:

LAN unbekannt da Herstellerseitig
WAN 172.31.0.140/8

Ich möchte hier eine möglichkeit schaffen, dass der TMS (172.20.20.31) aus dem 192.168.45.X Netz heraus erreichbar wird,
derzeit wird hier über das Internet zugegriffen, also raus aus der Bude und über ein Portforwarding wieder hinein.

Hier mal der Netzüberblich:

Hier die OpnSense Cfg:

Hier beim Ping wirds interessant, wenn ich das richtig erkenne wird der Mikrotik Router kontaktiert aber die Antwort kommt dann vom VPN Endpoint:

Hier die Mikrotik Cfg:

Kann mir hier wer etwas Licht ins Dunkel bringen?

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

Content-ID: 2181865269

Url: https://administrator.de/contentid/2181865269

Ausgedruckt am: 25.11.2024 um 11:11 Uhr

12 Kommentare

Neuester Kommentar

Bevor wir ins Eingemachte sollten wir vielleicht erstmal ein paar mögliche Fehler in deiner Beschreibung klären:

Schlimmster Fehler vorweg der das Routing Konzept zumindestens mit den 172er Masken scheitern lässt: Das 172.er Netz am Mikrotik nutzt eine /8er Maske und an der OPNsense hast du ein 172er Netz mit einem 16er Prefix. Das geht so nicht, denn dieses 16er Netz wäre ja Teil des /8er Netzes und damit ist eine eindeutige Wegefindung zumindestens im 172er IP Netz unmöglich. Das 172.20.er Netz muss zwangsweise einen 16er Prefix haben sonst funktioniert das Routing in diesem Netz nicht.
Die Netzadressen sind teils falsch angegeben ! "OPT 192.168.45.0/16" richtig wäre OPT 192.168.0.0/16. Das solltest du nochmal korrigieren.
Der TMS hat in der Skizze einen 16 Bit Prefix, in der Beschreibung aber einen 8 Bit Prefix. Welcher gilt denn jetzt ? Inkonsistente Subnetzmasken gehen natürlich nicht !
Ebenso der VPN Endpoint. Der hat eine /8er Maske das Netz selber gibst du aber als /16 an ! Was gilt ?? Wieder inkonsitente Masken...
Auf der OPNsense sind auch wieder völlig falsche Subnetzmasken eingetragen die nichts mit den von dir angegebenen gemein haben. Hier arbeitest du mit falschen /24er Masken z.B. beim 172.0.0.0er Interface ! Auch hier wieder falsche inkonsistente Subnetzmasken !
Der Mikrotik ist laut deiner Zeichnung nicht im 172.31.0.0 /16er Netz !! Er hat aber ein Default Gateway dahin, was zeigt das du deine Topologie an sich auch falsch aufgebaut hast. Der MT steckt dann laut deiner Zeichnung in falschen Netz Segmenten !

Mit dem Masken Kauderwelsch und dem falschen Anschluss des Mikrotik muss man sich nicht groß wundern das das Routing dann völlig in die Hose geht.

Hier musst du also dringenst dein Setup und die Konfiguration nachbessern ! Ganz besonders am 172er Netz des Mikrotik !

Um die Übersicht einmal etwas besser aus reiner Layer 3 Sicht (Routing) darzustellen sehen deine richtigen Routingeinträge in den Komponenten so aus:

Bedingungen:

Mikrotik ohne Default Konfig, also keine Firewall und kein NAT aktiv
OPNsense mit entsprechendem Regelwerk das Traffic der Segmente entsprechend passieren darf

Hallo aqui,

danke für deine Hinweise ich habe jetzt mal die Sachen auf welche ich Einfluss habe nachgezogen.

Von dem VPN Endpoint weis ich nur was er von mir von der OpnSense per DHCP bekommt mehr weis ich von dem Ding nicht, da Fremdfirma.

Also hier der neue Netzplan, es besteht eine Verbindung des Mikrotiks zur OpnSense, die Default Route ist aber inaktiv und ist jetzt auch gelöscht.

Mikrotik ist ohne Default Konfig am laufen.
Opnsense lässt den Traffic von Opt zu Lan durch, kann aus dem 192.168.45.0/24 die NAS im 172.31.0.0/16 erreichen.

Korrektur hatte noch einen Fehler drinnen

Netzplan neu:

Hier die Configs:

OpnSense:

Mikrotik:

Tracert von der OpenSense zur TMS:

Von dem VPN Endpoint weis ich nur was er von mir von der OpnSense per DHCP bekommt

Sorry, aber solche Rumpelsätze versteht kein Mensch und verwirrt hier !

Bitte beschreibe das technisch korrekt, damit alle hier dir auch zielführend helfen können !!
Am Mikrotik oben hast du in deiner Skizze wieder eine falsche Netzwerkangabe für das 172.20.0.0 /16er Netz !

Wenn man das richtig versteht dann vergibst du auf der OPNsense dem "VPN-Endpoint" dynamisch per DHCP eine IP Adresse die dann vermutlich an die Hardware Mac Adresse des gebunden ist damit dieser dann quasi eine feste IP im 172.31.0.0 /16er IP Netz hat ? Also dort die 172.31.0.140.
Ist das so richtig ?

die Default Route (Mikrotik) ist aber inaktiv und ist jetzt auch gelöscht.

Damit kann der Mikrotik ausschliesslich dann nur seine beiden IP Netze an eth1 und eth2 bedienen.
OHNE eine statische Default Route auf die OPNsense ist ein Routing in andere IP Netze technisch unmöglich ! Das ist dir hoffentlich klar, oder ?

Opnsense lässt den Traffic von Opt zu Lan durch, kann aus dem 192.168.45.0/24 die NAS im 172.31.0.0/16 erreichen.

Das ist schonmal gut !
Nützt aber nichts wenn Clients aus dem 172.20.0.0 /16er Netz in das 172.31.0.0/16er Netz wollen. Das geht aus 3 Gründen dann nicht:

Default Gateway auf dem Mikrotik auf die 192.168.45.254 fehlt ! (0.0.0.0/0 Gateway: 192.168.45.254)
In der OPNsense muss ein Regelwerk vorhanden sein das am OPT Port Traffic von 172.20.0.0 /16 auf 172.31.0.0 /16 zulässt. Ausnahme: Du hast dort eine "any zu any" Scheunentorregel !
Analog zu dem o.a. Punkt muss die FW zusätzlich ein entsprechendes Regelwerk am LAN Port haben das 172.31.0.0 /16 auf 172.20.0.0 /16 zulässt. Auch hier wieder die Ausnahme wenn es "any" als Destination hat !

Leider hast du dein OPNsense Regelwerk vom LAN und OPT Port nicht gepostet so das man hier nur raten kann.

3 Gründe also warum dein o.a. Ping erwartungsgemäß scheitern muss !

Nur mal nachgefragt: Die beiden IP Netze 172.31.0.0 /16 und das unbekannte Cisco LAN 172? hast du wohl hoffentlich auf dem Netgear Switch in 2 separate und getrennte VLANs gelegt, oder ?!

Die jetzt auf deine nun richtigen Subnetzmasken korrigierte Layer 3 Übersicht inkl. Routing und Gateway Angaben sieht dann final so aus:

Strategische Ping Tests die du machen solltest:

Mikrotik: Ping auf 192.168.45.254 pingen (Verifiziert Erreichbarkeit OPNsense aus Netzwerk eth2)
Mikrotik: Ping mit Source IP auf 172.20.20.254 und 192.168.45.254 pingen (Verifiziert Erreichbarkeit OPNsense aus Netzwerk eth1)
Mikrotik: Ping auf NAS IP 172.31.0.? pingen (Verifiziert Erreichbarkeit NAS/LAN Segment aus Netzwerk eth2)
Mikrotik: Ping mit Source IP auf 172.20.20.254 auf NAS IP 172.31.0.? pingen (Verifiziert Erreichbarkeit NAS/LAN Segment aus Netzwerk eth1)
OPNsense: Ping auf 172.20.20.254 pingen (Verifiziert Erreichbarkeit Mikrotik Netz eth1)

Alle diese Pings sollten ausnahmslos klappen wenn ICMP nicht geblockt ist !

Hallo aqui, erstmal vielen dank für deine Geduld mit mir und meinem Problem.

Zu dem Thema VPN Endpoint:
Dieser bekommt von der OpnSense eine Ip zugeteilt, auf Basis seiner MAC.
Es handelt sich dabei um die 172.31.0.140/16.
Mehr kann ich leider dazu nicht sagen, da das Gerät von der Fremdfirma verwaltet wird.

Zu dem Thema Kommunikation zwischen 172.31.0.0 u. 172.20.20.0/24
Die Verbindung dieser 2 Netze ist nicht notwendig, wird nur vom Operator PC benötigt.
Auf dem Operator PC sind deshalb auch die 2 Ips aus den verschiedenen Netzen zugeweisen.

Default Gateway / Default Route Mikrotik
Diese habe ich inzwischen nachgetragen, da ich selbst erkannt habe das diese noch fehlt.

Trennung VLAN 172.31.0 u. 172.?
Nein diesbezüglich ist nicht konfiguriert, da dieser Switch nur den VPN Endpoint und die dahinterliegenden Gerätschaften bedient, eine Querverbindung besteht nur über den VPN Endpoint

Strategische Pings
Alle Pings gehen durch wie sie sollen

Anbei das gewünschte Regelwerk der OpnSense:

Mikrotik Config:

Tracert von OpnSense zu TMS:

Tracert von OpnSense zu TMS:

Hier wäre es hilfreicher gewesen als Source Adresse einmal das LAN und das OPT Interface zu setzen aber nehmen wir mal an das das auch klappt...

Es handelt sich dabei um die 172.31.0.140/16.

Gut, dann ist zumindestens schon einmal die IP Adressierung dafür geklärt.

Zu dem Thema Kommunikation zwischen 172.31.0.0 u. 172.20.20.0/24

Sorry aber nun wirfst du mal wieder deine Adressierung zum dritten Mal um !

Oben war immer von einem 16 Bit Prefix am 172.20er Netz die Rede und nun ist es mit einmal ein 24er. Was denn nun ??
Sorry, aber mit jedem Thread eine Änderung der Subnetzmakse ist nicht wirklich zielführend hier. Du solltest zumindestens einmal wirklich final klar machen mit welchen Subnetzmasken/Adressierung du denn nun wirklich arbeiten willst !!
Ein /24er Prefix wäre sicher sinnvoller am 172.20er IP Segment denn eine 16er Maske ist Unsinn in einem LAN das eh nie mehr als 150 physische Endgeräte habe sollte. Du willst ja wohl kaum 65534 Endgeräte addressieren, oder ?
In der Beziehung sind 16er Masken immer unsinnig, aber egal...Kosmetik letztlich.

Dein Mikrotik arbeitet aktiv laut Screenshot NICHT mit der von dir angegebenen 24er Maske sondern mit einer 16 wie es auch vorher besprochen war. Die statische Route in der OPNsense sollte dann auch dazu passen.
Inkonsistente Subnetzmasken in einem IP Netz sind ein absolutes NoGo was du ja bestimmt auch selber weisst ?!
Statische Routen in der OPNsense müssen dann auch auf diese Maskierung passen wie oben schon erwähnt.

Strategische Pings: Alle Pings gehen durch wie sie sollen

Bingo ! Perfekt ! 👍 👏
Dann haben wir es doch und du kannst deinen Thread dann ja schliessen ! Oder ist jetzt nochwas offen ?!

Zum Thema /24 das war ein vertipper.

Die Pings gehen durch, nur wie du im letzen Screenshot vom OpnSense siehst, bekomme ich eine Antwort von dem VPN Endpoint und nicht vom TMS <-- das ist ja das grundlegende Problem an der ganzen Sache

Zum Thema /24 das war ein vertipper.

OK, zur Ehrenrettung ! 😉

im letzen Screenshot vom OpnSense siehst, bekomme ich eine Antwort von dem VPN Endpoint und nicht vom TMS

Mmmhhh... Du meinst den Traceroute auf die .20.31er TMS Adresse, richtig ?
Das ist in der Tat richtig ! Die 172.31.0.140 dürfte dort niemals auftauchen zumal der erste Hop auf den Mikrotik ja richtig ist.
Leider hast du es versäumt mal deine OPNsense Routing Tabelle bzw. Setup hier zu posten.
Es ist zu vermuten das du dort wieder falsche Subnetzmasken in den statischen Routen verwendet hast.

Also bitte einmal posten.

Was auch sein kann...
Mikrotik eth1 (172.20.0.0er Segment) und der Cisco VPN-Endpoint sind irgendwie über deinen Netgear Switch verbunden. Leider weiss hier keiner wie da du dazu keinerlei Auskunft gegeben hast ??

Fakt ist aber das diese beiden Segmente dann zwingend in getrennten VLANs liegen müssen !
Die dürfen sich nicht "sehen" können. Ganz besonders wenn du mit "172.?.?.?" keinerlei Ahnung hast in welchem IP Netzwerk sich der Cisco befindet.
Hast du diese fälschlicherweise mit 2 unterschiedlichen IP Netzwewrk Adressen in eine gemeinsame Layer 2 Broadcast Domain zusammengesteckt, kann das so ein Chaos erzeugen. Auch da also noch einmal genau hinsehen und ggf. eine Info dazu posten !

Die 127.0.01 er DNS Regel im LAN kannst du übrigens entfernen. Diese Loopback Adresse taucht im Netzwerk, Prinzip bedingt, physisch niemals als Destination Adresse auf.

Sodala, also welche Config Teile von der OpnSense brauchst du denn?

Ich muss mir nächste mal einene Überblick vor Ort über die Switches machen, ich fürchte
es besteht eine Querverbindung zwischen den NetGear Swtiches.

Ich habe jetzt auch auf ein /24 Prefix umgestellt im 172.20.20.0.

OpnSenseRouting Table:

Soweit OK bis auf eine Ausnahme...
Wie mal wieder erwartbar bei deinem Subnetzmasken Kauderwelsch ist zumindestens für das 172.20.0.0 /16er Netz eine falsche Route eingetragen !!
Zitat @godlie "Zum Thema /24 das war ein vertipper."
Und dennoch hast du die Route wiedermal falsch mit einem /24er Prefix eingetragen obwohl du aktiv ein /16er benutzt.

Bei soviel Pfuscherei im Setup weiss man ja gar nicht wo man zuerst suchen soll und macht den Hilfethread hier nur unnötig länger weil du einfach nicht sauber arbeitest.

Was jetzt bei der Sichtung der Switches und deren Setups herauskommt wollen wir hier vermutlich alle besser gar nicht wissen... Das dürfte wohl ein ähnliches Chaos werden ! Der Fehler spricht ja schon dafür....
Es bleibt also spannend...

Wenn's das denn nun war bitte dann auch nicht vergessen deinen Thread hier als erledigt zu markieren !
Wie kann ich einen Beitrag als gelöst markieren?