Solved

Cisco ASA 5505 DMZ servers access DMZ shares

Posted on 2009-07-02
16
1,696 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 3

Author Comment

by:hvdhelm
ID: 24762832
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
ID: 24764160
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 3

Author Comment

by:hvdhelm
ID: 24764393
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
ID: 24764433
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 3

Author Comment

by:hvdhelm
ID: 24770825
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
ID: 24772233
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
ID: 24773530
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 3

Author Comment

by:hvdhelm
ID: 24792804
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
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 
LVL 7

Accepted Solution

by:
Boilermaker85 earned 500 total points
ID: 24795509
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 3

Author Comment

by:hvdhelm
ID: 24804445
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
ID: 24808013
<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 3

Author Comment

by:hvdhelm
ID: 24812790
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
ID: 24813287
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 3

Author Comment

by:hvdhelm
ID: 24813529
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
ID: 24813620
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 3

Author Comment

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

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

We sought a budget ($5,000) firewall solution that would provide all the performance we needed with no single point of failure.  Hosting a SAAS web application in our datacenter, it was critical that we find a way to keep connectivity up and inbound…
This article offers some helpful and general tips for safe browsing and online shopping. It offers simple and manageable procedures that help to ensure the safety of one's personal information and the security of any devices.
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 is a video that shows how the OnPage alerts system integrates into ConnectWise, how a trigger is set, how a page is sent via the trigger, and how the SENT, DELIVERED, READ & REPLIED receipts get entered into the internal tab of the ConnectWise …

914 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

15 Experts available now in Live!

Get 1:1 Help Now