01-07-2014 02:40 PM - edited 03-11-2019 08:26 PM
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
Solved! Go to Solution.
01-07-2014 03:09 PM
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
01-07-2014 10:01 PM
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!
01-07-2014 03:09 PM
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
01-07-2014 10:01 PM
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!
01-07-2014 10:03 PM
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!
01-08-2014 03:05 AM
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
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: