13

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?

  • First of all You must of course inspect problem. So please install IP Tools from Play Store, make some nslookup`s and so on and than we will know more. Especially DNS server Nexus use, DNS lookup and so on. Try this IP Tools. It is in Polish language but of course You can change it. This tool I use in case of such problems. – mackowiakp Jul 24 '16 at 9:26
  • Hm. In IP Info, it displays the correct DNS addresses. In DNS lookup, the correct IP is shown (192.168.1.15). However, Traceroute tab shows the wrong public IP (90.78.26.42). – Arseni Mourzenko Jul 24 '16 at 10:24
  • So - in my opinion - there is something wrong with internal DNS entry for Nexus. I use simmilar configuration and everything works OK – mackowiakp Jul 24 '16 at 15:53
  • Internal DNS works fine on my Nexus 6p, Nexus 5, Nexus 10, etc. Have you tried flashing factory images to the Nexus 7 (if its bootloader unlocked) to make sure it's running known-good software? (I presume you got it used, since the Nexus 7 is not a new device). – derobert Jul 28 '16 at 17:23
  • I bought it second-hand, but I did a reset before using it, followed by the upgrades up to the latest Android version. I imagine this is enough to ensure it is not running any custom software, given that the device is not rooted. – Arseni Mourzenko Jul 28 '16 at 18:40
4

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

  • Indeed, this should be the cause in my case as well, since, similarly, I don't use IPv6 internally. I circumvented the DNS issue by creating a local VPN server and asking the Android device to use VPN instead; it works, but it's obviously too drastic. – Arseni Mourzenko Sep 7 '16 at 17:59
  • @ArseniMourzenko Did you ever resolve this issue? I have literally wasted two days of doing nothing else but trying to fix this problem, as it has literally broken a lot of what was previously working. And yes, I tried a VPN but it reduced transfer rate from 100Mbps+ to about 20 – Michael Dec 27 '16 at 17:27
  • @Michael: since my local DNS servers are configured to only support IPv4, Dimarc67's answer was relevant for me (this is also why this is marked as the accepted answer). From there, I just set up a VPN for all Android devices, and I'm happy to use it since then. I haven't noticed any reduction of transfer rate—not would I care, given how I use mobile devices. For what it's worth, I'm using OpenVPN on Debian server-side, and OpenVPN Connect on Android devices. – Arseni Mourzenko Dec 28 '16 at 0:14
1

I came across this post while trying to get my Android 6.0 device to use the locally configured DNS server to resolve local hostnames. One answer above indicated that Android 5.0 and newer insists on using IPv6 DNS servers. This was the clue that lead me to my solution.

My router was advertising the IPv6 DNS servers provided by my ISP using DHCP-PD. I reconfigured my router to stop advertising the IPv6 DNS servers and now the Android 6.0 device is resolving the local hostname using the IPv4 DNS server provided by DHCP (IPv4).

I also have a DNAT to redirect all DNS queries (TCP/UDP port 53) to my local DNS server. This was in place before disabling the router advertisement with IPv6 DNS servers so I don't know if Android 5.0+ falls back to the Google DNS servers (as claimed in the previous answer) and I caught them with my DNAT rule or whether my Android 6.0 device just used the DHCP assigned IPv4 DNS server. Either way, the local hostname resolution is working now.

  • Disabling IPV6 on my router fixed the issue on ALL of my android devices! – Ken J Dec 30 '17 at 12:10
1

I was finally able to solve this by setting up a DHCP server myself on the same network, which configures the correct Search Domain to send to the clients.

Once I had a dhcp server, in my case isc-dhcpd with the configuration in dhcp.conf:

option domain-name "myrealdomain.tld";

Android was able to resolve local A-records set in my DNS server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.