Can't get to (1) particular website (Company Network)

DigitalCancer

Diamond Member
Apr 6, 2004
3,726
0
76
Hey Guys,

Need some help here as I'm not entirely sure what's going on...

I work for a semi-small organization (around 50 people) and we're having some issues accessing www.maps.google.com

For some reason, when we try to visit it, it gives us "Page cannot be displayed". Now, we have (2) physical sites and (3) AD/DNS machines. The site that I am at has (2) AD's and after clearing the DNS cache, we can access maps.google.com again.

The issue is, my other site that has only (1) AD, doesn't work still...even after clearing the DNS cache, restarting DNS, restarting the machine, rebooting the modem...we do have a Meraki appliance out there that I'll be rebooting tonight but I don't suspect that will do any good.

Any thoughts would be greatly appreciated!
 

Cooky

Golden Member
Apr 2, 2002
1,408
0
76
Are you confirming Google Maps is inaccessible due to lack of DNS resolution?
Can clients nslookup the FQDN?
 

DigitalCancer

Diamond Member
Apr 6, 2004
3,726
0
76
Cooky, I haven't really confirmed anything.

Our sites are connected via VPN and we have (2) Meraki appliances (1 at each location), this issue was happening at both sites and after clearing the DNS cache at site 1 maps started working. Doing the same at site 2 has yet to work. I just reset the appliance (I passed out earlier) and it still doesn't work unfortunately.

It's weird b/c there is one machine that does work. We're resolving DNS via the DC's and I have changed the DNS manually to use Googles and it doesn't even work that way. I also have flushed the DNS on these machines.
 

DigitalCancer

Diamond Member
Apr 6, 2004
3,726
0
76
I am no expert at this, but your trouble seems to be either in the Active Directory setup, where the site is being blocked. Or perhaps in the Meraki (cisco) appliance.
I would look at this link for the Meraki and see if it can be of help:

https://docs.meraki.com/display/MX/Content+filtering

Unfortunately, the Meraki device isn't the issue. It would also state "Meraki blocked this site". This is strictly a DNS issue of some sort because as I said, we were able to clear the DNS cache at the main site and it started working again, just for some reason it's not doing it with the 2nd site.
 

seepy83

Platinum Member
Nov 12, 2003
2,132
3
71
Unfortunately, the Meraki device isn't the issue. It would also state "Meraki blocked this site". This is strictly a DNS issue of some sort because as I said, we were able to clear the DNS cache at the main site and it started working again, just for some reason it's not doing it with the 2nd site.

Are both sites forwarding DNS requests to the same upstream DNS server (for example, your ISP's servers, or google's dns servers)? If they're forwarding requests to different servers, the site that is having a problem might be forwarding the request to a server that has a bad entry for maps.google.com
 

DigitalCancer

Diamond Member
Apr 6, 2004
3,726
0
76
Are both sites forwarding DNS requests to the same upstream DNS server (for example, your ISP's servers, or google's dns servers)? If they're forwarding requests to different servers, the site that is having a problem might be forwarding the request to a server that has a bad entry for maps.google.com

I believe this is 'somewhat' the case...b/c as I said, the other site is fine.

So, we have DC04 (10.0.0.28) and DC02 (10.0.0.24) at the main site, then the 2nd site is DC03 (10.0.10.12)...they're using themselves as DNS but DC03 is still referencing DC01 (old DC we had) and so maybe that's playing a role in it?

I did manually set the DNS to 10.0.0.28/24 and even tried google's 8.8.8.8 with no change in behavior.
 

Railgun

Golden Member
Mar 27, 2010
1,289
2
81
So you're saying the page can't be displayed, but are you actually checking whether you can actually resolve it? You changed the DNS settings in the client, but I presume you didn't actually perform a lookup to see whether 1) you're actually pointing to what you configured and 2) whether it's actually resolving.

Could the other site's clients be somehow using a host file someone configured for something that's causing the issue? What about accessing the site from the servers themselves?
 

DigitalCancer

Diamond Member
Apr 6, 2004
3,726
0
76
So you're saying the page can't be displayed, but are you actually checking whether you can actually resolve it? You changed the DNS settings in the client, but I presume you didn't actually perform a lookup to see whether 1) you're actually pointing to what you configured and 2) whether it's actually resolving.

Could the other site's clients be somehow using a host file someone configured for something that's causing the issue? What about accessing the site from the servers themselves?

I'm pretty much a novice when it comes to the extreme networking (I'm still learning) and so I'm not sure what you mean by checking to see if I can resolve it?

When I change the DNS, it was on my test machine...TCP/IP config - DNS, after doing that I checked ipconfig /all to ensure that it was pulling the new DNS address. I then did an ipconfig /flushdns and tried www.maps.google.com, which then gives me the error "Page cannot be displayed". Google, however, works fine but when using the link Maps or Play Store (from Google's main site) both give the Page error. Images, Google, gmail, all are fine.


EDIT: The host file is clean on both the test machine and the servers...nothing special configured there.
 

Railgun

Golden Member
Mar 27, 2010
1,289
2
81
I just meant a simple nslookup from the client. If it can resolve it and you still can't display the page, that points to something else entirely.

Although, I have seen the CLI in Win7 behave differently than an application. EG I've looked up one thing via the CLI and had one response whereas the app, in my case an application we use resolved another. I'm not a windows guru so I can't explain that one.
 

DigitalCancer

Diamond Member
Apr 6, 2004
3,726
0
76
So...here's what I get currently...

C:\Users\administrator>nslookup maps.google.com
Server: dc04.<domainRemoved>.local
Address: 10.0.0.24

Non-authoritative answer:
Name: maps.google.com
Addresses: 2607:f8b0:4002:c06::65
74.125.196.138
74.125.196.100
74.125.196.113
74.125.196.102
74.125.196.139
74.125.196.101
 

Railgun

Golden Member
Mar 27, 2010
1,289
2
81
That's a good start. So if you're able to resolve it, but not actually hit the page, are you running any particular security policies? Any URL/application filtering somewhere between that site and where ever your Internet DMZ is? Beyond that, this is where I resolve to taking a trace somewhere between the client and the DMZ to see what's actually going on. Either that or something like http watch to see what the browser is actually doing.
 

bruceb

Diamond Member
Aug 20, 2004
8,874
111
106
That is good idea. Do a tracert from a computer that can't reach the site. See where it fails. You will then know the IP where it has stopped and you can then determine which device in your network is at fault. Then you just have to locate what is stopping it in that device.
 

wlee

Senior member
Oct 10, 1999
585
0
71
Do you have a true IPv6 INET connection, or only local link ?
I'm wondering if the clients are trying to preferably connect to the v6 site first, and when that fails, it has a cached failure and never tries the v4 addresses.
 

DigitalCancer

Diamond Member
Apr 6, 2004
3,726
0
76
Well guys, I'm actually on-site now and just hooked up directly to the comcast modem (it's got 4 ports on it) and wala! I have maps....hook up to the wifi though, no maps. The wifi is controlled via the Meraki device.

Also to note, this is the same machine/user that I was using earlier (as it's my laptop) at the other location with no issues. Also, I'm outside of the OU from the other users (IT and all ya know). ^_^
 

DigitalCancer

Diamond Member
Apr 6, 2004
3,726
0
76
So...I finally figured it out...my boss (proof in the change-log) enabled a setting for Web Encryption...apparently Google uses an encrypted search and therefore it disabled that. I'm still not certain how the one machine out there was getting past it as it was in the same OU as the others but...whatever, it's fixed now.

Thanks guys!