Cannot access my network? Please HELP.

lon21

Guys,

I have no idea why this is not working.

I have a ASA which is doing routing.

On one side is my MPLS router which is connected on the 10.0.0.0/24 network and the other is my inside/dmz both with same security levels.

Behind my MPLS line is network 172.31.10.0, connected via 10.0.0.0/24 and this is able to pink 10.0.0.1 (ASA Interface) and (.2 MPLS's Router outside interface)

My inside/DMZ is able to ping the firewall and the outside interface of my MPLS .2 router but it cannot ping the lan address 172.31.10.5 or any hosts.

Below is my config.

ASA Version 8.2(1)
!
hostname Test-Lab
names
!
interface Vlan1
 nameif outside
 security-level 0
 ip address dhcp
!
interface Vlan2
 nameif DMZ
 security-level 100
 ip address 192.168.0.1 255.255.255.0
!
interface Vlan3
 no forward interface Vlan1
 nameif MPLS
 security-level 100
 ip address 10.0.0.1 255.255.255.0
!
interface Ethernet0/0
!
interface Ethernet0/1
 switchport access vlan 2
!
interface Ethernet0/2
 switchport access vlan 2
!
interface Ethernet0/3
 switchport access vlan 2
!
interface Ethernet0/4
 switchport access vlan 2
!
interface Ethernet0/5
 switchport access vlan 2
!
interface Ethernet0/6
 switchport access vlan 2
!
interface Ethernet0/7
 switchport access vlan 3
!
boot system disk0:/asa821-k8.bin
ftp mode passive
dns domain-lookup outside
dns server-group DefaultDNS
 name-server 8.8.8.8
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
access-list allow extended permit ip any any
pager lines 24
mtu outside 1500
mtu DMZ 1500
mtu MPLS 1500
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-621.bin
no asdm history enable
arp timeout 14400
global (outside) 1 interface
global (MPLS) 1 interface
nat (DMZ) 1 192.168.0.0 255.255.255.0
access-group allow in interface DMZ
access-group allow in interface MPLS
route MPLS 172.31.10.0 255.255.255.0 10.0.0.2 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
dynamic-access-policy-record DfltAccessPolicy
aaa authorization exec LOCAL
http server enable
http 192.168.0.0 255.255.255.0 DMZ
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
no crypto isakmp nat-traversal
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 DMZ
ssh timeout 30
console timeout 0
dhcpd dns 8.8.8.8
dhcpd option 3 ip 192.168.0.1
!
dhcpd address 192.168.0.10-192.168.0.20 DMZ
dhcpd enable DMZ
!


threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  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 rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
!
service-policy global_policy global
prompt hostname context

instant000

Without any output from the other device, I'm not positive that the problem is on the ASA.

I'd be thinking you should check routing on the MPLS router, making sure it has a return route to the network that pinged it. It could very well have a connected route, and a default route to the outside, but not a route to the internal network that is contacting it.

Can you perform this test? (to eliminate the ASA)

packet-trace input DMZ icmp 192.168.0.3 8 0 172.31.10.5

I just supposed that 192.168.0.3 is an arbitrary address on your DMZ.

After clearing that your ASA can clear the traffic and get a result of "Allow" you can proceed to check the router for routes (though I honestly would have checked first at the router, but this question is specifically about the ASA, however, just as Richard Deal and Gary Donahue have noted, people are quick to blame the firewall when something goes wrong.

Here is a troubleshooting technote, that might assist you in this particular case:
Troubleshoot Connections through the PIX and ASA - Cisco Systems

However, I'm of the mindset that the problem should be "proven" to be something. The packet tracer could be used to help "prove" that the ASA isn't the problem, allowing you to concentrate on other, simpler issues, such as basic routing, making sure the traffic has a return path, for example.

Hope this helps!