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

ASA - inside to dmz not working

tsrader
Level 1
Level 1

Unable to access DMZ host from inside network

     - can ping inside interace of ASA from inside network

     - can ping dmz interface of ASA from dmz host (test laptop configured with dmz ip address)

     - can ping inside network from ASA

     - can ping dmz network (test laptop) from ASA

Requirements:

     - permit inside hosts access to the dmz network

     - deny dmz network access to inside hosts

No traffic is passing thru from inside to the dmz (to the test laptop)

Confused as to why this configuration isnt working.  Please help.

------------------------------------------------------------------------------


ASA Version 8.0(4) <context>
!
hostname lab
names
!
interface GigabitEthernet0/0.557
description DMZ lab L2
nameif DMZ
security-level 50
ip address 10.30.5.1 255.255.255.224
!
interface GigabitEthernet0/1.565
description INSIDE lab L3
nameif inside
security-level 100
ip address 192.168.195.4 255.255.255.224
!
object-group service server_maxo_ports tcp
port-object eq www
port-object eq 3389
object-group network server_max
network-object 10.30.5.5 255.255.255.255
network-object 10.30.5.6 255.255.255.255
network-object 10.30.5.7 255.255.255.255
access-list inside_in extended permit ip any any
pager lines 24
mtu DMZ 1500
mtu inside 1500
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
nat-control
global (DMZ) 1 interface
nat (inside) 1 192.168.195.0 255.255.255.224
static (DMZ,inside) 192.168.195.5 10.30.5.5 netmask 255.255.255.255
static (DMZ,inside) 192.168.195.6 10.30.5.6 netmask 255.255.255.255
static (DMZ,inside) 192.168.195.7 10.30.5.7 netmask 255.255.255.255
access-group inside_in in interface inside
route inside 0.0.0.0 0.0.0.0 192.168.195.1 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
no snmp-server location
no snmp-server contact
sysopt noproxyarp inside

5 Replies 5

Hi,

Which IP are you trying to access on the DMZ?

Either enable ICMP inspection or permit ICMP in a new ACL applied to the DMZ and check if you can PING that host from the inside network.

You have these commands:

global (DMZ) 1 interface
nat (inside) 1 192.168.195.0 255.255.255.224

So, from the inside 192.168.195.0/27 you should be able to ''access'' the DMZ network, but please define ''access'' --> which protocol/traffic

Federico.

I had not enabled icmp inspection.  It is done now but still unable to ping dmz host.

policy-map global_policy
class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect netbios
  inspect rsh
  inspect rtsp
  inspect skinny 
  inspect esmtp
  inspect sqlnet
  inspect sunrpc
  inspect tftp
  inspect sip 
  inspect xdmcp
  inspect icmp

Note that I am pinging from inside network on different vlan that 192.168.195.0 /27.    As the inside network is fully routed (L3 core switches), the 192.168.195.0 network is considered "directly connected".

From my pc, I am trying to ping 192.168.195.5 (which is dmz host 10.30.5.5).

My ACL is as follows:

access-list inside_in extended permit ip any any
access-list inside_in extended permit icmp any any

Again, from inside network I can ping ASA inside interace.

What am I missing?

You're trying to PING 192.168.195.5 from the inside.
The real IP of the DMZ is 10.30.5.5 but it will be ''seen'' as 192.168.195.5 from the inside.

I have two questions:

Why do you have a default route to the inside?
Do you need to access the DMZ server with an inside IP? (can't you access it with its real IP)?

As a test, I would do a Packet Tracer and see if the ASA reports the connection is torn down somewhere.

Federico.

The DMZ server ip address (10.x.x.x) is non-routable on the inside network hence the reason for static to inside ip address.

Packet tracer results show the following:

Phases 1-8 show ALLOW

Phase: 9
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
static (DMZ,inside) 192.168.195.5 10.30.5.5 netmask 255.255.255.255
nat-control
  match ip DMZ host 10.30.5.5 inside any
    static translation to 192.168.195.5
    translate_hits = 0, untranslate_hits = 0
Additional Information:
Forward Flow based lookup yields rule:
out id=0xcae4e608, priority=5, domain=nat-reverse, deny=false
        hits=0, user_data=0xcb0ab4f0, cs_id=0x0, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=10.30.5.5, mask=255.255.255.255, port=0, dscp=0x0

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop 
Drop-reason: (acl-drop) Flow is denied by configured rule

Just as a test to see if it works, could you add an ACL to the DMZ permitting the traffic?

You're getting acl-drop message, so let's see if by permitting the traffic in an DMZ-ACL it works.

access-list DMZ permit ip any any
access-group DMZ in interface DMZ

Federico.

Review Cisco Networking for a $25 gift card