10
RPF Violation bei Statischem NAT Eintrag
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
Gruß Keksdieb
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.
6 Jun 03 2013 11:35:57 302013 80.187.107.132 10198 XXX.XXX.XXX.XXX 3389
Built inbound TCP connection 694033 for outside:80.187.107.132/10198 (80.187.107.132/10198) to inside-prod:XXX.XXX.XXX.XXX/3389 (XXX.XXX.XXX.XXX/3389)Kurz danach kommt dann folgende Meldung im Syslog:
6 Jun 03 2013 11:36:27 302014 80.187.107.132 10198 XXX.XXX.XXX.XXX 3389 Teardown TCP connection 694033 for outside:80.187.107.132/10198 to inside-prod:XXX.XXX.XXX.XX/3389 duration 0:00:30 bytes 0 SYN TimeoutIm Packet Tracer zeigt er mir bei gleichem Beispiel ein RPF Fehler an.
5 Jun 03 2013 11:56:32 305013 XXX.XXX.XXX.XXX 3389
Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src outside:8.8.8.8/4611 dst inside-prod:XXX.XXX.XXX.XXX/3389 denied due to NAT reverse path failureDie 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:
object network Test
nat (inside-prod,outside) static interface service tcp 3389 3389 Hoffe, ihr könnt mich erleuchten
Gruß Keksdieb
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 207380
Url: https://administrator.de/forum/rpf-violation-bei-statischem-nat-eintrag-207380.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
10 Kommentare
Neuester Kommentar
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
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
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
HW = ASA 5510 (Version 8.4)
Config ist etwas lang, da hier mal der NAT Auszug (dachte der kleine Fitzel zum Host reicht ;) ):
nat (inside-prod,outside) source static any any destination static NETWORK_OBJ_Privat NETWORK_OBJ_Privat no-proxy-arp route-lookup description VPN Einwahl
nat (inside-lab,outside) source static any any destination static Network_Obj_Lab Network_Obj_Lab
!
object network Network_Obj-Productiv
nat (any,outside) dynamic interface
object network Network_Obj_Lab
nat (any,outside) dynamic interface
object network Test
nat (inside-prod,outside) static interface service tcp 3389 3389
!Vielen Dank aqui
Gruß Keksdieb
Na ja wie oben bei dir das Problem der asymetrischen SNAT und DNAT Sessions. Das musst du beseitigen, dann klappts auch.
2
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
Gruß Keks
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
Gruß Keks
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....
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....
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
packet-tracer input inside-prod tcp 192.168.0.221 3389 8.8.8.8 4711
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside-prod_access_in in interface inside-prod
access-list inside-prod_access_in extended permit ip object Network_Obj-Productiv any log debugging
Additional Information:
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
object network Test
nat (inside-prod,outside) static interface service tcp 3389 3389
Additional Information:
Static translate 192.168.0.221/3389 to XXXXXXXX/3389
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 6385, packet dispatched to next module
Result:
input-interface: inside-prod
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allowUnd andere Richtung meckert die ASA:
packet-tracer input outside tcp 8.8.8.8 4711 192.168.0.221 3389 de$
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.0.0 255.255.255.0 inside-prod
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit ip any any log debugging
Additional Information:
Forward Flow based lookup yields rule:
in id=0xad5d5080, priority=13, domain=permit, deny=false
hits=591, user_data=0xaa7ce7c0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=outside, output_ifc=any
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xad67a060, priority=0, domain=inspect-ip-options, deny=true
hits=6228, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=outside, output_ifc=any
Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xacf04f90, priority=13, domain=ipsec-tunnel-flow, deny=true
hits=592, user_data=0x0, cs_id=0x0, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=outside, output_ifc=any
Phase: 6
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network Test
nat (inside-prod,outside) static interface service tcp 3389 3389
Additional Information:
Forward Flow based lookup yields rule:
out id=0xad5d49f8, priority=6, domain=nat-reverse, deny=false
hits=12, user_data=0xadd43660, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=192.168.0.221, mask=255.255.255.255, port=3389, dscp=0x0
input_ifc=outside, output_ifc=inside-prod
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside-prod
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured ruleDa 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
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.
SNAT macht man nur für Server.
Wenn du das sauber trennst muss es funktionieren.
2
Hmm,
wie meinst du das mit dem Pool? Das verstehe ich nicht so ganz (kann auch an der späten Stunde liegen)
Gruß Keks
wie meinst du das mit dem Pool? Das verstehe ich nicht so ganz (kann auch an der späten Stunde liegen)
Gruß Keks
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
grml grml.
Gruß Keks
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
Für die Fehlersuche habe ich den packet-Tracer genommen, allerdings anders als in meinem Unwissenden Beispiel oben:
Befehl auf der ASA
packet-tracer input "outside-interface" "protocol" "externe ip" "externer port" "eigene öffentliche IP" "weitergeleiteter Port" In meinem Beispiel sa das dann so aus:
packet-tracer input outside tcp 8.8.8.8 11234 123.456.789.123 3389
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
object network Network_Obj_RDP
nat (inside-prod,outside) static interface service tcp 3389 3389
Additional Information:
NAT divert to egress interface inside-prod
Untranslate 123.456.789.123/3389 to 192.168.0.220/3389
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside-in in interface outside
access-list outside-in extended permit tcp any object Network_Obj_RDP eq 3389 log debugging
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network Network_Obj_RDP
nat (inside-prod,outside) static interface service tcp 3389 3389
Additional Information:
Phase: 7
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:
Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 9
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:
Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 959, packet dispatched to next module
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside-prod
output-status: up
output-line-status: up
Action: allowEs 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:
packet-tracer input outside tcp 8.8.8.8 4567 192.168.0.220 3389
Das Ergebnis:
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.0.0 255.255.255.0 inside-prod
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside-in in interface outside
access-list outside-in extended permit tcp any object Network_Obj_RDP eq 3389 log debugging
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network Network_Obj_RDP
nat (inside-prod,outside) static interface service tcp 3389 3389
Additional Information:
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside-prod
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured ruleEs 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:
nat (inside-prod,outside) source static Network_Obj_RDP interface service RDP RDP
nat (inside-prod,outside) source static any any destination static NETWORK_OBJ_192.168.0.96_28 NETWORK_OBJ_192.168.0.96_28 no-proxy-arp route-lookup description VPN Einwahl
!
object network Network_Obj-Productiv
nat (inside-prod,outside) dynamic interface
!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
