So your subnets are in the 10.128.0.0/9 (10.128.0.1-10.255.255.254) range? Then yes, you should be fine.
Kurt On Wed, Feb 8, 2017 at 11:28 AM, Charles F Sullivan <[email protected]> wrote: > 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 >>>> >>>> >>> >>> > >
