Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Common issues with ASA 8.6 version

 

Introduction

This document describes the issue faced by an user on ASA 8.6.

Problem

User is using ASA 5525 with 8.6 version, and he is trying to ping through different interfaces, However he is not able to do that. The test results are mentioned below:

  •      Can PING between the outside interface and the next hop (same subnet)
  •      Cannot PING between the inside interface and the next hop (same subnet)
  •      Cannot PING between the DMZ interface and the next hop (same subnet)

Please see below configuration for firewall for reference.

 

interface GigabitEthernet0/0

speed 100

duplex full

nameif outside

security-level 0

ip address 16.x.x.x 255.255.255.248


interface GigabitEthernet0/1

no nameif

security-level 0

no ip address

!


interface GigabitEthernet0/1.16

vlan 16

nameif inside

security-level 100

ip address 17.x.x.x 255.255.255.0



interface GigabitEthernet0/3

no nameif

security-level 0

no ip address


!


interface GigabitEthernet0/3.69

vlan 69

nameif dmz

security-level 50

ip address 18.x.x.x 255.255.255.0


access-list o_inside extended permit icmp any any

access-list o_inside extended permit icmp any any echo


access-list o_inside extended permit icmp 17.x.x.x (Inside interface) 255.255.0.0 18.x.x.x (DMZ interface) 255.255.255.0   

access-list o_inside extended permit icmp 17.x.x.x (Inside interface) 255.255.0.0 18.x.x.x (DMZ interface) 255.255.255.0


access-list o_dmz extended permit icmp any any

access-list outside extended permit icmp any any

access-list outside extended permit icmp any any echo-reply


icmp permit any outside

icmp permit any dmz


policy-map global_policy

class inspection_default


inspect icmp

inspect icmp error


route inside 17.x.0.0 (Whole inside interface subnet) 255.255.0.0 17.x.x.x (Internal Network) 1

route dmz 17.x.x.0 (Internal) 255.255.255.0 18.x.x.x (DMZ Nework) 1

route outside 18.x.x.0 (DMZ) 255.255.255.0 16.x.x.x (Outside Network) 1

 

User wants to know what should be added to achive the above mentioned result.

 

Solution

ASA should by default without any configurations accept ICMP on its interface.

Check the output of "show arp" and see if you can see the IP address (and the MAC address) of the host/router you are trying to ping.

The 4 "static" configurations above are pretty basic but 2 of them are Static Identity NAT configurations that you probably wont need in the new software

The below 2 configurations probably wont need any corresponding configuration in the new ASA/software since the traffic should go through wihtout NAT configurations.

 

static (dmz,inside) 192.168.1.85 192.168.1.85 netmask 255.255.255.255

static (inside,dmz) 172.16.0.0 172.16.0.0 netmask 255.255.0.0

 

The below Static NAT configurations you can easily convert using Auto NAT / Network Object NAT. Use "object" names that describe the setup better, use generic "object" names.

static (dmz,outside) 200.190.70.87 192.168.1.56 netmask 255.255.255.255

static (dmz,outside) 200.190.70.85 192.168.1.85 netmask 255.255.255.255

 

object network STATIC-1

host 192.168.1.56

nat (dmz,outside) static 200.190.70.87


object network STATIC-2

host 192.168.1.85

nat (dmz,outside) static 200.190.70.85

 

The best way to find possible problems with the ASA configurations is to use the "packet-tracer" command. This would tell you if some traffic is getting blocked by ACL or if the traffic is failing because of NAT

For a connection coming from behind "outside" you can use this format of the command

packet-tracer input outside tcp <source ip> 12345 <server nat ip> <destination port>

To test anything else you naturally just switch the "input <interface name>" to the one where the traffic is sourced from. You will naturally also have to check whether you need to use "tcp" or "udp" and also select a source/destination IP/port.

Taking the output of the following commands should help you to troubleshoot possible problems

You could take "packet-tracer" command output of both of the above mentioned cases. For example testing connectivity from "outside" to the "dmz" server. And the previous problem with testing connection from "inside" to "dmz" server.

If you are doing Dynamic PAT from "inside" to "dmz" then you should remove the above "static" commands that refer to "(inside,dmz)" then user wouldnt be able to connect from "dmz" to those "inside" IP addresses (of those static commands). This is the main reason why Dynamic PAT is not encouraged between local interfaces. It causes complexity for the NAT configurations when user have to add extra NAT configurations to override the possible problems caused by the Dynamic PAT

For the "management" interface you probably need any new NAT configuration.

The Dynamic PAT from "inside" to "dmz" means that you would need some Static Identity NAT configuration mentioned above also in the new software otherwise the ASA would drop the connection attempts.

nat (inside,dmz) after-auto source dynamic inside-pat-source dmz-pat-global

 

Source Discussion

Please help ASA 8.6 version

Version history
Revision #:
2 of 2
Last update:
‎08-29-2017 03:25 AM
Updated by:
 
Labels (1)
Contributors