10-30-2013 02:24 PM - edited 03-11-2019 07:58 PM
Hello,
I have a issue where I need to port forward a port from the outside to a host on the inside. The outside interface is a priviate (RFC1918), which is NAT'd to an upstream firewall. The problem is rpf-check DROP and %ASA-5-305013:
Topology: Internet--> Provider running nat --> Outside:10.10.10.2 --> Inside:10.1.2.2 - Provider is translating 10.10.10.2 to a public IP address
Configuration:
interface Ethernet0/0
description Outside WAN
nameif outside
security-level 0
ip address 10.10.10.2 255.255.255.0
!
interface Ethernet0/2
description Inside
nameif inside
security-level 100
ip address 10.1.2.1 255.255.255.252
!
route outside 0.0.0.0 0.0.0.0 10.10.10.1
!
object network User-1
host 10.1.2.2
!
object network 80-server
host 10.1.2.2
nat (inside,outside) static interface service tcp 80 80
!
nat (inside,outside) after-auto source dynamic User-1 interface
!
access-list Outside-In extended permit tcp any object User-1 eq 80
!
access-list Inside extended permit tcp any any
!
access-group Outside-In in interface outside
access-group Inside in interface inside
Syslog:
%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src outside:x.x.x.x/80 dst inside:10.1.2.2/80 denied due to NAT reverse path failure
Packet Trace:
Phase: 11
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network 80-server
nat (inside,outside) static interface service tcp 80 80
Additional Information:
Forward Flow based lookup yields rule:
out id=0xad6f5890, priority=6, domain=nat-reverse, deny=false
hits=410, user_data=0xb1662d28, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=10.1.2.2, mask=255.255.255.255, port=80, tag=0, dscp=0x0
input_ifc=outside, output_ifc=inside
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
Any assistance would be appreciated.
Thanks!
10-30-2013 02:29 PM
Hi,
Typically the result would be caused if your "packet-tracer" command targeted the actual local IP address of the server (10.1.2.2) rather than the mapped IP address (10.10.10.2)
This results in the initial direction not matching any NAT rule while the reverse matches the actual Static PAT configuration you were attempting to test with the "packet-tracer" command.
If you are simulating a packet coming from the interface to your server then the correct "packet-tracer" command would be for example
packet-tracer input outside tcp 1.1.1.1 12345 10.10.10.2 80
Configuration shown above seems to be correct though.
- Jouni
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide