Configuring always-on VPN on Android using a server domain name instead of a server IP address

Question

I am connecting to my home Hamachi-powered VPN with my Android (v4.4.x) mobile device using IPSec. The VPN connection is working fine, except that I am unable to configure the connection as "always-on" within Android's VPN settings. As a result the connection frequently drops and requires me to go back into my mobile device's Android settings and restart the VPN manually, which is annoying and sort of defeats the purpose of having a VPN.

(Side note: A bit more about the "always on" setting can be found here near the bottom of the article: http://www.howtogeek.com/135036/how-to-connect-to-a-vpn-on-android/.)

The cause of my problem is that Android requires a static VPN Server IP address before it will accept a VPN connection as "always on", and Hamachi doesn't use a static IP for mobile VPN connections. Instead, it only uses the static url "m.hamachi.cc".

So, I have two questions: First, how can I set up my VPN connection as "always on", given that the VPN server doesn't have a static IP address, which is required? Second, why does Google require a static IP for an always-on connection, what is the benefit to that?

Thanks, I'd appreciate any ideas.

Solution

It's quite a long time since this has been asked, but I am trying to answer it anyway. Based on the answer in this thread, the issue is DNS spoofing:

Always-on vpn is there to protect you from a network you can't control. If you have a DNS name in place instead of an ip, the device would have to resolve this name BEFORE the vpn tunnel is established. But this resolution would happen on a network you don't trust, so you couldn't be sure that the ip returned for the name is the correct one.

One scenario would be, that the dns server in the untrusted network would give you the ip to a VPN server under it's control to which then your credentials would be sent (instead of your own server).

Comments

[Aron]

At this level of tin foil hatting how does requiring a static IP protect against ARP poisoning? Which is arguably just as easy as DNS spoofing.

[Ramhound]

This is a comment submitted as an answer to a question. You should edit your answer so it directly and in detail answers the author's question. Comments should never be submitted as an answer to a question. 'Since I can't comment I would assume that your answer Christian is correct." - This statement is a comment.

[Christian]

You are absolutely right. I guess the reasoning behind this is that it was one easy way to prevent DNS spoofing while measures against ARP spoofing would be harder to implement on the smartphone (see en.wikipedia.org/wiki/ARP_spoofing#Defenses) If I'm not mistaken, the problem could be solved with usage of a VPN protocol that enforces a server with a trusted certificate

[Terry Burton]

@christian Indeed, all modern VPN protocols either have the option to authenticate the endpoint (e.g. using PKI or pinning the server certificate) or their key exchange uses a shared secret in such a way that does not divulge anything about the secret when attempting a connection to a rogue host.