| ALL DNS Entries resolve to 127.0.0.1Hi All,
I've been struggling with a very strange issue here lately. I support a few hundred PC's which are configured with folder redirection for my docs, favorites and desktop items. I then use offline files to allow laptop uses to sync these directories so that they have access to them while they are at home.
This has worked perfectly fine since its introduction nearly 2 years ago. As of Tuesday of this week, I've had almost every one of my users get prompted for a password after logging in, but ONLY when they are outside of my office. This dialogue box is prompting them for a password to my file server, lets call it fileserver1.contoso.com. No combination of their current username/password provides successful authentication as it complains that no DC is currently available.
In doing a bit of troubleshooting on their machine, here is what i've found:
1.) NO changes have been made recently to any of our configs/network.
2.) No entries in the hosts file accept for 127.0.0.1 for localhost
3.) I'm able to ping anything and it resolves to 127.0.0.1 as long as I don't specify a domain (ex. .com). Example: ping fhfhdfyduaifydufayduia resolves to 127.0.0.1.
4.) All Virus defs are up to date (mcAfee 8.5i Patch 8), also uninstalled mcafee to see if that was causing the issue.
5.) I tried adding the IP to my file server to the hosts file in order to see if that could resolve my issue (hoping that it would find the server is offline and then stay offline) and it was still able to resolve! tracert showed the following:
Tracing route to 10.2.11.2 over a maximum of 30 hops
1 1 ms 2 ms 1 ms WRT54GSv5 [192.168.1.1]
2 * * * Request timed out.
3 8 ms 10 ms 18 ms 68.85.131.157
4 9 ms 8 ms 8 ms po-10-ur08.mtprospect.il.chicago.comcast.net [68.87.231.70]
5 11 ms 10 ms 11 ms be-50-ar01.area4.il.chicago.comcast.net [68.87.230.53]
6 14 ms 12 ms 11 ms te-4-1-cr01.chicago.il.cbone.comcast.net [68.86.72.33]
7 27 ms 27 ms 28 ms te-9-1-cr01.omaha.ne.cbone.comcast.net [68.86.68.30]
8 79 ms 39 ms 37 ms te-9-1-cr01.denver.co.cbone.comcast.net [68.86.68.42]
9 203 ms 49 ms 48 ms te-9-1-cr01.ogden.ut.cbone.comcast.net [68.86.68.46]
10 140 ms 65 ms 65 ms te-9-1-cr01.seattle.wa.cbone.comcast.net [68.86.68.50]
11 211 ms 66 ms 66 ms te-0-8-0-0-ar01.seattle.wa.seattle.comcast.net [68.86.72.66]
12 119 ms 66 ms 66 ms te-8-1-ur02.everett.wa.seattle.comcast.net [68.86.96.198]
13 150 ms 84 ms 85 ms te-9-3-ur01.everett.wa.seattle.comcast.net [68.86.96.77]
14 187 ms 84 ms 87 ms 69.241.105.214
15 85 ms 86 ms 87 ms 69.241.105.242
16 88 ms 85 ms 86 ms 10.177.253.1
17 87 ms 85 ms 87 ms 10.2.47.201
18 89 ms 89 ms 89 ms 10.2.63.8
19 91 ms 89 ms 88 ms 10.2.11.2
Trace complete.
It's worth noting that there is no VPN or any kind of connection back to our office when working remotely. I'm at a complete and total loss on this one, any ideas are appreciated. Thanks! |
|
| When they are on the road, does ipconfig /all in a command window show a DNS Suffix
And in a command window does nslookup gobblygook resolve to 127.0.0.1? Maybe their ISP sets their own domain as default DNS suffix and uses a wildcard entry to resolve any unknown name in that default domain to self.
Or are there any manual settings for DNS Suffix in the Advanced tab of TCP/IP properties for whatever interface they are using for their on the road internet connection or in general? |
|
Bink
join:2006-05-14
Denver, CO
kudos:4
1 edit | reply to waynebike
From your tracert it would appear they might be using a Comcast DNS server—and Comcast is improperly routing traffic to private address space out their network. It also appears Comcast’s DNS servers, for whatever reason, are using a loopback address in response to some types of DNS requests. It might also be the case where Comcast is using private address space that is similar to what you use on their internal network. |
|
 MattAll noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | reply to waynebike
What is 10.2.11.2? Is that the IP of your server at work? If so, most cable companies use the 10.x.x.x network for devices, so what it looks like it happening is that you are running a trace route to a piece of Comcast equipment, not to your server.
What has me MORE puzzled, is why in the hell is your WRT router passing a 10.x.x.x address out the WAN port. Your Linksys should drop those packets as private address space shouldn't be routed onto the public internet. |
|
 tschmidtPremium,MVM
join:2000-11-12
Milford, NH
kudos:5
 ·Fairpoint Commun..
 ·Hollis Hosting
| said by Matt:Your Linksys should drop those packets as private address space shouldn't be routed onto the public internet. The only addresses router will not forward is the local address segment used by the LAN. It has no way of knowing what addresses are being used external to itself.
There is a lot of confusion about RFC 1918 private addresses. They are private in so far as they are not used on the public Internet. However that does not mean they are forbidden from being used by ISPs or corporate networks. As you pointed out it is common for ISPs to use the 10/8 block for edge routers. The "public" Internet does not begin until the ISP hands the traffic off at peering point.
/tom |
|
MattAll noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | said by tschmidt:said by Matt:Your Linksys should drop those packets as private address space shouldn't be routed onto the public internet. The only addresses router will not forward is the local address segment used by the LAN. It has no way of knowing what addresses are being used external to itself. Dood, Tom, you're right. I just tested performing a trace route to 10.0.0.1 and sure enough, my router tried to send it out onto North State's (my ISP's) network. I was under the assumption that a home router would be intelligent enough to know about the private address space and not pass it LAN to WAN. |
|
| reply to waynebike
Some ISP's do use private IP's as gateways, since outbound and inbound routes can differ (out/in routes differ on my DSL even though all IP's involved are public). And some foreign ISP do not even give their users public IP's (they NAT their customers). So if someone assumed that traffic to "any" private IP should not go out the WAN, they might break something. |
|
| reply to waynebike
Thanks to all who have replied. I'm actually working with Microsoft on this now. I've managed to stump two seperate teams thus far (AD & Networking). Both have had access to the systems and are completely unsure so for as to how this could be happening. If/when we get this resolved, I'll post the solution here. For now, I'll let them have a stab at it. |
|
MattAll noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | said by waynebike:Thanks to all who have replied. I'm actually working with Microsoft on this now. I've managed to stump two seperate teams thus far (AD & Networking). Both have had access to the systems and are completely unsure so for as to how this could be happening. If/when we get this resolved, I'll post the solution here. For now, I'll let them have a stab at it. Many moons ago I interviewed with the Microsoft Networking Team. If you're working at the level I would have been, those are some smart guys. You're in good hands. |
|
