Weiterleitung TCP-Pakete
Liebe Mitbestreiter ...
ich suche eine Lösung für mein kleines Problem einer Software.
Kurz zum Szenario ...
Es gibt eine Firmenzentrale (Standort A) und eine Liegenschaft (Standort B). Beide sind über einen IPSec-Tunnel(IKEv2) verbunden.
Die beiden Endgeräte LANCom R88 und Mikrotik CCR1016 arbeiten sauber und es gibt soweit Netzwerktechnisch keine Probleme.
Der Tunnel wird über 2 externe IP-Adressen (v4) aufgebaut. Zum Standort A gehört das lokale Netz 192.168.99.0/24 und im Standort B verteilen sich die zu erreichenden Endgeräte (TCS, Sontex) in ein 10.255.0.0/16 Netz.
Das Routing funktioniert sauber und "fehlerfrei". Die lokalen IP-Adressen (10.255.0.0/16) an Standort B sind auf einer LAN-Bridge aufgesetzt. In diese befinden sich alle nötigen Interfaces.
Wenn ich also einen Ping sende von einem PC(Standort A) mit der IP 192.168.99.99 an eine IP (10.255.205.2) an Standort B kommt es sauber sichtbar auf der Bridge nach 29ms an.
Auch andere Dienste laufen sauber auf der LAN-Bridge auf.
Nun habe ich aber eine Software, bei dem kommen die Pakte(für Destination TCP/Port 966) nicht auf der Bridge an, sondern auf dem physikalischen Interface vom WAN-Port an ... also als Input .
Somit können die Anfragen natürlich nicht die IP-Bereiche der LAN-Bridge erreichen.
Nun suche ich eine Möglichkeit über NAT ... die INPUT-Pakete vom Interface SFP1 in die LAN-Bridge (10.255.0.0/16) weiterzuleiten.
Gibt es dafür eine Möglichkeit ... also über eine NAT-Regel ... oder muss ich schon am PC etwas ändern?
Vielen Dank für eure Anstöße ...
ich suche eine Lösung für mein kleines Problem einer Software.
Kurz zum Szenario ...
Es gibt eine Firmenzentrale (Standort A) und eine Liegenschaft (Standort B). Beide sind über einen IPSec-Tunnel(IKEv2) verbunden.
Die beiden Endgeräte LANCom R88 und Mikrotik CCR1016 arbeiten sauber und es gibt soweit Netzwerktechnisch keine Probleme.
Der Tunnel wird über 2 externe IP-Adressen (v4) aufgebaut. Zum Standort A gehört das lokale Netz 192.168.99.0/24 und im Standort B verteilen sich die zu erreichenden Endgeräte (TCS, Sontex) in ein 10.255.0.0/16 Netz.
Das Routing funktioniert sauber und "fehlerfrei". Die lokalen IP-Adressen (10.255.0.0/16) an Standort B sind auf einer LAN-Bridge aufgesetzt. In diese befinden sich alle nötigen Interfaces.
Wenn ich also einen Ping sende von einem PC(Standort A) mit der IP 192.168.99.99 an eine IP (10.255.205.2) an Standort B kommt es sauber sichtbar auf der Bridge nach 29ms an.
Auch andere Dienste laufen sauber auf der LAN-Bridge auf.
Nun habe ich aber eine Software, bei dem kommen die Pakte(für Destination TCP/Port 966) nicht auf der Bridge an, sondern auf dem physikalischen Interface vom WAN-Port an ... also als Input .
Somit können die Anfragen natürlich nicht die IP-Bereiche der LAN-Bridge erreichen.
Nun suche ich eine Möglichkeit über NAT ... die INPUT-Pakete vom Interface SFP1 in die LAN-Bridge (10.255.0.0/16) weiterzuleiten.
Gibt es dafür eine Möglichkeit ... also über eine NAT-Regel ... oder muss ich schon am PC etwas ändern?
Vielen Dank für eure Anstöße ...
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 653900
Url: https://administrator.de/contentid/653900
Ausgedruckt am: 04.11.2024 um 22:11 Uhr
13 Kommentare
Neuester Kommentar
Nennt sich DSTNAT und wird mit einem Eintrag auf der PREROUTING Chain vorgenommen.
https://mikrotik-blog.de/mikrotik-port-forwarding-portweiterleitung-anle ...
Wenn die FORWARD Chain zusätzlich blockt auch hier eine Filterregel anlegen die den Traffic ans Zieldevice zulässt.
Gruß SK
https://mikrotik-blog.de/mikrotik-port-forwarding-portweiterleitung-anle ...
Wenn die FORWARD Chain zusätzlich blockt auch hier eine Filterregel anlegen die den Traffic ans Zieldevice zulässt.
Gruß SK
Nein eine Rückroute braucht es nicht wenn der Router Default GW vom Ziel ist und der Router den NAT Eintrag ja in der NAT State Tabelle führt, aber wie gesagt musst du auch die FORWARD Chain im Filter beachten und dort den Traffic auch freischalten, sonst bleibt der in der Forward Chain hängen.
Dann blockt das Device alles was nicht aus dem selben Subnetz kommt, also die Firewall des Devices selbst checken!
Wenn dem so wäre (was bei solchen Dingern oft konfiguriert ist) und du kannst die Firewall des Devices selbst nicht beeinflussen musst du ein zusätzliches SRCNAT am Mikrotik für diese Pakete vornehmen was dann die Absenderadresse der Pakete auf die des Routers umschreibt so das das Device denkt die Pakete kommen aus dem selben Subnetz.
Ein einfaches tracert und ein zus. Wireshark Mitschnitt zeigt dir sofort was Sache ist , und du musst nicht mehr rum raten!
Wenn dem so wäre (was bei solchen Dingern oft konfiguriert ist) und du kannst die Firewall des Devices selbst nicht beeinflussen musst du ein zusätzliches SRCNAT am Mikrotik für diese Pakete vornehmen was dann die Absenderadresse der Pakete auf die des Routers umschreibt so das das Device denkt die Pakete kommen aus dem selben Subnetz.
Ein einfaches tracert und ein zus. Wireshark Mitschnitt zeigt dir sofort was Sache ist , und du musst nicht mehr rum raten!
Kennt hier leider keiner den exakten Aufbau deines Netzes
Versuche noch eine Regel am Router wo das Endgerät angeschlossen ist .
Ach nee, noch ne Info die fehlt, dann verwundert das nicht .... Freitag 🐟
Mach eine Zeichnung vom Aufbau und poste deine Mikrotik Settings in Textform. Sonst müssen wir hier nur rumraten und bis zum nimmerleinstag raten was tatsächlich Sache ist! Fakten zählen.
Aber sollte das Interface (Sontex) in Interface (CRS) senden ...(input) ... dann brauche ich dort auch eine Regel ... oder irre ich?
Den Satz verstehe ich leider nicht, bitte verständlich beschreiben, sonst bin ich raus.Zitat von @IP-PUPPI:
... ich hatte vorhin gefragt : ... benötige ich für die Rückrichtung,... also vom Gerät auch eine NAT-Regel ...
... da bekam ich die Antwort : Nein ...
Genau, das ist aber wie ich geschrieben habe abhängig davon welchen Router das Device als DefaultGW nutzt. Wäre der Mikrotik nämlich nicht das Default GW des Devices, müsste man entweder dem anderen GW sagen wohin es die Pakete schicken muss oder dem Device in seiner Routing-Tabelle dies mitteilen. Bei normalem DSTNAT ist im Normalfall keine weitere NAT Regel nötig weil der Router eine NAT-State Table führt in der er die Rückpakete entsprechend die Absenderadresse des Routers automatisch wieder umschreibt!... ich hatte vorhin gefragt : ... benötige ich für die Rückrichtung,... also vom Gerät auch eine NAT-Regel ...
... da bekam ich die Antwort : Nein ...
... zum Thema "sonst bin ich raus : Wenn ein Interface (auch Mitgleid Bridge) ein Input bekommt, erzeugt er dann auch gleichzeitig ein Forward?
Erst einmal INPUT ist alles was an den ROUTER selbst gerichtet ist! Die FORWARD-Chain passieren alle Pakete die der Router weiterleitet also das Ziel ein anderes als der Router selbst oder ein anderes Interface ist. Schau dir die Packet-Flow Grafik einmal ganz genau an dann verstehst du auch was da intern passiert. Dieses Verständnis ist essentiell um Firewalls wirklich zu verstehenhttps://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Bei einer Bridge fließt am Ende alles aus dem Bride-Interface selbst wenn es an ein anderes Subnetz geht (außer wir sprechen wir von VLANs auf der Bridge das ist dann nochmal was anderes).
Hast du das verstanden und dann noch Zweifel hilft wie gesagt ein einfacher Wireshark Trace deine Zweifel oder evt. Fehlverhalten/Misskonfiguration aufzuklären.