RPF Violation bei Statischem NAT Eintrag

keksdieb
Goto Top
moin moin zusammen,

Bin mal wieder am Cisco Studium und versuch ein statisches NAT für einen DMZ Server einzurichten.
Allerdings hakt es da irgendwie gewaltig...

Die ACL passen soweit, ich bekommen eine Meldung im Syslog, das die Verbindung aufgebaut wird.

Kurz danach kommt dann folgende Meldung im Syslog:

Im Packet Tracer zeigt er mir bei gleichem Beispiel ein RPF Fehler an.


Die Access listen passen alle, es wird ja auch versucht eine Verbindung aufzubauen. Allerdings scheitert er an der NAT Regel und ich verstehe nicht warum.

Hier der Teil der NAT Config:

Hoffe, ihr könnt mich erleuchten :) face-smile

Gruß Keksdieb

Content-Key: 207380

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

Ausgedruckt am: 16.05.2022 um 21:05 Uhr

Mitglied: aqui
aqui 03.06.2013 aktualisiert um 12:16:44 Uhr
Goto Top
Ist zu erwarten ! Hier ist das Warum erklärt:
https://supportforums.cisco.com/thread/1003401
bzw.
https://learningnetwork.cisco.com/thread/39723
Ist jetzt aber etwas ins Blaue geraten da du weder Konfig oder einen Auszug der NAT Konfig hier gepostet hast noch uns mitteilst was für HW (geraten: vermutlich ASA) du verwendest :-( face-sad
Mitglied: keksdieb
keksdieb 03.06.2013 um 12:24:28 Uhr
Goto Top
Bah, Fehler von meiner Seite:

HW = ASA 5510 (Version 8.4)

Config ist etwas lang, da hier mal der NAT Auszug (dachte der kleine Fitzel zum Host reicht ;) ):


Vielen Dank aqui

Gruß Keksdieb
Mitglied: aqui
aqui 03.06.2013 um 13:04:38 Uhr
Goto Top
Na ja wie oben bei dir das Problem der asymetrischen SNAT und DNAT Sessions. Das musst du beseitigen, dann klappts auch.
Mitglied: keksdieb
keksdieb 03.06.2013 aktualisiert um 14:05:21 Uhr
Goto Top
Jupp, so hab ich das auch raus gelesen...

Aber dann hab ich das Problem, dass die Arbeitsplatz PC´s nicht mehr ins Internet kommen, da das SNAT ja nicht mehr geht...

Vielen Dank für deine Hilfe :) face-smile

Gruß Keks
Mitglied: keksdieb
keksdieb 03.06.2013 um 14:30:56 Uhr
Goto Top
Jetzt stehe ich total auf dem Schlauch...

Ich habe die alle NAT Einträge gelöscht und nur noch die Einträge für den Server hinzugefügt.
Allerdings kommt immer noch ein Syn Timeout im Syslog und der Verbindungsaufbau scheitert...

Grml, das NAT in der ASA ist ja mal ein ganz anderer schnack als im normalen Router....
Mitglied: keksdieb
keksdieb 03.06.2013 aktualisiert um 14:47:07 Uhr
Goto Top
Hier nochmal ein Auszug aus dem Packet Tracer:


packet-tracer input inside-prod tcp 192.168.0.221 3389 8.8.8.8 4711

Und andere Richtung meckert die ASA:

Da jetzt nur die eine NAT Regel da ist, kann RFP doch gar nicht mehr stimmen, oder sehe ich das falsch?

Gruß und danke für eure Geduld...

Keks
Mitglied: aqui
aqui 03.06.2013 um 17:16:51 Uhr
Goto Top
Für die Arbeitsplatz Rechner nimmt man in der Regel ja auch einen Pool oder noch besser Port Adress Translation (PAT)
SNAT macht man nur für Server.
Wenn du das sauber trennst muss es funktionieren.
Mitglied: keksdieb
keksdieb 03.06.2013 um 19:11:09 Uhr
Goto Top
Hmm,

wie meinst du das mit dem Pool? Das verstehe ich nicht so ganz (kann auch an der späten Stunde liegen)

Gruß Keks
Mitglied: keksdieb
keksdieb 03.06.2013 um 19:30:39 Uhr
Goto Top
Okay, das mit dem Pool würde ich gerne wissen, aber nachdem der Serveradmin die FW abgeschaltet hat läuft es...


grml grml.

Gruß Keks
Mitglied: keksdieb
keksdieb 04.06.2013 um 09:47:12 Uhr
Goto Top
Also, es funktioniert nach abgeschalteter Firewall (auf dem RDP Server) mit dem NAT.

Für die Fehlersuche habe ich den packet-Tracer genommen, allerdings anders als in meinem Unwissenden Beispiel oben:

Befehl auf der ASA

In meinem Beispiel sa das dann so aus:

Es werden alle Phasen des Verbindungsaufbaus beschrieben.

In Phase 1 wird die öffentliche IP Adresse (123.456.789.123 in die lokale umgewandelt (192.168.0.220).
In Phase 6 wird dann überprüft ob der Weg zurück auch richtig ist (RPF - Reverse Path Fail)

Dazwischen sieht man die einzelnen anderen Schritte, wie in Phase 3 das "abklappern" der ACL.

Im ersten Step habe ich selber einen RPF Violation verursacht, weil ich den Packet Tracer mit den falschen Parametern gestartet habe:
Es macht natürlich keinen Sinn, eine interne Adresse auf dem Outside Interface zu übersetzen....

Das Ergebnis:
In Phase 6 kann man sehen, wie die Übersetzung versucht wird.
Es wird also nicht die interne Adresse nach aussen übersetzt, sondern die externe Adresse nach innen, wenn man den Fehler korrigiert hat, klappt es auch mit dem Verständnis für die NAT Einträge auf der ASA...

Ach ja, die Statischen NAT Einträge habe ich in der Reihenfolge nach oben gesetzt und die dynamischen NAT/PAT Einträge über die Network Objects angelegt. (ich glaube, dass ist es, was aqui mit Pools meint, bin mir aber nicht ganz sicher).

Die komplette NAT Konfig sieht jetzt so aus:

Vielen Dank an aqui für die Unterstützung und vor allem für die Geduld!
Das Supportforum von Cisco hat auch noch Schützenhilfe geleistet (https://supportforums.cisco.com).

Gruß Keksdieb