ASA Outside NAT Problem!!!

[andyc0313]

Hi everybody,

My situation is as follows:
My Pre 8.3 ASA is connected to two outside networks: the ISP with security level 0, and a separate agency network with security level 10.  We are having a problem connecting to the agency network from a L2L VPN tunnel coming through the ISP interface.  These VPN branch users can communicate with our entire corporate network and I'm currently using outside-to-outside nat to get them to talk to the internet out the same ISP interface they come in through, but they can't talk to the agency network at all. *All inside users have full communication with the agency network.*  

I receive the following error:
------------------------------
asa1# sh nat outside agency
ERROR: No matching NAT policy found
------------------------------
If I statically nat one user from the VPN branch to one of the agency pool addresses, I have full connectivity between that VPN user and the agency network.
This command makes it work: static (outside,agency) 16x.5x.1x.12x 10.18.1.1

My configuration:
nat (outside) 20 access-list vpn_outside_nat
nat (inside) 0 access-list NONAT
nat (inside) 30 access-list inside_nat_outbound
nat (inside) 20 0.0.0.0 0.0.0.0
global (agency) 20 16x.5x.1x.1x-1x.5x.1x.12x
global (agency) 20 16x.5x.1x.1x
global (outside) 20 20x.1x.2x.1x
global (outside) 10 20x.1x.2x.1x netmask 255.255.255.0
global (outside) 30 20x.1x.2x.1x netmask 255.255.255.255

access-list vpn_outside_nat extended permit ip 10.0.0.0 255.0.0.0 any

access-list NONAT extended permit ip any 10.0.0.0 255.0.0.0

access-list inside_nat_outbound extended permit ip host 192.168.1.12 any

Please let me know if you need any more information to help.  I appreciate any answers!  
Thanks!

[Marius Gunnerud]

Could you add the no nat to the agency interface and then issue the packet tracer again.

I see that the NAT statements are missing from the 1841 could confirm that the traffic from the 10.18 network to the agency network is being exempted from NAT?

--

Please remember to select a correct answer and rate helpful posts

[jpl861]

What about nat (agency) 0 access-list xxxx? This is a normal issue with return traffic sometimes as the return traffic is being dropped or translated into a different IP.

[Marius Gunnerud]

The poster has indicated that he has added a nat 0 to the agency interface but the issue persists.

[andyc0313]

From the packet-tracer output, it seems that the return traffic coming from the VPN going to the agency network is being nat'ed to the global address that is only supposed to be for the outside interface instead of the global address intended for the agency network. That would explain why it can't communicate, but how do I fix this and get it to NAT to the global (agency) pool instead of the global (outside) pool?

Here's the output:

asa1# packet-t input agency tcp 1xx.5xx.3xx.1xx 12345 10.18.1.1 80 det

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group acl_agency in interface agency
access-list acl_agency extended permit ip host 1xx.5xx.3xx.1xx 10.0.0.0 255.0.0.
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xcb954718, priority=12, domain=permit, deny=false
        hits=2, user_data=0xcbf4fc78, cs_id=0x0, flags=0x0, protocol=0
        src ip=1xx.5xx.3xx.1xx, mask=255.255.255.255, port=0
        dst ip=10.0.0.0, mask=255.0.0.0, port=0

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xc88014f8, priority=0, domain=permit-ip-option, deny=true
        hits=496646, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
 match default-inspection-traffic
policy-map global_policy
 class inspection_default
  inspect http
service-policy global_policy global
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xcb8c98b0, priority=70, domain=inspect-http, deny=false
        hits=21, user_data=0xcb8c8fb0, cs_id=0x0, use_real_addr, flags=0x0,
ocol=6
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=80

Phase: 6
Type: NAT-EXEMPT
Subtype:
Result: ALLOW
Config:
nat (agency) 0 access-list NONAT
  match ip agency any outside 10.0.0.0 255.0.0.0
    NAT exempt
    translate_hits = 1, untranslate_hits = 1
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xcbd9e088, priority=6, domain=nat-exempt, deny=false
        hits=0, user_data=0xcc144078, cs_id=0x0, use_real_addr, flags=0x0, p
col=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=10.0.0.0, mask=255.0.0.0, port=0

Phase: 7
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xc7695f80, priority=70, domain=encrypt, deny=false
        hits=5734, user_data=0x1338149c, cs_id=0xd4f14878, reverse, flags=0x
rotocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=10.18.0.0, mask=255.255.0.0, port=0

Phase: 8
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in  id=0xd06f2c40, priority=69, domain=ipsec-tunnel-flow, deny=false
        hits=6035, user_data=0x13384f54, cs_id=0x0, reverse, flags=0x0, prot
=0
        src ip=10.18.0.0, mask=255.255.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Phase: 9
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (outside) 20 access-list vpn_outside_nat
  match ip outside 10.0.0.0 255.0.0.0 outside any
    dynamic translation to pool 20 (2xx.1xx.2xx.190)
    translate_hits = 204581, untranslate_hits = 26424
Additional Information:
 Reverse Flow based lookup yields rule:
 in  id=0xd4f0e198, priority=2, domain=host, deny=false
        hits=693456, user_data=0xcd09b6d8, cs_id=0x0, reverse, flags=0x0, pr
ol=0
        src ip=10.0.0.0, mask=255.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in  id=0xc87f2bc0, priority=0, domain=permit-ip-option, deny=true
        hits=872576652, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protoc
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 1048522497, packet dispatched to next module
Module information for forward flow ...
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_inspect_http
snp_fp_translate
snp_fp_adjacency
snp_fp_encrypt
snp_fp_fragment
snp_fp_tracer_drop
snp_ifc_stat

Module information for reverse flow ...
snp_fp_inspect_ip_options
snp_fp_ipsec_tunnel_flow
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_inspect_http
snp_fp_adjacency
snp_fp_fragment
snp_fp_tracer_drop
snp_ifc_stat

Result:
input-interface: agency
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

[Marius Gunnerud]

Even though it shows a match on the NAT to the outside global, it is the NAT0 which takes precedence:

Type: NAT-EXEMPT
Subtype:
Result: ALLOW
Config:
nat (agency) 0 access-list NONAT
  match ip agency any outside 10.0.0.0 255.0.0.0

But to see if this is the issue, you could add a more specific ACL that matches the exact source and destination subnets.

--

Please remember to select a correct answer and rate helpful posts

[andyc0313]

Well I'm talking about Phase 9, where it appears the return traffic from the VPN gets nat'ed to the outside interface pool.  That would explain why it doesn't communicate.  I need to NAT from the outside interface to the agency interface pool, and it doesn't seem that's currently happening, for some reason.

[Marius Gunnerud]

You don't want to NAT anything when doing VPN...unless you have an address overlap.  Which is why the NAT exempt is there. NAT exempt will match first even though phase 9 states that there is a match it will not be executed.  It is just part of the checks.

I suggest doing a packet capture between the agency interface and the outside interface and capture specifically the traffic from the addresses you are testing two and from.  The result should be that you requests and replies on the agency interface and nothing on the outside interface...this will confirm that traffic is being encrypted on the ASA side...if you see requests and/or replies on the outside interface then traffic is not being encrypted.

I suggest using the ASDM as it is easier.

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/110117-asa-capture-asdm-config.html

--

Please rememeber to select a correct answer and rate helpful posts

[andyc0313]

The output below is what happens when traffic from the inside goes out to the agency network.  You can see that it is being nat'ed to the agency pool.  I want the same thing to happen with the VPN traffic, don't I?  In theory, there's nothing different about the VPN traffic once it's decrypted, other than the fact that it's coming from the outside interface.

Phase: 6
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside) 20 0.0.0.0 0.0.0.0
  match ip inside any agency any
    dynamic translation to pool 20 (1xx.5xx.1xx.1xx)
    translate_hits = 1756, untranslate_hits = 114
Additional Information:
Dynamic translate 10.6.1.1/0 to 1xx.5xx.1xx.1xx/0 using netmask 255.255.255.255
 Forward Flow based lookup yields rule:
 in  id=0xcfe7d268, priority=1, domain=nat, deny=false
        hits=1769, user_data=0xcbf4fcb8, cs_id=0x0, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Phase: 7
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 20 0.0.0.0 0.0.0.0
  match ip inside any outside any
    dynamic translation to pool 20 (2xx.1xx.2xx.190)
    translate_hits = 10728121, untranslate_hits = 221934
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xc8979d80, priority=1, domain=host, deny=false
        hits=8891939, user_data=0xcc03bf80, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0

[Marius Gunnerud]

is the agency interface connected to a network consisting of public IPs (ie. Internet)?

you could try to add a nat statement as the following.

no nat (outside) 20 access-list vpn_outside_nat

nat (outside) 20 10.0.0.0 255.0.0.0

could be that the traffic is not matching the ACL.

--

Please remember to select a correct answer and rate helpful posts

[andyc0313]

Yes, the network consists of public IPs.  I've tried that but I still get the "no NAT policy found" error.  It seems like it's just not applying it at all, even after a "clear xlate".  Could this be a bug?  

[Marius Gunnerud]

I am not sure if this is a bug or a configuration issue...I will try to lab this scenario and get back to you...I don't have a 8.2 to do this on but I will see what result I get on my 8.4 ASA.

--

Please remember to select a correct answer and rate helpful posts
 

[Marius Gunnerud]

Have a look at the following highlighted NAT rules.

global (outside) 20 2xx.1xx.2xx.190
global (outside) 10 2xx.1xx.2xx.185 netmask 255.255.255.0
global (outside) 30 2xx.1xx.2xx.184 netmask 255.255.255.255
global (agency) 20 1xx.5xx.1xx.10-1xx.5xx.1xx.122
global (agency) 20 1xx.5xx.1xx.125
nat (outside) 20 access-list vpn_outside_nat
nat (inside) 0 access-list NONAT
nat (inside) 30 access-list inside_nat_outbound
nat (inside) 20 0.0.0.0 0.0.0.0

I am wondering if perhaps the reason you are having issues is that you have both global outside and agency with the same defining number.  I suggest revising you NAT statements and giving the global agency entries a different number.

--

Please remember to select a correct answer and rate helpful posts

[andyc0313]

I've tried changing the pool numbers to be different in a nat statement and a global statement, and I still get the error "no NAT policy found."  I still have no communication that way.

[Marius Gunnerud]

It is quite possible that this is a bug...or perhaps a restart of the ASA will sort things out.

It is also possible that this is not supported on the ASA...though I find that hard to believe.  I have never tried to do what you are trying, but hairpinning works fine, so do not know why it should not work going to another interface.

If you do try a restart and the problem still persists, I suggest opening a TAC case to find out why this is happening.

--

Please remember to select a correct answer and rate helpful posts

[andyc0313]

I just rebooted the ASA to no avail.  Still don't have a NAT policy for outside to care.  It seems to be a bug... unless we're missing something in the configuration?