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
