Solved

Cisco ASA 5505 DMZ servers access DMZ shares

Posted on 2009-07-02
16
1,677 Views
Last Modified: 2012-05-07
Hi,

I have a Cisco ASA 5505 Sec Plus with multiple servers in the DMZ. When I connect the ASA to the DMZ switch it's no longer possible to access shares between the hosts in de DMZ.

These are the messages from the realytime logging:

6      Jul 02 2009      14:28:55      106015      172.16.0.180      1317      connector_in      139      Deny TCP (no connection) from 172.16.0.180/1317 to connector_in/139 flags RST  on interface DMZDEX

6      Jul 02 2009      14:28:55      106015      172.16.0.180      1316      connector_in      445      Deny TCP (no connection) from 172.16.0.180/1316 to connector_in/445 flags PSH ACK  on interface DMZDEX

Ideas?
ASA Version 8.2(1) 

!

hostname rtr-fw-01

!

interface Vlan1

 nameif inside

 security-level 100

 ip address 10.10.162.253 255.255.255.0 

!

interface Vlan2

 nameif outside

 security-level 0

 ip address 62.xx.xxx.x8 255.255.255.248 

!

interface Vlan12

 nameif DMZDEX

 security-level 50

 ip address 172.16.0.1 255.255.255.0 

!

interface Vlan22

 nameif DMZWEB

 security-level 50

 ip address 172.17.0.1 255.255.255.0 

!

interface Ethernet0/0

 switchport access vlan 2

!

interface Ethernet0/1

 switchport access vlan 12

!

interface Ethernet0/2

 switchport access vlan 12

!

interface Ethernet0/3

 switchport access vlan 12

!

interface Ethernet0/4

 switchport access vlan 22

!

interface Ethernet0/5

 switchport access vlan 22

!

interface Ethernet0/6

!

interface Ethernet0/7

!

boot system disk0:/asa821-k8.bin

no ftp mode passive

clock timezone CEST 1

clock summer-time CEDT recurring last Sun Mar 2:00 last Sun Oct 3:00

dns domain-lookup inside

dns server-group DefaultDNS

 name-server 10.10.162.100

 domain-name dummy.local

same-security-traffic permit intra-interface

object-group network DEX_LAN

 network-object 10.10.160.0 255.255.248.0

 network-object 10.20.0.0 255.255.0.0

 network-object 10.30.0.0 255.255.0.0

object-group protocol DM_INLINE_PROTOCOL_1

 protocol-object ip

 protocol-object icmp

object-group protocol DM_INLINE_PROTOCOL_2

 protocol-object ip

 protocol-object icmp

object-group protocol DM_INLINE_PROTOCOL_3

 protocol-object ip

 protocol-object icmp

object-group protocol DM_INLINE_PROTOCOL_4

 protocol-object ip

 protocol-object icmp

object-group service DM_INLINE_TCP_1 tcp

 port-object eq 3389

 port-object eq 8080

 port-object eq www

 port-object eq https

object-group service DM_INLINE_TCP_2 tcp

 port-object eq 3389

 port-object eq 8080

 port-object eq www

 port-object eq https

object-group service DM_INLINE_TCP_3 tcp

 port-object eq 3389

 port-object eq 8080

 port-object eq www

 port-object eq https

access-list inside_access_in extended permit object-group DM_INLINE_PROTOCOL_1 any PSI 255.255.255.0 

access-list inside_access_in extended permit object-group DM_INLINE_PROTOCOL_2 any DAD 255.255.255.0 

access-list inside_access_in extended permit object-group DM_INLINE_PROTOCOL_3 any 172.16.0.0 255.255.255.0 

access-list inside_access_in extended permit object-group DM_INLINE_PROTOCOL_4 any 172.17.0.0 255.255.255.0 

access-list outside_access_in extended permit tcp any host dmz1_web_ex object-group DM_INLINE_TCP_1 

access-list outside_access_in extended permit tcp any host dmz1_payment_ex object-group DM_INLINE_TCP_2 

access-list outside_access_in extended permit tcp any host dmz1_content_ex object-group DM_INLINE_TCP_3 

access-list DMZDEX_access_in extended permit ip any any 

access-list global_mpc extended permit ip any any 

pager lines 24

logging enable

logging asdm informational

mtu inside 1500

mtu outside 1500

mtu DMZDEX 1500

mtu DMZWEB 1500

no failover

icmp unreachable rate-limit 1 burst-size 1

asdm image disk0:/asdm-621.bin

no asdm history enable

arp timeout 14400

nat-control

global (outside) 1 interface

global (DMZDEX) 2 interface

global (DMZWEB) 3 interface

nat (inside) 1 0.0.0.0 0.0.0.0

nat (DMZDEX) 1 0.0.0.0 0.0.0.0

static (inside,DMZDEX) 172.16.0.0 10.20.0.0 netmask 255.255.0.0 

static (inside,DMZWEB) 172.17.0.0 10.20.0.0 netmask 255.255.0.0 

static (inside,DMZDEX) 172.16.0.0 10.10.162.0 netmask 255.255.255.0 

static (inside,DMZWEB) 172.17.0.0 10.10.162.0 netmask 255.255.255.0 

static (DMZDEX,outside) dmz1_web_ex dmz1_web_in netmask 255.255.255.255 

static (DMZDEX,outside) dmz1_payment_ex dmz1_payment_in netmask 255.255.255.255 

static (DMZDEX,outside) dmz1_content_ex dmz1_content_in netmask 255.255.255.255 

access-group inside_access_in in interface inside

access-group outside_access_in in interface outside

access-group DMZDEX_access_in in interface DMZDEX

route outside 0.0.0.0 0.0.0.0 62.xx.xxx.x7 1

route inside 10.0.0.0 255.0.0.0 10.10.162.254 1

route DMZWEB DAD 255.255.255.0 172.17.0.3 1

route DMZWEB PSI 255.255.255.0 172.17.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

http server enable
 

http 10.0.0.0 255.0.0.0 inside

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

telnet 10.0.0.0 255.0.0.0 inside

telnet timeout 5

ssh timeout 5

console timeout 0

dhcpd auto_config outside

!
 

threat-detection basic-threat

threat-detection statistics port

threat-detection statistics protocol

threat-detection statistics access-list

threat-detection statistics tcp-intercept rate-interval 30 burst-rate 400 average-rate 200

ntp server 194.109.22.18 source outside

webvpn

!

class-map global-class

 match access-list global_mpc

 match default-inspection-traffic

class-map trp

!

!

policy-map type inspect dns preset_dns_map

 parameters

  message-length maximum 512

policy-map global-policy

 class global-class

  inspect dns 

  inspect ftp 

  inspect http 

  inspect netbios 

  inspect tftp 

!

service-policy global-policy global

prompt hostname context 

Cryptochecksum:56c2515e00c61def2fb4098cc582a6f7

: end

Open in new window

0
Comment
Question by:hvdhelm
  • 8
  • 5
  • 3
16 Comments
 
LVL 1

Author Comment

by:hvdhelm
Comment Utility
I gues one of the source from my problems is in de dns. Forgot this error messages:

2      Jul 02 2009      15:05:10      106007      172.16.0.180      53      DNS            Deny inbound UDP from 172.16.0.180/53 to web_in/63719 due to DNS Response
0
 
LVL 33

Expert Comment

by:MikeKane
Comment Utility
Start with basic tests:
1) can the dmz host ping the ASA DMZ interface?
2) can the asa ping the DMZ host?
3) When you try these, do you get syslog errors?




That last entry is probably due to the dns inspection.  DNS Guard may be catching it....    

Issue the command:
SHOW SERVICE-POLICY INSPECT DNS

What do you get?

Here is the 106007 defined:
Explanation    This is a connection-related message. This message is displayed if a UDP packet containing a DNS query or response is denied.
Recommended Action    If the inside port number is 53, the inside host probably is set up as a caching name server. Add an access-list command statement to permit traffic on UDP port 53 and a translation entry for the inside host. If the outside port number is 53, a DNS server was probably too slow to respond, and the query was answered by another server.





0
 
LVL 1

Author Comment

by:hvdhelm
Comment Utility
1. Yes all the hosts can ping the DMZ interface, not each other
2. Yes the DMZ interface can ping al the DMZ hosts
3. No syslog error

Result of the command: "SHOW SERVICE-POLICY INSPECT DNS"
Global policy: 

  Service-policy: global-policy

    Class-map: global-class

      Inspect: dns preset_dns_map, packet 28, drop 0, reset-drop 0

        message-length maximum 512, drop 0

        dns-guard, count 14

        protocol-enforcement, drop 0

        nat-rewrite, count 0

Open in new window

0
 
LVL 33

Expert Comment

by:MikeKane
Comment Utility
You also mentioned you are plugging into a switch.... is this a managed switch?   Possibility of defined VLANs/ACLs/ etc in the switch code?  


0
 
LVL 1

Author Comment

by:hvdhelm
Comment Utility
I have tried both, managed and unmanaged. In both cases all was working fine, but when I plugged in the ASA the shares are not working any more and the internal DNS request. For a better picure, the servers in the DMZ form a domain. Internal DNS request are blocked by the ASA, external DNS request are working.
Member server <-> DC <-> DNS forword to external DNS server.

We can say it no switch issue. At the moment I am using a lowend 3com switch to rule out the switch. Still the same problems.
0
 
LVL 33

Expert Comment

by:MikeKane
Comment Utility
So for the 'DMZ domain', what IP does it use for DNS?   Is there a separate 'inside domain' and, if so, what kind of trust is setup?    Or, is the DMZ domain only using the inside IP for DNS resolution.    Is the inside IP the only DNS server for this domain.  

On the DMZ domain, lets call it dmzdom.com.   And lets call the inside domain insdom.com.    Is there a single server resolving both domains?  Multiple servers?   What do your forwards look like?  

If you suspect the ASA is blocking anything, I suggest you turn on logging to a syslog server and start grabbing some logs while traffic is being rejected.   IF the ASA is dropping packets for any reason, the log will catch it.    I can help analyze the log files if needed.  
0
 
LVL 7

Expert Comment

by:Boilermaker85
Comment Utility
eliminate name resolution for a test. Put lmhosts entry in one host (for the other host) and hosts file entry too. Then ping (uses hosts file) the other host. Net View \\Other-host-name (which uses the lmhosts file). If these work, then you know your problem is just getting the name resolution setup correctly.

Shares typically use Netbios name resolution. So if you understand netbios, it broadcasts server names on its own subnet. If WINS configured, it will register with WINS and lookup via WINS, but it still may broadcast UDP 137 by default. Broadcasts don't pass through a pix or router. Win2k, XP, 2003,2008 should use DNS, but they should point to a DNS that they can get to, and  responses can get back. if the DNS is inside, make sure there is a static statement and acl allowing dmz to nat of internal DNS server.
0
 
LVL 1

Author Comment

by:hvdhelm
Comment Utility
Both DNS and WINS are configured.

Here is the syslog:
2|Jul 07 2009|12:01:59|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to web_in/56832 due to DNS Response

2|Jul 07 2009|12:01:58|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to connector_in/64164 due to DNS Response

2|Jul 07 2009|12:01:58|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to web_in/56832 due to DNS Response

2|Jul 07 2009|12:01:57|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to connector_in/64164 due to DNS Response

2|Jul 07 2009|12:01:56|106001|172.16.0.180|389|connector_in|1618|Inbound TCP connection denied from 172.16.0.180/389 to connector_in/1618 flags SYN ACK  on interface DMZDEX

2|Jul 07 2009|12:01:56|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to connector_in/58446 due to DNS Response

2|Jul 07 2009|12:01:56|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to connector_in/64164 due to DNS Response

2|Jul 07 2009|12:01:54|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to web_in/57217 due to DNS Response

2|Jul 07 2009|12:01:52|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to connector_in/58446 due to DNS Response

2|Jul 07 2009|12:01:50|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to connector_in/58446 due to DNS Response

2|Jul 07 2009|12:01:50|106001|172.16.0.180|389|connector_in|1618|Inbound TCP connection denied from 172.16.0.180/389 to connector_in/1618 flags SYN ACK  on interface DMZDEX

2|Jul 07 2009|12:01:50|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to web_in/57217 due to DNS Response

2|Jul 07 2009|12:01:49|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to connector_in/58446 due to DNS Response

2|Jul 07 2009|12:01:48|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to connector_in/58446 due to DNS Response

2|Jul 07 2009|12:01:48|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to web_in/57217 due to DNS Response

2|Jul 07 2009|12:01:47|106001|172.16.0.180|389|connector_in|1618|Inbound TCP connection denied from 172.16.0.180/389 to connector_in/1618 flags SYN ACK  on interface DMZDEX

2|Jul 07 2009|12:01:47|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to web_in/57217 due to DNS Response

2|Jul 07 2009|12:01:46|106007|172.16.0.180|53|DNS||Deny inbound UDP from 172.16.0.180/53 to web_in/57217 due to DNS Response

Open in new window

0
Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

 
LVL 7

Accepted Solution

by:
Boilermaker85 earned 500 total points
Comment Utility
Those messages are telling me that the DNS responses have already come back.
Firewall syslog message 106007 will be generated when the firewall detects that a DNS response message has already been received for a DNS query message and the connection entry has been torn down by the DNS guard function. This syslog message indicates that the DNS response message received has been denied. Additional information about this syslog message is available in Cisco Security Appliance System Log Message - 106007.

(from: http://www.cisco.com/web/about/security/intelligence/dns-bcp.html)

SO, I looked at your config and see some things I don't know if it will work. For example, I have never seen where the Pix/ASA will allow you to enter two different static statements for an overlapping NAT range, but I guess I have never tried it.
static (inside,DMZDEX) 172.16.0.0 10.20.0.0 netmask 255.255.0.0
static (inside,DMZDEX) 172.16.0.0 10.10.162.0 netmask 255.255.255.0

This looks like you want all your DMZDEX systems to see the internal 10.20.x.x network as local DMZDEX IPs (172.16.0.0), on a one-to-one mapping of this class B. Then in the second line you want the 10.10.162.0 devices to get 172.16.0.x addresses when talking to the DMZDEX.
 What if there is a device in DMZDEX with address 172.16.0.10, and it needs to respond to the device 10.20.0.10? Clearly if 10.20.0.10 sends a SYN packet to the DMZDEX resource, it gets its source translated to 172.16.0.10 and now the firewall is answering for 172.16.0.10 and the device has the same IP, so at layer 2 the switch will be confused as to where that IP is connected.  I suggest you remove those static statements (all 4 Inside to DMZxxx), and instead let the nat statements handle the translation to the DMZs for traffic from inside. For DNS lookups from either DMZ to the internal DNS server, you can create a host static for it (static (inside,DMZDEX) 172.16.0.100 10.10.160.100 netmask 255.255.255.255)   provided there is no device on that dmz using address .100.  There is no need for whole network Static statements. Statics are necessary only when the lower security interface 50 needs to initiate a session to a higher security interface (100)  device, such as the DNS server. In general the DMZs won't initiate sessions to internal devices. And internal devices will be PATed when they initiate sessions to the DMZs. This might clear up all those messages because the ASA is confused on where the device is.

I also don't see an access-list for DMZWEB_access_in or an access-group statement to allow it to talk to DNS if needed. that may be by design so this may not be needed.

Try the above cleanup of your static statements and see what happens.
0
 
LVL 1

Author Comment

by:hvdhelm
Comment Utility
First I agree with the strange NAT sollution. The reason why I did this is that I have multiple Vlans and subnets on the inside.

INSIDE
vlan5 10.10.162.0/24
vlan10 10.20.1.0/24
vlan20 10.20.2.0/24
vlan30 10.20.3.0/24

DMZDEX
172.16.0.0/24

DMZWEB
172.17.0.0/24

The DMZDEX has to reached from al of the INSIDE subnets. After your comment I gues there is a better sollution to allow access from the inside subnets to the DMZ subnet. The ASA is located on VLAN5 with IP 10.10.162.253.
The switches are tagging the right VLANs.

How do I get this fundamental configuration right. I gues its the orgin of my problems.
0
 
LVL 7

Expert Comment

by:Boilermaker85
Comment Utility
<I suggest you remove those static statements (all 4 Inside to DMZxxx), and instead let the nat statements handle the translation to the DMZs for traffic from inside.>  If you remove those 4 Static statements, all of your internal networks will still be able to initiate sessions to the DMZs, and will be PATed as they go through the firewall, appearing to come from the FW DMZ interface.

THen create static for the DNS server for inbound connection.
static (inside,DMZDEX) 172.16.0.100 10.10.160.100 netmask 255.255.255.255
static (inside,DMZWEB) 172.16.0.100 10.10.160.100 netmask 255.255.255.255    (if needed)

That is all you need.
0
 
LVL 1

Author Comment

by:hvdhelm
Comment Utility
I understood your comment, I have removed the static NAT rules. I don't need the static NAT for the DNS. The DMZ domain is standalone with a DNS forwarder to a external DNS server on the outside interface. This works.

After I have removed the static rules my file sharing problems seems to be solved.

Now appears the next problem, after I have remove the static NAT rules I can't access the DMZ from the inside networks.

I have this syslog message, the PAT is not working:
3|Jul 09 2009|14:16:39|305006|connector_dmzdex|3389|||portmap translation creation failed for tcp src inside:10.10.162.222/54729 dst DMZDEX:connector_dmzdex/3389

3|Jul 09 2009|14:16:38|305006|connector_dmzdex|3389|||portmap translation creation failed for tcp src inside:10.10.162.222/54729 dst DMZDEX:connector_dmzdex/3389

3|Jul 09 2009|14:16:38|305006|connector_dmzdex|3389|||portmap translation creation failed for tcp src inside:10.10.162.222/54729 dst DMZDEX:connector_dmzdex/3389

Open in new window

0
 
LVL 7

Assisted Solution

by:Boilermaker85
Boilermaker85 earned 500 total points
Comment Utility
I see the problem. The Global statements should all use number 1. change this:
global (outside) 1 interface
global (DMZDEX) 2 interface
global (DMZWEB) 3 interface

to this:
global (outside) 1 interface
global (DMZDEX) 1 interface
global (DMZWEB) 1 interface

Your nat statements all refer to number 1 and have to match up with the corresponding global statements on each interface. Small change, and you'll be in business :-)
0
 
LVL 1

Author Comment

by:hvdhelm
Comment Utility
I have tried, but get this error:
rtr-fw-01(config)# global (DMZDEX) 1 interface

global for this range already exists

rtr-fw-01(config)#
 

=====
 

rtr-fw-01#sh run | i global

global (outside) 1 interface

global (DMZDEX) 2 interface

global (DMZWEB) 3 interface

rtr-fw-01#

Open in new window

0
 
LVL 7

Expert Comment

by:Boilermaker85
Comment Utility
You have to remove the globals with 2 and 3 in them. That is what I meant by "Change". The Interface keyword defines the range and you are already using it. So do this:
no global (DMZDEX) 2 interface
global (DMZDEX) 1 interface
or global (DMZDEX) 1 172.16.0.2 netmask 255.255.255.255    
(this second technique assigns a separate IP for PAT which is different than the interface IP. I normally use this technique and there are never any confusion over overlapping ranges.)

then repeat for other DMZ:
no global (DMZWEB) 3 interface
global (DMZWEB) 1 interface
0
 
LVL 1

Author Comment

by:hvdhelm
Comment Utility
Thanks! It's working!
I'm going to run some test now!
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Imagine you have a shopping list of items you need to get at the grocery store. You have two options: A. Take one trip to the grocery store and get everything you need for the week, or B. Take multiple trips, buying an item at a time, to achieve t…
Hi All,  Recently I have installed and configured a Sonicwall NS220 in the network as a firewall and Internet access gateway. All was working fine until users started reporting that they cannot use the Cisco VPN client to connect to the customer'…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.
This video shows how to remove a single email address from the Outlook 2010 Auto Suggestion memory. NOTE: For Outlook 2016 and 2013 perform the exact same steps. Open a new email: Click the New email button in Outlook. Start typing the address: …

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now