cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3026
Views
0
Helpful
5
Replies

ASA 5512-X 8.6(1)2 NAT Overload

dannybunkins
Level 1
Level 1

My collegue and I have been banging our heads against the wall trying to figure out why we are unable to get this ASA to NAT Overload correctly. Can anybody out there taka look at our config and see what we are missing? I'm sure it is something stupid, and the config may have gotten a little dirty as we tried to change options and make it work. Any insights would be much appreciated. FYI, we can ssh from the WAN into the device to configure it. It is communicating externally, but it isn't natting. 

ASA Version 8.6(1)2

!

hostname ASA5512-X-Remote

enable password ********** encrypted

passwd ********** encrypted

names

!

interface GigabitEthernet0/0

description ISP

nameif WAN

security-level 0

ip address 10.10.10.250 255.255.255.248

!

interface GigabitEthernet0/1

nameif LAN

security-level 100

ip address 172.16.55.2 255.255.255.0

!

interface GigabitEthernet0/2

no nameif

no security-level

no ip address

!

interface GigabitEthernet0/2.1

vlan 58

nameif VENDOR_58

security-level 0

ip address 192.168.58.1 255.255.255.0

!

interface GigabitEthernet0/2.2

vlan 56

nameif VENDOR_56

security-level 0

ip address 192.168.56.1 255.255.255.0

!

interface GigabitEthernet0/3

shutdown

no nameif

no security-level

no ip address

!

interface GigabitEthernet0/4

shutdown

no nameif

no security-level

no ip address

!

interface GigabitEthernet0/5

shutdown

no nameif

no security-level

no ip address

!

interface Management0/0

shutdown

no nameif

no security-level

no ip address

management-only

!

ftp mode passive

object network LAN-HOSTS_172.16.55.0

subnet 172.16.55.0 255.255.255.0

access-list LAN standard permit any

access-list WAN_access_in extended permit ip any any

access-list LAN_access_in extended permit ip any any

pager lines 24

mtu WAN 1500

mtu LAN 1500

mtu VENDOR_56 1500

mtu VENDOR_58 1500

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

!

object network LAN-HOSTS_172.16.55.0

   nat (LAN,WAN) dynamic interface

access-group WAN_access_in in interface WAN

access-group LAN_access_in in interface LAN

route WAN 0.0.0.0 0.0.0.0 10.10.10.254 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

timeout floating-conn 0:00:00

dynamic-access-policy-record DfltAccessPolicy

user-identity default-domain LOCAL

aaa authentication ssh console LOCAL

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

no snmp-server enable

telnet timeout 5

ssh 0.0.0.0 0.0.0.0 WAN

ssh timeout 60

console timeout 0

management-access WAN

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

username admin password ********** encrypted privilege 15

!

class-map inspection_default

match default-inspection-traffic

!

!

policy-map type inspect dns preset_dns_map

parameters

  message-length maximum client auto

  message-length maximum 512

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect ip-options

  inspect netbios

  inspect rsh

  inspect rtsp

  inspect skinny

  inspect esmtp

  inspect sqlnet

  inspect sunrpc

  inspect tftp

  inspect sip

  inspect xdmcp

!

service-policy global_policy global

prompt hostname context

no call-home reporting anonymous

call-home

profile CiscoTAC-1

  no active

  destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService

  destination address email callhome@cisco.com

  destination transport-method http

  subscribe-to-alert-group diagnostic

  subscribe-to-alert-group environment

  subscribe-to-alert-group inventory periodic monthly 19

  subscribe-to-alert-group configuration periodic monthly 19

  subscribe-to-alert-group telemetry periodic daily

Cryptochecksum:6ec463a9761699ba648aa4a17237e3ea

: end

As stated before, any help or insights would be greately appreciated.

edit: txt file of config attached.

1 Accepted Solution

Accepted Solutions

Ah,

Actually now I noticed the reason why atleast the "packet-tracer" was failing.

You are using the LAN interface IP address as the source. Use some other IP address. Just some IP address that is part of the same subnet.

I dont think the ASA allows the use of its interface IP address as the source IP address for packet-tracer

- Jouni

View solution in original post

5 Replies 5

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Configurations seems fine to me. Though the PAT configurations is only for the network on LAN interface

If you want to configure several interfaces/networks in a single PAT configuration, you can use for example

object-group network DEFAULT-PAT-SOURCE

network-object 172.16.55.0 255.255.255.0

network-object 192.168.56.0 255.255.255.0

network-object 192.168.58.0 255.255.255.0

nat (any,WAN) after-auto source dynamic DEFAULT-PAT-SOURCE interface

If you want to confirm that the PAT rule is applied to the traffic then use the "packet-tracer" command

packet-tracer input LAN tcp 172.16.55.100 1234 1.2.3.4 80

Just as an example command. The output should tell if a NAT/PAT is done for the traffic simulated by the command.

If you happen to be testing with ICMP and it isnt working (and therefore think that NAT/PAT might be the problem) then please add the following configuration

policy-map global_policy

class inspection_default

inspect icmp

It automatically allows ICMP echo reply messages back through the firewall. (Then again you seem to have opened everything in both directions)

- Jouni

It looks like i'm being blocked by an ACL, but I would have expected to have the ACL that was giving me trouble be listed. Is it the implicit deny that is giving me trouble?

I'm sorry for my confusion, I think the change it the NAT's is just throwing me off..I'm so used to 8.2 i'm not sure what to do. Any further insight?

ASA5512# packet-tracer input LAN tcp 172.16.55.2 1234 74.125.224.228 80

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         WAN

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: LAN

input-status: up

input-line-status: up

output-interface: WAN

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Hi,

Usually if the ASA doesnt mention the ACL it means the traffic is failing due to some other missconfiguration.

I tried to look through the configurations and everything else seems fine to me but the following line seems a bit strange in your situation

management-access WAN

Could you try to temporarily remove this

no management-access WAN

and try the "packet-tracer" again or perhaps try an actual connection also.

I think this command is only needed if you try to access the ASAs management on that interface through another interface. But if you are on the LAN you might as well use the LAN interface IP for management connections and when you are on the WAN you can use its interfaces IP address for management connections.

- Jouni

Ah,

Actually now I noticed the reason why atleast the "packet-tracer" was failing.

You are using the LAN interface IP address as the source. Use some other IP address. Just some IP address that is part of the same subnet.

I dont think the ASA allows the use of its interface IP address as the source IP address for packet-tracer

- Jouni

          
************EDIT*********************

oops, I didn't see your reply before I posted mine...let me check that .....

************EDIT**********************

I've added some testing ACL's to allow any tcp traffic from any to any applied to both the WAN and the LAN, and i'm still being met with the implicit ACL block like I have been getting.

maybe i'm goinig overboard, but I want to at least get it functioning and then start backing things out one at a time.

i've added the following:

access-list TESTING extended permit tcp any any

access-list TESTING extended permit udp any any

access-list TESTING extended permit icmp any any

access-group TESTING global

I have been staring at this running config for literally 8 hours so I will admit to having likely flawed logic in some of this stuff.

Review Cisco Networking products for a $25 gift card