ASA rpf-check DROP, ASA checking NAT in the incorrect interface

Question

Hi
My current architecture is :
Internet <--> FW <--> ASA <--> LAN
                      FW <--> ASA
we have two links between ASA and the FW, the corresponding ASA interfaces are "outside" and "vpn"
the "outside" interface is used for browsing Internet, also for making some services accessible to our partners by doing NAT to our servers
the "vpn" interface is used to grant access to our LANs from remote Offices
let say that firewall rules are OK and the remote offices have access to the whole LAN by port 80
below the current configuration :
interface GigabitEthernet0/0
  nameif inside
 security-level 100
 ip address 192.168.1.2 255.255.255.0
interface GigabitEthernet0/1
 nameif outside
 security-level 0
 ip address 192.168.11.2 255.255.255.0
interface GigabitEthernet0/2
 nameif vpn
 security-level 0
 ip address 192.168.12.2 255.255.255.0
object-group network Inside_LANs
 network-object 192.168.3.0 255.255.255.0
 network-object 192.168.4.0 255.255.255.0
 network-object 192.168.5.0 255.255.255.0
access-list Inside-to-outside extended permit icmp object-group Inside_LANs any echo 
access-list Inside-to-outside extended permit udp any host TimeServer eq ntp 
access-list Inside-to-outside extended permit ip object-group Inside_LANs any 
global (outside) 1 interface
global (outside) 2 192.168.11.60 netmask 255.255.255.255
nat (inside) 1 access-list Inside-to-outside
nat (inside) 2 192.168.6.0 255.255.255.0
static (inside,outside) 192.168.11.10 192.168.2.10 netmask 255.255.255.255 
static (inside,outside) 192.168.11.11 192.168.2.11 netmask 255.255.255.255 
static (inside,outside) 192.168.11.12 192.168.2.12 netmask 255.255.255.255 
route inside 192.168.2.0 255.255.255.0 192.168.1.1 1
route inside 192.168.3.0 255.255.255.0 192.168.1.1 1
route inside 192.168.4.0 255.255.255.0 192.168.1.1 1
route inside 192.168.5.0 255.255.255.0 192.168.1.1 1
route inside 192.168.6.0 255.255.255.0 192.168.1.1 1
route vpn 192.168.20.0 255.255.255.0 192.168.12.1 1
our problem is that packets are dropped from remote office to LAN, we are getting the rpf-check drop in packet tracer
example 1 (to a server without NAT 192.168.2.13) ---> connection OK (not dropped)
remote office 192.168.20.55 to 192.168.2.13
Phase: 5
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 1 access-list Inside-to-outside
  match udp inside any inside host TimeServer eq 123
    dynamic translation to pool 1 (No matching global)
    translate_hits = 0, untranslate_hits = 0
Additional Information:
example 2 (to a server with static NAT 192.168.2.10) ---> connection OK (not dropped)
remote office 192.168.20.55 to 192.168.2.10
Phase: 6
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) 192.168.11.10 192.168.2.10 netmask 255.255.255.255 
  match ip inside host 192.168.2.10 outside any
    static translation to 192.168.11.10
    translate_hits = 76643, untranslate_hits = 188597
Additional Information:
example 3 (to a host with dynamic ACL NAT 192.168.4.40) ---> connection NOK (dropped)
remote office 192.168.20.55 to 192.168.4.40
Phase: 5
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
nat (inside) 1 access-list Inside-to-outside
  match ip inside 192.168.4.0 255.255.255.0 vpn any
    dynamic translation to pool 1 (No matching global)
    translate_hits = 1, untranslate_hits = 0
Additional Information:
example 4 (to a host with dynamic Network NAT 192.168.6.30) ---> connection NOK (dropped)
remote office 192.168.20.55 to 192.168.6.30
Phase: 5
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
nat (inside) 2 192.168.6.0 255.255.255.0
  match ip inside 192.168.6.0 255.255.255.0 vpn any
    dynamic translation to pool 2 (No matching global)
    translate_hits = 117, untranslate_hits = 0
Additional Information:
our questions :
1) why ASA don't check the reverse path route before checking the NAT ?
 if it does, the route back to the office is set to the "vpn" interface (route vpn 192.168.20.0 255.255.255.0 192.168.12.1 1), so ASA don't have to check NAT in other interface, currently it's checking the NAT in the "outside" interface even if it's not the route back to the office
2) why it's working for static NAT servers and Not working for the dynamic NAT ones ?
when ASA check a server with static NAT it find  a match in the outside interface but even so it discard it and the connection Work. (example 2)
when ASA check a server/host with dynamic NAT (ACL or Network) if find a match in the outside interface but drop the connection
3) we know that this behavior can be solved by adding a NAT exception for the dynamic NAT in the "outside" interface (nat (inside) 0 access-list Inside-NAT-Exceptions) but :
why ASA checking the global NAT even if it's not the correct interface ?
Why it's working for static NAT and not working for the dynamic one ?
Thanks a lot

Answer 1

Hi,
It would be easier to troubleshoot if you shared the complete "packet-tracer" command you used and the full output of the command.
But to me the situation in its current form looks the following.
Example 1
To me it seems this is working as it should. Connection is coming from "vpn" to "inside". There is no "static" configurations between "vpn" and "inside" and there is no "nat" command for "vpn" interface so the traffic should pass normally without any NAT related conflicts/problems as the traffic does not match any NAT configuration.
Notice that the ASA might show some unrelated NAT information in the output of the "packet-tracer" command (commands related to other interfaces). In those NAT Phase sections there is a section saying "Additional Information:" If there is no text after this text that means that this NAT has not been applied. I am not sure why the ASA lists some NAT configurations in the output that are not related. I have seen this in many occasions and do not know the reason and I have not really put any time/effort into understanding why it shows the unrelated information in the output.
Example 2
This seems to be working as expected also.
According to the configuration provided there is no existing NAT configurations related to either the source or destination IP address on the ASA between "vpn" and "inside" interface so the traffic passes through the ASA without facing any conflicts with NAT configurations.
Again, the "packet-tracer" shows NAT information unrelated to this situation. And again the "Additional Information:" section lists no additional information so the NAT listed is not applied.
Example 3 and 4
These tests fail as expected since there is a Dynamic Policy PAT configuration for both internal destination hosts that the remote users are trying to connect to. The problem comes from the fact that the initial direction from remote to internal does not match any NAT configuration and the reverse direction from internal to remote matches the Dynamic Policy PAT and therefore the connection attempt is dropped. The connection must match the same NAT configuration on both directions.
In this situation you would either have to configure NAT0, Static NAT , Static PAT or Static Policy NAT/PAT which all would prevent the connection from matching to the Dynamic Policy PAT (But would match the mentioned type of NAT in both directions as they have higher priority than Dynamic Policy PAT). Typically the prefererred solution would be to use NAT0 though you naturally have the option to use a NAT address if there is any overlap.
Hope this helps :)
- Jouni