I have a very strange behavior on an Android device (Nexus 7) when trying to access local network applications. Instead of getting the actual IP of the machine on LAN, the Android device gets the public IP, which means that Chrome, Firefox or any other browser simply shows the web page of the router.
I have an internal DNS server which handles the local networks. Doing ping from a PC works correctly:
$ ping s.pelicandd.com
PING pelicandd.com (192.168.1.15) 56(84) bytes of data.
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=1 ttl=64 time=0.524 ms
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=2 ttl=64 time=0.578 ms
^C
On an HTC One device (accessed with adb shell), it works well too:
shell@m7:/ $ ping s.pelicandd.com
PING pelicandd.com (192.168.1.15) 56(84) bytes of data.
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=1 ttl=64 time=2.56 ms
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=2 ttl=64 time=27.8 ms
^C
However, this is what I get when doing the same ping from Nexus 7:
shell@flo:/ $ ping s.pelicandd.com
PING pelicandd.com (90.78.26.42) 56(84) bytes of data.
64 bytes from LFbn-1-2441-42.w90-78.abo.wanadoo.fr (90.78.26.42): icmp_seq=1 ttl=64 time=2.56 ms
64 bytes from LFbn-1-2441-42.w90-78.abo.wanadoo.fr (90.78.26.42): icmp_seq=2 ttl=64 time=8.63 ms
^C
Instead of resolving to the internal IP, it resolves to the public one.
The network configuration is—except the IP address of the device—exactly the same on both devices: IP settings are set to Static, and DNS servers are the internal ones. Both Android devices are connected through Wi-Fi (unlike the PC). A major difference, however, is that Nexus 7 is using Android 6.0.1, while HTC One uses Android 5.0.2.
There is no nm-tool, dig or nslookup on Nexus 7. The device is not rooted.
The problem existed since I bought the device a few weeks ago, so it could hardly be the issue with DNS cache.
What can I do to further inspect this issue?
Answer
We recently encountered this issue, and we narrowed it to occurring ONLY on devices running Android v5 and newer. Android v4 and all other OS's have no issue.
With that tidbit, we determined that Android v5 and newer insists on using IPv6 for DNS name resolution. (Since we've completely disabled IPv6 on our network, this jibes with the issue.) If Android v5(+) can't get an IPv6 response from local DNS, then it reaches out to Google's public name host (8.8.8.8). Hence, no internal DNS, just external.
We worked around the issue by creating DNS records on our public-facing DNS servers for select internal names and IPs. With that done, Google's public DNS could resolve these internal names with internal IPs, and the devices could then reach our internal hosts.
We're proceeding with fully enabling IPv6 on our internal DNS servers (domain controllers) as a permanent fix.
=========================================
UPDATE-- Well, it turns out this may be a total red herring...or not. My home network is Win2008R2, single-domain with DHCP and DNS and no IPv6 binding. Tested an Android v5 device from there and had NO ISSUE. Office network with issue is Win2012 (non-R2), single-domain.
Bypassed current office WAPs with stand-alone Linksys WAP and separate SSID for testing, issue persists.
Differences between office and home networks (that I can think of): - Windows version - 2012 vs. 2008 R2 - router model (Cisco vs. Linksys) - WAP model (Dell-branded Aruba Networks vs. Linksys)
Proceeding with whatever further testing I can think of for narrowing the issue. Any suggestions or input is extremely appreciated!
=========================================
PROBLEM GONE (?!)
Our issue seemed to disappear on its own following a network topology change that I wouldn't think was related, but here's the info in case.
(HUGE APOLOGIES for this long, drawn out story, but this is when our Android issues disappeared, so ride this out if you can. I'm probably providing WAY too much detail here, but because I can't see a direct connection, I'm laying it all out exactly as it happened.)
Our ISP is Comcast Business Class—a cable modem with a static IP block of five addresses (weird number but that's how Comcast sells them). Comcast's cable modem is essentially a combination modem/firewall/router/switch, with our static IP block remotely programmed into it.
For 10+ years and almost as many employers, I've always built office networks the same way:
Configure a LAN IP for the ISP modem/router, which NAT's traffic from the internet. Couldn't be simpler, and that's how my current office network has been configured for four years.
Recently our office internet service went down. Usually a modem restart corrects it, but when it didn't we called Comcast who sent a tech, who replaced the cable modem to restore service.
A few days later, the same thing happened again. We called again, and the onsite tech (different tech than before) attempted to replace the modem again, this time with a newer model. Surprisingly, the newer cable modem did not support changing the LAN subnet address. The default subnet is 10.1.10.0/24, and it cannot be changed. (Only the 4th octet was configurable.) As our office subnet is 192.168.100.0/24, I let the tech know we couldn't use it without being able to change the LAN subnet. He understood, but had no info as to why the cable modem would prevent the change. So he installed a replacement modem of the same model as before, which we configured identically, and internet access was restored.
Another day or two passes, and the service goes down again. This time when I called Comcast, the initial tech I spoke with asked detailed and knowledgeable questions about our network configuration. When I explained that the cable modem was configured with a LAN IP on our subnet, he seemed puzzled by this. He said that most Comcast customers connect a NAT'ing router between the cable modem and LAN rather than use the cable modem's NAT'ing. In fact, he said he wasn't aware that the cable modem supported NAT'ing.
Comcast sent out another tech with a brand new cable modem (latest model that doesn't support changing the LAN subnet). He did extensive testing on the existing modem, and finally determined that it was only passing IPv6 traffic—no IPv4. He also confirmed what the phone tech had said--that it's recommended to use a separate router for NAT'ing, and to not change the LAN subnet on the cable modem (which we can't do on the newer modems now anyway).
And now we finally come to the network change we made. I installed a simple LinkSys router between the cable modem and our core router, configured with our static IP on the modem side, and a LAN IP on the inside. Internet service was then restored, and has remained stable for some time now.
After internet service was restored, I thought about the oddness of the IPv6 issue with the cable modem, which in turn reminded me of the Android v5 issue. I then tested our Android devices in the office, and was stunned to see that the DNS issue was no longer occurring.
Adding the LinkSys router for NAT'ing is the ONLY NETWORK CHANGE WE MADE. Coincidence?? Possibly, but it just seemed a little peculiar that both were related to IPv6.
Anyway, sorry again for the long story, but our Android issue is gone. Make what you can out of it.
Dimarc67
No comments:
Post a Comment