Cannot access my network? Please HELP.

lon21lon21 Member Posts: 201

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 network and the other is my inside/dmz both with same security levels.

Behind my MPLS line is network, connected via and this is able to pink (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 or any hosts.

Below is my config.

ASA Version 8.2(1)
hostname Test-Lab
interface Vlan1
 nameif outside
 security-level 0
 ip address dhcp
interface Vlan2
 nameif DMZ
 security-level 100
 ip address
interface Vlan3
 no forward interface Vlan1
 nameif MPLS
 security-level 100
 ip address
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
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
access-group allow in interface DMZ
access-group allow in interface MPLS
route MPLS 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 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 DMZ
ssh timeout 30
console timeout 0
dhcpd dns
dhcpd option 3 ip
dhcpd address DMZ
dhcpd enable DMZ

threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
class-map inspection_default
 match default-inspection-traffic
policy-map type inspect dns preset_dns_map
  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


  • instant000instant000 Member Posts: 1,745
    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 8 0

    I just supposed that 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!
    Currently Working: CCIE R&S
    LinkedIn: (Please connect: Just say you're from TechExams.Net!)
Sign In or Register to comment.