Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

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

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

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Super Bronze

Hi, To be honest I am not

Hi,

 

To be honest I am not sure why the ASA/PIX firewalls behave this way but is a pretty common problem even in the most simple setups which have 3 interfaces configured on the firewall for example.

 

What I mean is that consider that you have for example interfaces "inside" , "dmz" and "outside". You configure "nat" for interface "inside" and corresponding "global" for the "outside" interface. Now you want to connect from "inside" to "dmz" and you have no other NAT configurations on the firewall other than the ones mentioned so far. In this case the result of connecting from "inside" to "dmz" will probably result the traffic matching the "nat" statement on the "inside" interface and since there is no matching "global" for the destination interface the traffic will be dropped. In these situations you usually tend to need a Static Identity NAT (translate address/subnet to itself) to prevent "inside" to "dmz" traffic from matching the "nat" statement at all.

 

So in your examples 3 and 4 it seems to me that the initially the traffic from the "vpn" to "inside" might not match any NAT configuration but the reverse direction from "inside" to "vpn" matches the "nat" configuration in each example. (Even though there is no corresponding "global" for the actual interface where the connection originated from)

 

As I said I am not sure why this happens. I guess the fact is that the the firewall just checks if the source address matches the "nat" statement on that interface and if it does it must have a matching "global" configuration. If not, its dropped.  That is ofcourse unless there is some overriding NAT configuration like NAT0 or Static NAT etc. which would need to be used in this case to prevent traffic matching the "nat" statement.

 

Hope this helps :)

 

- Jouni

 

 

 

4 REPLIES
Super Bronze

Hi, It would be easier to

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

New Member

Thanks a lot for your answer,

Thanks a lot for your answer, there is still one thing that i can not understand

in Example 3 & 4, you said :

"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 key word here is reverse direction, for me the traffic from internal to remote doesn't match a NAT configuration because for the simple reason that the Dynamic Policy PAT you are talking about concerns the outside interface and not the vpn one.

then for me, the reverse direction is also clean, no NAT at all

can i know why ASA checking a Dynamic Policy PAT configured on the "outside" interface while dealing with a traffic which concerns the "vpn" interface ?

i know that internal hosts match the ACL or the network, but this ACL or network are configured for NAT on the "outside" interface, so only traffic leaving from the "outside" interface will be NATed, not all traffic.

the traffic leaving from the "vpn" interface will stay unchanged, so the Dynamic Policy PAT must not interfere from inside to remote

Thanks

 

 

 

 

 

Super Bronze

Hi, To be honest I am not

Hi,

 

To be honest I am not sure why the ASA/PIX firewalls behave this way but is a pretty common problem even in the most simple setups which have 3 interfaces configured on the firewall for example.

 

What I mean is that consider that you have for example interfaces "inside" , "dmz" and "outside". You configure "nat" for interface "inside" and corresponding "global" for the "outside" interface. Now you want to connect from "inside" to "dmz" and you have no other NAT configurations on the firewall other than the ones mentioned so far. In this case the result of connecting from "inside" to "dmz" will probably result the traffic matching the "nat" statement on the "inside" interface and since there is no matching "global" for the destination interface the traffic will be dropped. In these situations you usually tend to need a Static Identity NAT (translate address/subnet to itself) to prevent "inside" to "dmz" traffic from matching the "nat" statement at all.

 

So in your examples 3 and 4 it seems to me that the initially the traffic from the "vpn" to "inside" might not match any NAT configuration but the reverse direction from "inside" to "vpn" matches the "nat" configuration in each example. (Even though there is no corresponding "global" for the actual interface where the connection originated from)

 

As I said I am not sure why this happens. I guess the fact is that the the firewall just checks if the source address matches the "nat" statement on that interface and if it does it must have a matching "global" configuration. If not, its dropped.  That is ofcourse unless there is some overriding NAT configuration like NAT0 or Static NAT etc. which would need to be used in this case to prevent traffic matching the "nat" statement.

 

Hope this helps :)

 

- Jouni

 

 

 

New Member

Thanks for your explanation,

Thanks for your explanation, indeed we are using NAT0, but like we have an 5520 ASA with an additional four module gigabit ethernet, then we have an inside interface, an outside one and 6 dmzs, so configuration is getting heavy while configuring NAT0 for traffic that is not NATed.

as we have many LAN network, we don't have much choice than using a dynamic NAT for the outside (Internet) to hide our addresses and secure connection with our second firewall (above ASA)

Thanks

 

1516
Views
0
Helpful
4
Replies