topic RPF-CHECK Failure in Network Security

RPF-CHECK Failure

mvann — Tue, 12 Mar 2019 01:35:24 GMT

Hey gang, I'm trying to NAT a server to an outside interface on an ASA running 8.4. It isn't working and when I run packet tracer I see that I'm droping at the RPF-CHECK.

Phase: 5

Type: NAT

Subtype: rpf-check

Result: DROP

Config:

object network obj-192.168.1.254

nat (inside,outside) static 50.198.198.19

Additional Information:

Below is my nat config.

object network obj-192.168.1.254

nat (inside,outside) static 50.198.198.19

Can somebody point me in the right direction on this?

Thanks

RPF-CHECK Failure

Jouni Forss — Fri, 26 Apr 2013 14:19:43 GMT

Hi,

Probably something to do with overlapping NAT rules.

Could you share the whole "packet-tracer" command and its whole output

If that doesnt tell anything then might need to see the whole NAT configurations.

- Jouni

RPF-CHECK Failure

mvann — Fri, 26 Apr 2013 20:42:37 GMT

JouniForss,

Thanks for the help. Here are the requested outputs.

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.1.0 255.255.255.0 inside

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit tcp 173.226.30.0 255.255.255.0 host 192.168.1.254 eq https
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: HOST-LIMIT
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network obj-192.168.1.254
nat (inside,outside) static 50.198.198.19
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

object network obj-192.168.1.254

nat (inside,outside) static 50.198.198.19

access-list outside_access_in line 3 extended permit tcp 173.226.30.0 255.255.255.0 host 192.168.1.254 eq ssh (hitcnt=0) 0x66fd5e9c

access-list outside_access_in line 4 extended permit tcp 173.226.30.0 255.255.255.0 host 192.168.1.254 eq https (hitcnt=8) 0x4d4c811c

RPF-CHECK Failure

palanivelm — Fri, 26 Apr 2013 21:01:55 GMT

can you please confirm your packet-tracer command was like below?

packet-tracer input outside tcp 173.226.30.1 1500 50.198.198.19 443

RPF-CHECK Failure

Jouni Forss — Fri, 26 Apr 2013 21:19:18 GMT

Hi,

You didnt show the "packet-tracer" command you used.

It seems to me that you are using the command with wrong parameters since the connection specified by the "packet-tracer" didnt match any NAT rule at all.

You were probably using the real IP address of the host as the destination IP address.

This would explain why we see the RPF Fail. Since on the other direction it matches the NAT.

- Jouni

RPF-CHECK Failure

mvann — Mon, 29 Apr 2013 18:34:34 GMT

JouniForss,

I checked and you are correct, I was entering the packet tracer command wrong. I assumed that because the FW rules had changed to reflect the true destination, not a nat'ed address, that I should do the same for packet tracer. I appreciate you pointing that out.

Using the correct packet-tracer commands everything appears to work correctly. Unfortunatly only one of the two NAT'ed IPs responds. I'll do some digging and post relevant outputs in a different post when I get my head around the current issue.