IP- und Port-Forwarding mit RouterOS 5.11

bitmuncher

Senior-Nerd
Irgendwie hab ich gerade einen Knoten im Hirn oder mache grundlegend was falsch. ;)

Also... ich habe hier einen Router mit RouterOS 5.11 und 5 Ethernet-Ports. Dieser ist an 2 verschiedene ISPs angebunden und an 2 verschiedene LAN. Also hat er folgende Interfaces

ether1-ISP1 = diverse feste IPs mit Direktverbindung zum Gateway (1.1.1.168/29, Gateway: 1.1.1.169)
ether2-ISP2 = PPPoE-Client-Einwahl bei ISP2 (dynamisch)
ether3-intern = LAN1 (10.10.0.0/24)
ether3-guests = LAN2 (10.10.0.0/24)

Aktuell gehen beide LAN über ISP2 in's Netz, was durch ein Masquerading gewährleistet wird:

Code:
 0   chain=srcnat action=masquerade src-address=10.10.0.0/24 
     out-interface=pppoe-ISP2 

 1   chain=srcnat action=masquerade src-address=10.10.1.0/24 
     out-interface=pppoe-ISP2

Nun sollen aber 2 Clients aus LAN1 (10.10.0.10 und 10.10.0.21) über externe IPs bei ISP1 verfügbar sein. Also...

1.1.1.170 -> 10.10.0.10
1.1.1.171 -> 10.10.0.21

Zu diesem Zweck hab ich erstmal ein entsprechendes Masquerading eingestellt:

Code:
chain=srcnat action=masquerade out-interface=ether1-ISP1

Doch schon beim ersten Destination-NAT gibt's Probleme. Sobald ich folgende Regel setze, ist die IP 1.1.1.171 von aussen gar nicht mehr erreichbar, d.h. sie antwortet weder auf Pings noch kann man mit dem Webserver verbinden:

Code:
 5   chain=dstnat action=dst-nat to-addresses=10.10.0.21 
     dst-address=1.1.1.171

Auch das Setzen eines Gateways auf ether1-ISP1 mit bevorzugter Quelle 10.10.0.21 scheint nicht der richtige Weg zu sein, da sich auch damit nichts mehr bewegt:

Code:
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
...
 3   S  0.0.0.0/0          10.10.0.21      ether1-ISP1                1
...

Hat jemand eine Idee, woran es hier hängt?

Falls es wichtig ist: Die Verbindungen für die statischen IPs auf ether1-ISP1 werden mittels Mangle/mark routing entsprechend markiert. Sobald das DST-NAT aus ist, ist unter den IPs das Router-Interface erreichbar, aber stattdessen sollen die internen Webserver erreichbar werden.
 
Hi,

kann es sein, dass du DST-ADDRESS und PREF-SRC vertauscht hast? (oder habe ich jetzt den Dreher in meinem Bild? )
 
Alles, was von 10.10.0.21 an irgendeine IP geht, soll halt über Interface ether1-ISP1 geleitet werden. Wird's aber irgendwie nicht, denn die Verbindung geht aktuell noch immer über ISP2.
 
Das Problem ist, dass da gar nichts zurück kommt. Wenn ich z.B. mittels Browser die entsprechende IP aufrufe, sendet der Browser Anfragen, auf die er keine Antworten bekommt. Innerhalb des LAN ist der Webserver aber problemlos erreichbar. Ein Ping wird übrigens beantwortet, wenn ich das DST-NAT nur für bestimmte Ports setze. Da antwortet dann also offensichtlich der Router.

Meine Vermutung ist mittlerweile, dass die Antworten über ISP2 rausgeschickt werden und daher nicht ankommen. Die Frage ist nur, wie ich das ändern kann, da ich ja offenbar keine direkte Route zwischen der 10.10.0.21 und ISP1 legen kann. Zumindest keine, die funktioniert. ;)
 
Und nun wird's noch seltsamer. Mit dem gleichen NAT-Regel ist ein Videoconferencing mit einer Tandberg-Anlage (10.10.0.21:* <- 1.1.1.171:*) problemlos möglich. Aber der Webserver den ich auf gleiche Weise forwarde (10.10.0.10:80 <- 1.1.1.170:80) lässt sich nicht aufrufen. Der Port wird von aussen als filtered angezeigt und antwortet nicht. Die IP-Pakete des Clients kommen zwar an, werden aber nicht beantwortet. Nutze ich ein mark_connection für diese Verbindungen/NATs, wird der Port als closed nach aussen angezeigt. Soweit ich weiss, setzt aber die Tandberg-Anlage ihre externe IP direkt in den Netzwerk-Paketen. Und nun stellt sich mir die Frage, ob ich ähnliches mit Linux auch irgendwie hinbekommen kann.

Ich hab auch nochmal überprüft, ob die Verbindungen zwischen den einzelnen Router-Ports funktionieren. Pings lassen sich durch die Source-Adressen problemlos an ihre Ziele senden.

Nachtrag: Ein traceroute vom Ziel-Rechner (10.10.0.10) auf die externe IP zeigt auch, dass kein Umweg über ISP2 gegangen wird, sondern dass er die IP direkt über den Router anspricht.
 
Zurück
Oben