Solved

Cisco ASA 5505 DMZ servers access DMZ shares

Posted on 2009-07-02
16
1,720 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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
Ransomware - Can it be prevented?

Worried about ransomware attacks hitting your organization?  The good news is that these attacks are predicable and therefore preventable. Learn more about how you can  stop a ransomware attacks before encryption takes place with WatchGuard Total Security!

 
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
 
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

Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
CCNP Exam question 6 30
DHCP default-router command 1 21
Recovering ASA 5505 vpn config from flash card? 7 52
Single Number Reach 3 87
Have you experienced traffic destined through a Cisco ASA firewall disappears and you do not know if the traffic stops in the firewall or somewhere else? The solution is the capture feature. This feature was released in 6.2(1) and works in all firew…
I recently updated from an old PIX platform to the new ASA platform.  While upgrading, I was tremendously confused about how the VPN and AnyConnect licensing works.  It turns out that the ASA has 3 different VPN licensing schemes. "site-to-site" …
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…

740 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