Right. So if his off-prem site is 10.0.0.0/16, and his on-prem site is 10.0.0.0/8, then his on-prem computers in the 10.0.0.0/16 defined subnet(s) (i.e., from 10.0.0.1-10.0.255.254) will go off-prem, since the on-prem site definition is less specific than the off-prem definition.
So, like i said, he needs to fix that, if he doesn't want his on-prem computers to talk to the off-prem DCs. amirite? Kurt On Wed, Feb 8, 2017 at 6:43 AM, Brian Desmond <[email protected]> wrote: > AD will match the most specific subnet so in this case the 10.0.0.0/16 subnet > will match anyone who is 10.0.X.X. IP. > > Thanks, > Brian Desmond > > (w) 312.625.1438 | (c) 312.731.3132 > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Kurt Buff > Sent: Tuesday, February 7, 2017 6:55 PM > To: ntsysadm <[email protected]> > Subject: Re: [NTSysADM] Blocking AD Client Traffic to a Certain Site > > And there's your problem, if you didn't typo your response. > > 10.0.0.0/8 overlaps with (actually includes) 10.0.0.0/16 > > That's why some clients will go to your second site (AWS) at random. > > You probably need to list out your subnets more carefully for your main site. > > Kurt > > On Tue, Feb 7, 2017 at 11:33 AM, Charles F Sullivan > <[email protected]> wrote: >> I’ve only been able to do very limited testing. >> >> >> >> - I had about 8 member servers in a site which were actually all in >> the same subnet as each of and the one DC we had for testing, let’s >> call the subnet 198.168.17.0/24. In that site I included the usual private >> ranges: >> 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8 >> >> - At AWS I had a subnet with one DC and just a couple of member >> servers in the 10.0.0.0/16 subnet, which was defined as the only AWS site. >> >> Note that the AWS subnet is a subset of one that I defined at the main >> site, but this absolutely is supported by MS and others have told me >> that this works for them. Despite all of this I did see one member >> server in the main site use the AWS DC after a reboot even though the >> local DC was clearly present and being used by the other member >> servers. So that means 1 out 8 member servers I had for testing >> crossed sites. This made me wonder how often it might happen in our >> production environment where there are thousands of member computers. >> >> >> >> I do have to say that I recently got to test this again, this time >> having 5 DCs at the main site and 2 at AWS. Again, I had just a >> handful of member servers and a workstation and this time I didn’t see >> any of them using an AWS DC. The AWS admin didn’t see his one member >> server use anything besides an AWS DC. >> >> >> >> From: [email protected] >> [mailto:[email protected]] >> On Behalf Of Michael B. Smith >> Sent: Tuesday, February 7, 2017 1:32 PM >> To: [email protected] >> Subject: RE: [NTSysADM] Blocking AD Client Traffic to a Certain Site >> >> >> >> Doesn’t make sense to me. >> >> >> >> The only reason you should have cross-site connections at this point >> is because you don’t have all of the relevant subnets defined in ADS&S. >> >> >> >> From: [email protected] >> [mailto:[email protected]] >> On Behalf Of Charles F Sullivan >> Sent: Tuesday, February 7, 2017 11:40 AM >> To: [email protected] >> Subject: [NTSysADM] Blocking AD Client Traffic to a Certain Site >> >> >> >> I’d like to get some ideas and opinions regarding this, especially if >> anyone has had a similar need….. >> >> >> >> Our AD topology to this point has been as simple as can be. Since just >> about everything on our extended network is connected at high speeds, >> we have never had to have more than one AD site. We are about to put a >> couple of DCs at AWS, which of course will require a second site to be >> defined. This will still be pretty straightforward. Everything but AWS >> will be on the one existing site and a second site will be added for the one >> subnet at AWS. >> >> >> >> I know that even with the two sites defined, some clients may at times >> use the remote site. This is what I have seen in testing, for whatever >> reason, but I don’t consider it to be a real problem because I assume >> it would not happen often. The problem is that our director wants >> absolutely no cross-site traffic except in the case of a disaster. >> >> >> >> It is being proposed that the firewall between the sites allow only AD >> traffic between the DCs themselves. AD clients would be stopped at the >> firewall. I’m not comfortable with that as a solution because I’m >> concerned that when clients do try to use DCs at the remote site, it >> will cause slowness if not failure. Does this seem like a bad idea for >> that or any other reason? >> >> >> >> I was thinking that maybe I could use weight and priority within SRV >> records so that the DCs at AWS would be weight=0 and priority=65535. >> If I did that, would the clients at AWS honor the site rules over the >> SRV records weight and priority? I’m guess that would be >> unpredictable, thus also not a good solution. >> >> >> >> Thanks in advance for any help. >> >> >> >> >> >> Charlie Sullivan >> >> Sr. Windows Systems Administrator >> >> > >
