Beyond the DNS issue, I would like to understand the VPN situation a little better.
This VPN sounds like a site to site configuration, no? Why wouldn't you be able to use NAT successfully -- in this case, one-to-one NAT terminated at the firewall? *ASB **http://XeeMe.com/AndrewBaker* <http://xeeme.com/AndrewBaker> *Providing Virtual CIO Services (IT Operations & Information Security) for the SMB market...* On Thu, Apr 24, 2014 at 9:07 AM, Melvin Backus <[email protected]>wrote: > No other DHCP servers that I'm aware of but certainly worth a look. > That said, the process I'm using to detect the change reports the DHCP > server (I'm just doing psexec and ipconfig) and they are all pointing to > the correct one. The only difference we've found is that the DNS servers > are wrong. We've even connected to those machines and manually checked > settings to confirm they are still set for DHCP, etc., when it happens. > > > > The machines don't have to have publicly available IPs, only routable > IPs. As in no NAT, and no private IP ranges. So, we've got IP blocks that > we assign to all those machines. They never see the outside world, but > they are routable to the outside should that need every arise. Think > large, formerly monopolistic telco. J > > > > Essentially the same as above. In order to be allowed to see their DNS > servers, they have to be on non-private subnets. Since we already have > everything setup on private subnets for server and infrastructure, rather > than move that, we added a couple of DNS servers on one of the non-private > subnets. They just have a list of conditional forwarders and either > forward DNS request to the partner, our domain DNS, or the Internet. I'm > not sure that's the best way to handle the whole thing but it provided a > mechanism for us to allow the systems which require access to the partner > network to resolve it (we used to actually have to maintain hosts files > because they didn't use DNS) without a total rework of our DNS > infrastructure. Things would probably be different if we were starting > from scratch, but that's almost never the case. J > > > > > > -- > There are 10 kinds of people in the world... > those who understand binary and those who don't. > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Andrew S. Baker > *Sent:* Thursday, April 24, 2014 8:52 AM > *To:* ntsysadm > *Subject:* Re: [NTSysADM] DNS server settings getting changed > > > > How sure are you that there isn't another DHCP server in the mix? Have > you ever looked at the what DHCP server a machine with bad DNS settings has? > > Also, I must say that I've never seen a requirement for a partner VPN > (private network) that required individual client machines to have PUBLIC > addresses. > > > *>>As part of the VPN requirement we have set up a second set of DNS > servers which are used to resolve hosts in the partner's domains. * > > Why would you need separate DNS servers to handle this? > > > > > > > > > > *ASB **http://XeeMe.com/AndrewBaker* <http://xeeme.com/AndrewBaker> > *Providing Virtual CIO Services (IT Operations & Information Security) for > the SMB market...* > > > > > > On Thu, Apr 24, 2014 at 8:26 AM, Melvin Backus <[email protected]> > wrote: > > OK, this has been driving us nuts for a couple of days now. > > > > One of our remote sites is seeing seemingly random PCs change their DNS > server settings. They're all configured to get them from the DHCP server, > and it has the correct DNS servers. All the PCs do in fact get the correct > settings when they get or renew an IP. That all seems to be working as we > expect. But periodically we'll see a machine change the DNS servers to > something else. This causes applications to start failing because the > hosts they need no longer resolve. As soon as the PC renews it's IP, > whether automatically or manually, everything goes back to normal and stuff > works again. > > > > We have a short term fix (force the DNS server settings manually instead > of DHCP) but that doesn't explain what's going on, and since we're using > this same setup in 20 offices it also begs the question of why just this > office. > > > > Background: > > Multiple small offices with either /28 or /27 networks. They are publicly > routable IPs due to requirements for a partner VPN. The DHCP server is on > the Juniper SSG FW. It servers two pools, one for PCs, another for > phones. The PC subnet is publicly routable, the phone subnet is a > non-routable 10.x subnet with matching ranges. (12.x.x.x/27 and > 10.x.x.x/27). All DNS points to the home office. Until recently these > pointed strictly to our domain DNS servers. As part of the VPN requirement > we have set up a second set of DNS servers which are used to resolve hosts > in the partner's domains. This is done with conditional forwarders. > Partner DNS traffic gets resolved by their servers, everything else goes to > our domain DNS or the Internet as required. > > > > This all works fine except in a single office. Even in that office it > worked fine for weeks and has suddenly started this "revert" behavior. > When the PCs change, they go back to pointing to our domain DNS which can't > resolve the partner hosts. > > > > My question becomes (sorry it took so long) how do we track what is > actually changing the DNS settings? I can tell when it happens fairly > easily, but nothing in the event logs, etc., seems to indicate what > triggered it, or what process is doing it. It doesn't happen as part of a > DHCP operation as best we can tell. > > > > > > -------------------- > Melvin Backus | Sr. Systems Analyst | Byers Engineering Company | > 404.497.1565 > > Service Desk | 404-497-1599 | http://servicedesk.byers.com > > -- > There are 10 kinds of people in the world... > those who understand binary and those who don't. > > > > >
