This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AD x subnets

Hi all,

I have one domain controller in the HQ 192.168.0.0/24 and REDs 192.168.1.0/24 in the branches offices, so I write this post here and not in the RED section because I found today the log bellow in the firewall live log..

19:22:32 Default DROP NetBIOS Name Service 192.168.1.132:137 → 192.168.1.255:137 len=78 ttl=128 tos=0x00 srcmac=0d:52:00:9c:4e:85 dstmac=00:53:64:03:e2[:D]e

My problem is that the computers behind the REDs cannot works fine with AD in the HQ, not logon, not access shares etc...

I try everything, I only got join the computers to the domain via djoin (off line join) but its very bad, I try WINS, NetBIOS over TCPIP, LMHOSTS etc... 

Anyone have an idea to help ?

thx.


This thread was automatically locked due to age.

  • I just register that I dont know why but always when I request in nslookup the frist lookup is timed-out only in the second lookup I got the resolution... any idea ?


    In my experience, it could be related with slow Internet link, or with wrongly configured Forwarder IP address in DC or UTM DNS settings....stick with Bob's DNS best practice guide.

    In attached screenshot is a real world example, how DNS resolution works in Windows server when using wrong Forwarders (a few years ago when client's local ISP changed their DNS IP addresses without any notice to their clients....[:)]. At the end "Use root hints if no forwarders are available" option resolved the name of www.google.com after 12s delay and one manual push.
  • Hi vilic but what is the best practice that you think, set the UTM as forward in the AD DNS or dont set and let DNS use root hints ?
  • I would first go with internal DC/DNS using root hints, and allowing it to pass through UTM (firewall rule DC -> NTP/DNS -> InternetV4).

    I must admit that I don't configure DCs like in Bob's guide for my clients (point no 6.). I always let all DCs outbound TCP/UDP 53 to InternetV4 or to specified ISP forwarder, bypassing UTM as DNS source for them.

    Coming from the Microsoft world, it would add another layer of complexity to my mind, so by eliminating UTM from DNS story it is much easier for me to troubleshoot DNS related problems. 

    Regarding performance degradation and DNS cache mentioned in some posts, in AD environments all clients are already pointing to the DCs for DNS services,.
  • Hi vilic / BAlfson, I think that all my issues with RED Subnets x AD was solved, I'll sent one machine that never was joined into the domain to one branch and try put the machine to domain from the branch and I let you know.

    thx by now.
  • Vilic, the reasons for Client->DC->UTM->OpenDNS are redundancy and "fastest path" in the clients and the DC.  All UTM->DC DNS requests should be via 'Request Routes' - the DC should not be a forwarder in the UTM DNS Proxy.  Not my rules, just my documentation of others' best practices.

    Cheers - Bob
  • Anyway, I prefer more Client -> DC -> ISP DNS path. 

    I've setup dozens of ISA/TMG server scenarios in the past on that way (they don't have built-in DNS proxy service), so I just continued to use the same concept with the UTM. 
    It is easier for me to troubleshoot DNS problems internally only in one place, and there is also one hop less, so I guess that this is the fastest path...[;)]

    I agree with the request routing part, of course.