Push dhcp-options for Android.

[Mimiko]

As I am playing with the device, I came to this problem when using "redirect-gateway". Whanting the internet from Android to go thru the tunnel, and mostly, the Android has to use our internal DNS to resolve internally used domains, that are not publically registered. It's a frustration that "dhcp-option DNS" and "dhpc-option WINS" are valid only for windows clients, but for unix clients is needed to create a script. Now I came across to issues. First, what commands are used to set the DNS in Android system, as resolv.conf is not used. The second, is much problematic. Normally Android gets the DNS from the internet provider (3G). As this DNS does not know about our privat domains, the users will not be able to access our internal services thru VPN using provider's DNS servers. Another thing is that provider's DNS is accesible only from Android IP, not thru the tunnel and internet. I can set the google's DNS, but it does not about our privat domain too. I can't even set statically our internal DNS, as when VPN is not accesible, users will not be able to access internet. So, the only resolvation is to use scripts do dinamically set Android DNS to our internal DNS when VPN connection is established, and unset this DNS leaving them to provider's DNS.
Now, suppose I create such script (don't know how for now), for setting DNS on connection, and unsetting on disconnect. The recomended on internet setting is writing to resolv.conf (or other Androids file). Suppose after a succeseful connection, the DNS is set in the file, but the user extracts the battery. So the disconnect script is not invoked. Then the battery is placed back and phone turned on, without connecting to VPN. In such case, user will not have an accesible resolver.
For such a issue it will be a good to set the DNS IP not in Androids configuration file, but some how only in running environment. So on restart the DNS will be the original, like in Windows.

I can set a static DNS in resolv.conf (or other file) to be used, where it is specified in order: our internal DNS, google DNS. Provider's DNS will not be used, as it might change it's IP. If VPN is established, our DNS will be accesible. If VPN is not established, Android will try our DNS, then will try google's DNS. But if the VPN is established, when system is using google's DNS, using of our DNS will not be returned, even it's accesible. Well if I redirect the traffic thru tunnel, I can block access to google's DNS from Android thru tunnel, and the system will return to our DNS. A bad workaround.

To summarize, what is the command to set DNS IP on Android (and Linux) to be only temporar (as in dhcp mode)? And will be implemented "dhcp-option" in future versions?

[janjust]

To summarize, what is the command to set DNS IP on Android (and Linux) to be only temporar (as in dhcp mode)? And will be implemented "dhcp-option" in future versions?

On Linux, there is no such command: the resolver library looks at /etc/resolv.conf , period. If you want to alter this behaviour, alter the resolver library (which is part of libc, IIRC).

Others please correct me if I'm wrong

[krzee]

you're in luck... i just needed to play with this too
i did not make a script out of it, because i decided to handle my issue by rewriting the hosts file instead of overwriting DNS... but heres the commands that matter, you can steal the skeleton of the script to put these in from update-resolv-conf linux script if you like...

setprop net.dns1 8.8.8.8
setprop net.dns2 4.2.2.1

[Mimiko]

oke, junjust, every solution a found on internet is pointing to resolv.conf. But how about using DHCP option? When DHCP server pushes with IP and the DNS, is it writed to resolv.conf, too? I just don't know how this works on linux.

Thanks, krzee, I thought about this command, but didn't tried yet. But, "busybox nslookup" looks for the DNS in resolv.conf only. I created this file and busybox even finds the DNS IP from resolv.conf, still does not resolve the name. But ping resolves using 8.8.8.8 after the setprop command. Setting with the "setprop" our internal DNS, ping resolves the domains. Busybox nslookup looks for DNS IP from /system/etc/resolv.conf only. And even the DNS is accesible, busybox can't resolve. If I remove resolv.conf, "busybox nslookup" uses 0.0.0.0 as DNS server.

[krzee]

here is my resolv.conf:

Code: Select all

# cat /system/etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

my hosts file has an entry which my vpn --route-up script adds

nslookup checks my ISP's nameserver, not what is in resolv.conf (because if i 'getprop net.dns1', that is the nameserver it says it uses)

trust me, the command i gave you controls what nameserver is used, not resolv.conf

the hosts file is respected too, the entry in my hosts.conf exists nowhere in DNS, but i can nslookup it and get the right reply, and i can ping it.

you now should have all the info you need for this, hope it helps =]

if you need help writing the script come find me on the IRC, but I think you can handle it with the above info

[gomita]

Hi to all. I'm bringing back this issue just to ask you if you had the same problem as me: in my setup I also need my corporate DNS server because we have a lot of fqdn to resolve that are internal to our network. I've set DNS server with openvpn VPN DNS option and all is working ok, but here is the weird problem:

* If i'm connected via Wifi, all traffic is routed via VPN tunnel and I can connect to our http sites no matter what browser I use (stock, firefox, opera, dolphin, skyfire)
* but If i'm connected via 3G, all browsers fail except firefox :S, i've checked and DNS server setting is ok
* busybox nslookup always works right
* ping, etc, from terminal emulator always works right
* ping from the openvpn server to the android client always goes through ok

Anyone has experienced the same problem?

Many thanks in advance

[Mimiko]

I will write a post on setting OpenVPN on Android. But for now, using setprop net.dns1 DNS_IP is not taken in account by browser and a nslookup program from market. On android IRC I asked the question and they don't know why, and from wich parameter browser takes IP of the DNS.

[gomita]

I think I solved this. The problem was a property that I think is set on succesful 3G connection by our cell phone provider. The property in question is: net.gprs.http-proxy. It was set to: http://200.x.x.x:8080 and all HTTP traffic from the browser was sent to that proxy. Just issuing "setprop net.gprs.http-proxy off" fixed the problem.

Hope it helps somebody else...

Thanks anyway!

[Mimiko]

gomita, it's not about the proxy. Proxy just gives access to pages. But Android's browser uses providers DNSes, which are not acessible due to traffic redirect. So browser just can't resolve name to ip. To test this behavior, just connect to some OpenVPN server which redirects all traffic and install (before VPN) on Android DNS lookup (https://market.android.com/details?id=c ... okup&hl=en). This software also uses DNSes from some place else, rather than net.dns, maybe it uses net.rmnet0.dns, which will not be correct as connection may be done also by wifi.

[dazo]

This was discussed on the IRC channel the other day, and one guy came with a great hint!

<Waraudon> [19-03 11:31:06] dazo: I actually just now figured it out. The main DNS server is stored in net.dns1, and can be read/set using 'getprop net.dns1' / 'setprop net.dns1 <server>'

It still needs to be done via scripts in OpenVPN. We have no plans to change that. The reason is based on differences between Windows and *nix-platforms. First of all, to make DHCP work, you need TAP. That's no exception. But lets look on these differences more in detail:

Lets first have a look at the difference between TUN and TAP devices. TUN is a layer 3 adapter, which can only do IP based traffic. So there are no MAC addresses or Ethernet headers in the data stream when using TUN. When using TAP, it can transport all kind of network protocols, not just TCP/IP. That's because TAP is a layer 2 adapter, which provides Ethernet frames in the data stream. You can say that TAP devices are the closest you get to simulate a real hardware network card (NIC).

Now lets have a look at the platform differences. In Windows, there exists no such thing as a TUN device. The network driver in Windows is a pure TAP interface. However, the TAP driver is clever enough to emulate a TUN device, by adding the needed Ethernet frames before pushing the data stream further to the Windows kernel - as a proper NIC would normally provide. So when a OpenVPN session is being set up on Windows, the OpenVPN client establishes the connection with the server, retrieves all the needed network information. Then it "activates" the TAP adapter in Windows, which causes Windows to start sending DHCP requests on this device. The TAP driver then emulates a DHCP server, providing IP address, network mask and DNS resolvers, which is sent back to the Windows kernel. And voilá, the VPN is configured.

In the *nix world, you can probably do the same, by using a --up script together with --up-delay. This 'up script' will then start dhclient on the TAP device. But this will not(!) work on TUN. That's because DHCP sends out MAC broadcast packets with IP address set to 0.0.0.0. This will not be possible to transport over a TUN device, which does not have any concept of Ethernet frames, which is required for such broadcast packets.

Further, the TUN devices are supported in a very much different way in the *nix world. Where it is fully integrated in the OS kernels, and when the kernel knows this is a TUN device, it will not bother about Ethernet frames and these packets will go straight to the IP parsing code. So if you manage to bind a DHCP client to a TUN interface, the traffic itself will probably never reach OpenVPN, as the kernel might pretty much reject these "non-sense" packets.

So the conclusion for the *nix platform is that it is not possible to use DHCP at all on TUN. Unless the TUN drivers are re-written on Linux, *BSD and Solaris to support such features. But to be honest, I don't think that will gain much traction. As the *only* benefit you get is to make dhclient (or another DHCP client) to modify /etc/resolv.conf. The response will probably something be like "Use your platforms utilities to setup name resolvers properly, don't create a massive hack in the kernel to that job for you". For Android, that probably means using getprop/setprop, or writing an even better OpenVPN frontend on Android which uses the VPN abstraction which came in Ice Cream Sandwich (v4.0) ... On Linux, it can even mean to integrate better with NetworkManager - something which the OpenVPN plug-in to NM already does.

I hope this can help you to understand that DHCP isn't necessarily the right approach for non-Windows platforms, especially when using TUN devices. But if you use TAP devices, you might find a way how to make that work with DHCP in the *nix world. However, I believe you need the latest 2.3-alpha code, to make it work - James have provided some fixes to improve DHCP over TAP.