trojan81
asked on
asa 5505 nat rpf-check DROP
Experts, see attached file of my asa config. It is a simple config.
I have an ipsec vpn tunnel established.
Encryption domain:
Local:192.168.3.0 255.255.255.0
Remote:10.75.100.0 255.255.255.0
The tunnel works and my users are able to RDP to 10.75.100.240. They have a preconfigured RDP icon with this IP.
The problem is I need to set their RDP icon to point to IP 19.39.160.240 (there is a specific reason for this not mentioned) without touching the VPN tunnel.
I can accomplish this by adding:
static (outside,inside) 19.39.160.240 10.75.100.240 netmask 255.255.255.255
After adding the NAT, I can point their RDP icon to 19.39.160.240 and it works fine. However, when I try to go to RDP to the real IP 10.75.100.240, it doesnt work anymore.
A packet tracer: packet-tracer input inside tcp 192.168.3.24 10000 10.75.100.240 3389 detailed
Phase: 10
Type: NAT
Subtype: rpf-check
Result: DROP
When I remove the static NAT, i'm able to RDP to it using 10.75.100.240 again. I'm curious as to why I can't rdp to 10.75.100.240 when the static NAT is in place. I would like the users to have the ability to reach both IPs so that I can put in the static NAT and take my time to repoint the RDP icons one at a time.
Even with the NAT in place, when they go to 10.75.100.240, it should hit the ACL inside_nat0_outbound and go out fine right?
Is traffic going out, but not able to come back?
asaEE.txt
I have an ipsec vpn tunnel established.
Encryption domain:
Local:192.168.3.0 255.255.255.0
Remote:10.75.100.0 255.255.255.0
The tunnel works and my users are able to RDP to 10.75.100.240. They have a preconfigured RDP icon with this IP.
The problem is I need to set their RDP icon to point to IP 19.39.160.240 (there is a specific reason for this not mentioned) without touching the VPN tunnel.
I can accomplish this by adding:
static (outside,inside) 19.39.160.240 10.75.100.240 netmask 255.255.255.255
After adding the NAT, I can point their RDP icon to 19.39.160.240 and it works fine. However, when I try to go to RDP to the real IP 10.75.100.240, it doesnt work anymore.
A packet tracer: packet-tracer input inside tcp 192.168.3.24 10000 10.75.100.240 3389 detailed
Phase: 10
Type: NAT
Subtype: rpf-check
Result: DROP
When I remove the static NAT, i'm able to RDP to it using 10.75.100.240 again. I'm curious as to why I can't rdp to 10.75.100.240 when the static NAT is in place. I would like the users to have the ability to reach both IPs so that I can put in the static NAT and take my time to repoint the RDP icons one at a time.
Even with the NAT in place, when they go to 10.75.100.240, it should hit the ACL inside_nat0_outbound and go out fine right?
Is traffic going out, but not able to come back?
asaEE.txt
ASKER
Ullas,
I think you are on the right track. Attached is the packet trace showing it working when I RDP to the NAT IP, and not working when I RDP to the real IP.
Is it even possible that both the NAT IP and the REAL IP still work simultaneously?
trace-working.txt
trace-notworking.txt
I think you are on the right track. Attached is the packet trace showing it working when I RDP to the NAT IP, and not working when I RDP to the real IP.
Is it even possible that both the NAT IP and the REAL IP still work simultaneously?
trace-working.txt
trace-notworking.txt
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
ullas,
That suggestion did not work. When I attempted to use the public IP it failed RPF check. I will award you the points since I went ahead and made the cut over night so I could make all changes without downtime.
That suggestion did not work. When I attempted to use the public IP it failed RPF check. I will award you the points since I went ahead and made the cut over night so I could make all changes without downtime.
the rpf drop you are getting should be due to the static (outside,inside) 19.39.160.240 10.75.100.240 netmask 255.255.255.255....the outgoing traffic is getting nat exempted by ACL inside_nat0_outbound but the return traffic must be hitting the static.
to clarify this can you please attach the output of your packet-tracer.
if that is the case then you might need to do a nat exempt on the outside interface for the return traffic ie from your remote pvt ip.