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.
