Domain Controller (and network) cannot access internet and DCDIAG fails on DC

[james.mcclernon1]

Hi,  It appears I broke my network.  There is a server VLAN and workstations VLAN.  There is one desktop that is on the server VLAN and it can login and do all the DNS record checks using nslookup that "claim" everything is OK.  Nothing on the workstations VLAN can login....they get either "logon server is unavailable" or unknown domain.  

When I attempt to use nslookup on the DC, it does not work...it cannot lookup any other servers.  The DC can ping the desktop machine and all the other servers.  When running DCDIAG it is complaining about not being able to see DNS records that are in the DNS server.....

I did try a packet trace from the DC on port 53 to itself on port 53 (as well as TCP on 53) and it is dropped stating "slowpath security checks failed" and drops the packet.  My question is:  Why is the DCDIAG going to the switch and ASA at all instead of just answering the question on the machine it is on?  Second, how to prevent this packet from being dropped.  TIA Jim

[ngkin2010]

Hi,

I am not very familiar with your question, you may take it as a reference.

I think the TCP-53 DNS request cannot pass the ASA's inspection. Could you check if "tcp-inspection" is enabled for class-map of DNS? Could you try to disable the "tcp-inspection" for DNS to see whether it help in your case?

policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection <---------------------

=============

Update: Sorry, seems it's not too relevant to your problem. Please ignore it...

[Alan Ng'ethe]

I am assuming your DC has an AD-integrated zone and so is also the DNS server. Please respond to the following;

Is there reachability from the workstations to the server vlan via IP?

What are the IP settings (including DNS) for the DC? What are the IP settings for the workstation that 'works'? And those that don't work?

The fact that DCDIAG is trying to get out of your local network may suggest that the DC may have some misconfiguration in its ip settings.

On Event viewer of the DC in question, what related error logs do you see under 'DNS server', 'Application' and 'System'?

Are your services started on the DC; Netlogon, AD domian services, DNS server, and DNS client?

Are you able to launch the DNS server mmc snap-in without any errors, and can you verify the existence of the required forward (and reverse) lookup zones? 

Please provide more information.

[jmcclernon]

Here is a table of the info you requested:

IP        VLAN SUBNET    GW ping DC IP Ping same Vlan     DNS
16           WS    128        01         Y               Y                    227
72           WS    128        01         y                Y                    227
110         FP      0           1.1         Y               Y                    227
230           S     240        225        Y               Y                    227
227           S     240        225        Y               Y                    227

Interesting note about IP 72 is I removed it from domain and then tried to put it back in....

Active Directory Domain Controller for the domain could not be contacted

Following error occurred when DNS was queried for the service location (SRV) resource record used to locate an AD DC for domain

0x000005B4  ERROR-TIMEOUT

SRV record _ldap._tcp.dc._msdcs.domain

All of the services are running.  No logs to speak of.  Was able to launch DNS MMC without error and it contained the forward and reverse records (including the ldap one above).....

[Alan Ng'ethe]

Interesting. Could you also upload an output from your dcdiag? You can save it as a text file.

Are you able to telnet 389 on the DC from the workstations?

[jmcclernon]

Alan,

telnet DC 389 or

telnet x.y.z.227 389 brought up a blank screen (suggesting it connected), but never received a reply or any text in the screen.  However, I could see a connection on the DC (227).  This only worked from workstation 230 which happens to be on the same VLAN.  Neither of the other workstations tested on firepower and workstation LANS were able to telnet 389 to the DC.  Attached is the DCDIAG /dnsbasic

[Alan Ng'ethe]

---

@jmcclernon wrote:

Alan,

telnet DC 389 or

telnet x.y.z.227 389 brought up a blank screen (suggesting it connected), but never received a reply or any text in the screen.  However, I could see a connection on the DC (227).  This only worked from workstation 230 which happens to be on the same VLAN.  Neither of the other workstations tested on firepower and workstation LANS were able to telnet 389 to the DC.  Attached is the DCDIAG /dnsbasic

---

Two things:

1. I would ensure that workstations are able to get to port 389 on the DC from their subnets. It looks like they are unable to query for the domain SRV records for some reason, maybe some device is filtering these connection attempts. You should be able to receive the same blank screen when you telnet.  You may be able to run logs on the device doing the routing/filtering to find out the cause.

2. I see loopback addresses configured on the DNS/DC server. In the past I have experienced numerous problems with this kind of configuration. I would hard code the actual IP address (227)? on the NICs. You also don't mention how many NICs you have on this server. 

3. For good measure you also want the forwarders and root hints configured correctly. I think the DNS server properties page has some kind of test for this, use it and confirm that both tests pass, though this is less important than the above.