cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1747
Views
5
Helpful
4
Replies

ASA 8.2 NAT rpf-check drops

mmelbourne
Level 5
Level 5

Hi,

I have an ASA 8.2 firewall, with the following configuration:

no nat-control

!

interface Ethernet0/0

nameif inside

security-level 100

ip address 10.1.1.1 255.255.255.0

!

interface Ethernet0/1

nameif ril

security-level 50

ip address 192.168.0.1 255.255.255.0

!

interface Ethernet0/2

nameif outside

security-level 0

ip address 172.16.10.1 255.255.255.0

route inside 10.2.2.0 255.255.255.0 10.1.1.10

route ril 192.168.1.1 255.255.255.0 192.168.0.10

!

nat (inside) 1 0.0.0.0 0.0.0.0

global (outside) 1 interface

!

nat (ril) 2 access-list VPN-POLICY-NET outside

global (inside) 2 10.1.1.254

!

access-list VPN-POLICY-NAT permit ip 192.168.1.0 255.255.255.0 10.2.2.0 255.255.255.0

Here, 192.168.1.0/24 is reachable via a router connected to 192.168.0.10 on the ril (security=50) interface, and 10.2.2.0/24 is reachable via a router connected to the inside (security=100) network on 10.1.1.10.

For traffic with source 192.168.1.0/24 and destined for the 10.2.2.0/24 network behind the inside interface, I wish to PAT the source address to 10.1.1.254. I hoped this would be achieved by the use of 'outside' keyword on the NAT statement to permit traffic to be PATed from a lower-to-higher security interface. A packet-tracer output shows this to fail on the NAT rpf-check because their is an overlap between "nat (inside) 1 0.0.0.0 0.0.0.0", when the range defined in the "nat (inside) 1" statement includes 10.2.2.0/24.

Phase: 7

Type: NAT

Subtype: rpf-check

Result: DROP

Config:

nat (inside) 1 0.0.0.0 0.0.0.0

   match ip inside any ril any

     dynamic translation to pool 1 (No matching global)

     translate_hits = 0, untranslate_hits = 0

Additional Information:

Is there any way to get this to work (and maintain PAT from inside networks 10.1.1.0/24 and 10.2.2.0/24) to the outside interface.

Cheers,

Matt

2 Accepted Solutions

Accepted Solutions

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Getting a bit rusty with the 8.2 (and below) NAT configuration format. I wasnt personally expecting a RPF DROP for this traffic.

I guess the next thing I would try is to configure a Static Identity NAT for the network behind "inside" towards the "ril" interface

static (inside,ril) 10.2.2.0 10.2.2.0 netmask 255.255.255.0

After this the same "packet-tracer" output should show the destination IP address matching this "static" command in an UN-NAT phase where the ASA untranslates the destination. Later on your should see the Dynamic Policy PAT for the source address.

- Jouni

View solution in original post

I think that you should actually configure a policy NAT that anyone coming from the 192.168.1.0/24 destine to the 10.2.2.0/24 should be translated to 10.1.1.254.

!

access-list VPN-POLICY-NAT permit ip 192.168.1.0 255.255.255.0 10.2.2.0 255.255.255.0

nat (ril) 2 access-list VPN-POLICY-NET outside

global (inside) 2 10.1.1.254

access-list policy_nat permit ip 10.2.2.0 255.255.255.0 192.168.1.0 255.255.255.0

static (inside,ril) 10.2.2.0 access-list policy_nat

Run the packet tracer and let me know if it works

Value our effort and rate the assistance!

Value our effort and rate the assistance!

View solution in original post

4 Replies 4

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Getting a bit rusty with the 8.2 (and below) NAT configuration format. I wasnt personally expecting a RPF DROP for this traffic.

I guess the next thing I would try is to configure a Static Identity NAT for the network behind "inside" towards the "ril" interface

static (inside,ril) 10.2.2.0 10.2.2.0 netmask 255.255.255.0

After this the same "packet-tracer" output should show the destination IP address matching this "static" command in an UN-NAT phase where the ASA untranslates the destination. Later on your should see the Dynamic Policy PAT for the source address.

- Jouni

I think that you should actually configure a policy NAT that anyone coming from the 192.168.1.0/24 destine to the 10.2.2.0/24 should be translated to 10.1.1.254.

!

access-list VPN-POLICY-NAT permit ip 192.168.1.0 255.255.255.0 10.2.2.0 255.255.255.0

nat (ril) 2 access-list VPN-POLICY-NET outside

global (inside) 2 10.1.1.254

access-list policy_nat permit ip 10.2.2.0 255.255.255.0 192.168.1.0 255.255.255.0

static (inside,ril) 10.2.2.0 access-list policy_nat

Run the packet tracer and let me know if it works

Value our effort and rate the assistance!

Value our effort and rate the assistance!

If that does not work I think it could be that the outside PAT goes first and all you need to add is the next rule:

access-list policy_nat permit ip 10.2.2.0 255.255.255.0 host 10.1.1.254

Value our effort and rate the assistance!

Value our effort and rate the assistance!

I applied the static identity policy NAT (to be as specific as possible), and this results in an inital "un-nat" set in the packet-tracer, and then the NAT rpf check succeeds - I didn't need to include the ACE above referencing the PATed address.

(I'd like to think that the "twice NAT" changes in 8.3+ would have made this simpler).

Many thanks,

Matt

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: