Packet-Tracer Fails Subtype: rpf-check Result: DROP

KB ID 000904 

Problem

I love packet-tracer, I use it a lot, especially when I’ve been told that the firewall I’ve installed is stopping a particular port. I had set up a simple port forward the other day, and when I went to check it with packet-tracer this happened.

Petes-ASA# packet-tracer input outside tcp 123.123.123.123 443 192.168.1.10 443

<——-Output removed——–>

Phase: 7 Type: NAT Subtype: rpf-check Result: DROP Config: object network Web-Server-INT nat (inside,outside) static Web-Server-EXT Additional Information:

<——-Output removed——–>

Solution

This happens because the packet-tracer command is expecting to see the address that exists on the outside interface. So it’s the opposite way round to the way you would write an ACL. (Unless you are an old school Cisco tech, then it’s the same way we used to write ACL’s (before version 8.3)).

So, as I’m port forwarding the port that I’m tracing (tcp port 443 or https if you prefer) from the outside interface (100.100.100.100), that’s the IP address I should be using.

Note: If you are testing a static translation, then you would use the public IP for testing inbound traffic.

Petes-ASA# packet-tracer input outside tcp 123.123.123.123 443 100.100.100.100 443

Phase: 1 Type: UN-NAT Subtype: static Result: ALLOW Config: object network Web-Server-INT nat (inside,outside) static Web-Server-EXT Additional Information: NAT divert to egress interface inside Untranslate Web-Server-EXT/443 to Web-Server-INT/443

Phase: 2 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group inbound in interface outside access-list inbound extended permit tcp any4 object Web-Server-INT eq https Additional Information:

Phase: 3 Type: NAT Subtype: per-session Result: ALLOW Config: Additional Information:

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

Phase: 5 Type: Subtype: Result: ALLOW Config: Additional Information:

Phase: 6 Type: VPN Subtype: ipsec-tunnel-flow Result: ALLOW Config: Additional Information:

Phase: 7 Type: NAT Subtype: rpf-check Result: ALLOW Config: object network Web-Server-INT nat (inside,outside) static Web-Server-EXT Additional Information:

Phase: 8 Type: NAT Subtype: per-session Result: ALLOW Config: Additional Information:

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

Phase: 10 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 5844584, packet dispatched to next module

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

Do the same from the ADSM

As you can see below, the same thing happens if you use the graphical Packet Tracer in the ASDM

Packet Tracer rpf-check Fails

Packet Tracer Inbound Packet Works

Related Articles, References, Credits, or External Links

NA

 

Author: Migrated

Share This Post On