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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide