Yes, so I'm set with that. For the on-prem site, there are no computers in the 10.0.0.0/16 subnet. Another way to put it is that the subnet doesn't even actually exist in the on-prem network. We have about twenty 10.x.x.x subnets on-prem and none have a subnet mask of less than /16.
Thanks. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kurt Buff Sent: Wednesday, February 8, 2017 1:25 PM To: ntsysadm <[email protected]> Subject: Re: [NTSysADM] Blocking AD Client Traffic to a Certain Site Sorry - just to be absolutely clear, my response is meant only to apply computers with addresses in that 10.0.0.0/16 subnet. Machines in other subnets would talk according to the other definitions in ADS&S. Kurt On Wed, Feb 8, 2017 at 10:17 AM, Kurt Buff <[email protected]> wrote: > 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 >>> >>> >> >>
