The following ten sections describe how to set up and use the FEAT VPN app. If you would like to connect to a VPN service, please check out new section 11. If you are an experienced OpenVPN administrator, then sections 01 and 02 may be enough to get you up and running.
Note that things work slightly different on Android phones (Android versions 2.x) and Android tablets (Android versions 3.x). Tablet users need to go through a few steps that do not apply to phone users.
If you are dealing with a specific error message, e.g., Code M01 or Lite time limit, you may want to use the search function of our website to get to the relevant section more quickly.
If you run into problems and the documentation does not help, please let us know in our support forum.
FEAT VPN brings OpenVPN to Android versions before Android 4.0, no root required. It is the first layer-3 VPN app that works on any off-the-shelf device with an Android version between 2.1 and 3.2.
Android 4.0 and later break the underlying technology of FEAT VPN. Thus, unfortunately, FEAT VPN cannot be made to work on these Android versions. However, Android 4.0 is also the first release to offer official support for VPN apps. Somebody else will probably come up with a version of OpenVPN for Android 4.0+.
FEAT VPN comes in two versions. The free version, FEAT VPN Lite, is intended for people who connect to a VPN server only occasionally. To check their email a few times each day, for example. Use of FEAT VPN Lite is limited to one hour per day. The commercial version does not have this time limit.
You are probably aware of the built-in Android VPN client. On most devices it is accessible via Settings > Wireless & networks > VPN settings. Its supported VPN protocols are PPTP, L2TP, and L2TP/IPsec. Normally, you would use the built-in client to connect to, say, a remote L2TP server. The fundamental idea behind FEAT VPN is to not connect the built-in client to a remote server, but, instead, to connect it locally to the FEAT VPN app on the device. The FEAT VPN app then sits between the built-in L2TP client and the remote OpenVPN server and provides VPN protocol translation:
The following diagram illustrates this idea.
Note that the security of L2TP is not relevant here. The L2TP connection is established between two apps on the same device: the built-in L2TP client app and the FEAT VPN app. L2TP packets never traverse a network, because they never leave the device. Security issues of L2TP thus do not apply to FEAT VPN.
The underlying technology of FEAT VPN has a few drawbacks. In our experience they do not have much of an impact, though.
IPv6. The built-in L2TP client does not support IPv6 and, accordingly, FEAT VPN cannot support IPv6, either.
Network Configuration And Routes. The OpenVPN server pushes network configuration changes to the OpenVPN client when a VPN tunnel is being established, e.g., a DNS server to be used by the client. Just like IP packets, FEAT VPN receives these configuration changes from OpenVPN and forwards them via L2TP to the built-in L2TP client. We are thus limited to network configuration changes that can be transmitted via L2TP, which are:
In particular, L2TP does not support route modification. The built-in L2TP client generally routes all traffic through the L2TP connection. So, no split tunnels. When the OpenVPN tunnel is up, all traffic always goes to the OpenVPN server.
TUN/TAP. The built-in L2TP client only offers a TUN-like device. FEAT VPN inherits this limitation and, accordingly, only supports TUN configurations.
System Calls. Just like the rest of FEAT VPN, the OpenVPN client does not run with root privileges. This breaks a few OpenVPN options, e.g., chroot or mlock.
Device-Specific Bugs. Apart from these general limitations, a handful of Android devices comes with a broken built-in L2TP client. On startup, FEAT VPN detects and notifies you of any known problems with your device. The section Installing And Running FEAT VPN contains more details.
The source code of our versions of OpenVPN is available at the following URLs:
Version 8 - http://www.featvpn.com/sites/default/files/v08.tgz
Version 10 - http://www.featvpn.com/sites/default/files/v10.tgz
Version 20 - http://www.featvpn.com/sites/default/files/v20.tgz
The archive includes the OpenSSL and LZO libraries as well as the build files that are required to recompile OpenVPN. Note that we use Linux to develop FEAT VPN and it has been brought to our attention that at least on Windows the build process does not work out of the box. On Linux, simply install the Android NDK, unpack the archive, and run ndk-build.
The licenses of the open source components used by FEAT VPN are available at the following URL:
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). This product includes cryptographic software written by Eric Young (firstname.lastname@example.org).
This section assumes that you are very familiar with setting up and running OpenVPN servers and clients. It summarizes those aspects of FEAT VPN that may not be obvious and leaves the rest to your experience. If you prefer more detailed guidance, please skip ahead to the next section Installing And Running FEAT VPN.
Initial Setup. FEAT VPN supplies a local L2TP server on your Android device. The basic idea underlying FEAT VPN is to connect the L2TP client built into Android to this local L2TP server. On Android 2.x (i.e., Android phones) FEAT VPN automatically handles this L2TP connection behind the scenes. On Android 3.x (i.e., Android tablets), however, you need to manually configure the L2TP connection with the built-in L2TP client. The name of the L2TP connection needs to be Feat, the L2TP server needs to be localhost. If you have an Android tablet, push the Setup button on the main screen to get to the setup screen, which has further information.
Test Suite. FEAT VPN depends on the correct implementation of the built-in L2TP client. Unfortunately, a few devices have severely broken L2TP clients. This is why FEAT VPN comes with a test suite, which makes sure that it works on your device. If you have an Android phone, pushing the Setup button on the main screen starts the test suite. If you have an Android tablet, then push the Test button on the setup screen after you have configured the L2TP connection.
If you have an Android tablet, your help is needed after the first four tests have been run. You need to manually establish the L2TP connection to localhost that you previously configured. Use a user name of test and a password of x to establish the connection - as pointed out by the instructions shown by FEAT VPN at this point. Again, on Android phones this happens automatically behind the scenes.
Tunnel Configuration. Push the Tunnels button on the main screen to add a VPN tunnel. Push the Add button to get to the tunnel edit screen. Here you give your tunnel a name and load your VPN configuration. The two most common configuration formats are supported:
Tunnel Establishment. If you have an Android phone, simply push the Tunnels button on the main screen and tap on the VPN tunnel that you would like to connect. If you have an Android tablet, you need to manually connect the L2TP connection that you previously configured. Push the Connect button on the main screen. This brings up the built-in L2TP client. As the L2TP user name enter the name of the tunnel to be connected, as the L2TP password enter the password that unlocks any password-protected keys in the VPN configuration. If none of your keys are password-protected, simply enter x as a dummy password. FEAT VPN will detect the incoming L2TP connection, receive the user name that you entered, and match the user name against the names of the VPN tunnels. The VPN tunnel that matches your entered user name is then connected.
DNS Server. You can push a DNS server from your OpenVPN server to FEAT VPN.
NAT And Battery Life. When you are on mobile data, your phone accesses your OpenVPN server via the operator gateway of your mobile carrier. The operator gateway is essentially a firewall with NAT. This leads to the following problem: When your VPN tunnel is idle for a while, the NAT mapping for your VPN tunnel will time out on the operator gateway. When your VPN tunnel becomes active again, the operator gateway will use a new, different NAT mapping. The OpenVPN server now sees a different source port in your VPN tunnel packets and drops them - your tunnel hangs. You can revive it by pushing the Reconnect button on the status screen. You can also keep the NAT mapping from timing out by setting up pings on your OpenVPN server and add, for example, ping 30 to your server configuration. This, however, can severely drain the battery of your Android device as the pings prevent its radio from going to sleep. So, try to find a ping interval that is as long as possible but still keeps the NAT mapping alive. Also, Wi-Fi routers seem to have longer NAT timeouts than most operator gateways. You may also want to try using OpenVPN via TCP vs. UDP. Different NAT timeouts may apply to different network protocols.
Switching Networks. FEAT VPN detects when you switch from mobile data to Wi-Fi and vice versa and automatically restarts the OpenVPN tunnel on a switch.
FEAT VPN is described in much greater detail in the following sections.
On installation, FEAT VPN asks for five permissions. Here's what they are and why FEAT VPN requires them:
INTERNET, which enables network communication. We use this permission to establish the L2TP connection with the built-in L2TP client as well as the OpenVPN tunnel with the remote OpenVPN server.
RECEIVE_BOOT_COMPLETED, which allows an app to detect when the Android device was switched on or rebooted. We need this permission, because FEAT VPN can be configured to automatically start on boot.
WAKE_LOCK, which allows an app to prevent the device from sleeping. FEAT VPN uses this permission to prevent the device from turning off the screen when running automated tests. See the section Initial FEAT VPN Setup for details on these tests.
READ_LOGS, which allows an app to access the Android system log. We use this permission to read the system log entries of the built-in L2TP client. If you report a problem with FEAT VPN, we ask you to send us the FEAT VPN log, which also contains said system log entries. This helps us to track down the problem.
WRITE_EXTERNAL_STORAGE, which allows an app to write to the SD card. When you send us the FEAT VPN log, it is compressed with gzip and then attached to an automatically generated email. The compressed log is written to the SD card and later deleted. This is why we need this permission.
When FEAT VPN is started, it goes through a few basic checks to make sure that it works as intended on your device. Here are the things that can come up at this point:
Duplicate Installation. If you are upgrading from FEAT VPN Lite to the commercial version, it is best to uninstall FEAT VPN Lite first. FEAT VPN Lite and the commercial version cannot coexist on the same device. If you start FEAT VPN and it indicates that both versions are installed, please uninstall FEAT VPN Lite. Then start the commercial version again.
Crash. If you restart the FEAT VPN app after it crashed, it asks you to send us the FEAT VPN log. Please do not ignore this. Please send us the log. It helps us to make FEAT VPN more robust.
Device Problems. A tiny number of devices comes with a broken L2TP implementation in the built-in L2TP client. Here are the problems that are detected by FEAT VPN at startup and their associated error codes:
But before you try to work around this problem, find out whether it really affects you. Technically, the problem behind this error code is that on some devices TCP-based DNS lookups may fail. The vast majority of DNS lookups, however, is UDP-based. DNS uses TCP only for large DNS responses of 512 bytes and more and domains with DNS responses that large are very rare. So, simply go ahead and surf a little with an established VPN tunnel. If you encounter problems with DNS, i.e., if your browser tells you that a certain website cannot be found, then try to work around the problem. If this does not help, then please let us know in our support forum. Also, your device vendor may be offering an upgrade to a newer Android version that adds support for IPv6 and makes this problem go away.
Turn off any of the above components that you do not absolutely need. Then restart your device. Now the disabled components do not store any settings in the system property table of your device, leaving space for the settings of the built-in L2TP client. When you now start FEAT VPN, this error code should not appear again. If it does, then please let us know in our support forum. Also, your device vendor may be offering an upgrade to a newer Android version that increases the size of the system property table and makes this problem go away.
The following screen shot shows the main screen of FEAT VPN on Android phones.
The main screen on Android tablets looks slightly different, as can be seen in the following screen shot. It has an additional button.
To start the configuration process, push the Setup button. The button works slightly differently on Android phones and Android tablets. On Android tablets, this button takes you to the setup screen, which is described in the next section, L2TP Configuration. On Android phones, the button skips the setup screen and takes you directly to the test screen, which is described further down in the section Self Test. So, if you have an Android phone, then please skip the next section and skip forward to the section Self Test instead.
This section only applies to Android tablets. If you use FEAT VPN on an Android phone, then please skip this section and move on to the section Self Test.
As outlined in the section Underlying Technology, FEAT VPN acts as a VPN protocol translator between L2TP and the OpenVPN protocol. The idea is that the built-in L2TP client establishes an L2TP connection to FEAT VPN - and now we tell it, how to accomplish that. To the built-in L2TP client, FEAT VPN looks like an L2TP server that runs locally on the device. In other words, FEAT VPN looks like an L2TP server with an IP address of 127.0.0.1 or a DNS name of localhost, respectively. The initial setup of FEAT VPN thus requires us to configure an L2TP connecting in the built-in L2TP client accordingly.
Pushing the Setup button takes you from the main screen to the setup screen, which is shown in the following screen shot.
The setup screen describes in detail what needs to be done. It breaks the process down into ten simple steps and each step is illustrated by a screen shot. Scroll horizontally and, if needed, vertically to review the given ten steps. In a nutshell, here is what the ten steps accomplish:
You could open the built-in L2TP client via Settings > Wireless & networks > VPN settings, but the Start button on the setup screen provides a shortcut. Push it to bring up the built-in L2TP client. Then configure the L2TP connection as described.
After you configured the L2TP connection and pushed the back button to return to FEAT VPN, push the Test button on the setup screen, which takes you to the test screen.
The following screen shot shows the test screen.
The test screen essentially provides an extended version of the checks described under Device Problems in the section Startup. A total of 20 tests is run, including tests that establish a test VPN tunnel to our test VPN server. Please make sure that your device is connected to the Internet before running the tests.
This section only applies to Android tablets. If you use FEAT VPN on an Android phone, then please skip this section and move on to the section Test Description.
The first four tests run automatically, but then your assistance is required and FEAT VPN automatically switches from the test screen to the test connection screen, which is shown in the following screen shot.
It looks a bit like the setup screen in that it outlines a few steps that need to be taken in the built-in L2TP client. This time there are four steps and, again, they are illustrated by four screen shots. Again, scroll horizontally and, if required, vertically to review the four steps. In a nutshell, here is what needs to be done:
Again, the Start button is a shortcut and pushing it brings up the built-in L2TP client. Push it and establish the L2TP connection as described. Once the built-in L2TP client starts connecting to the L2TP server provided by FEAT VPN, the test screen becomes active again and the remaining tests are run.
While the tests are running, push the Stop button at any time to abort. Here is what the individual tests do:
L2TP Protocol. Tests the implementation of L2TP on your device. Test failure means the same as Code M01 under Device Problems in the section Startup. See there for more information. In a nutshell, if this test fails, then your built-in L2TP client claims to support L2TP, but does not. As L2TP support is essential for FEAT VPN to work, this unfortunately means that you are not able to run FEAT VPN on your device.
IPv6 Addressing. Tests, whether your device is IPv6-ready. Test failure means the same as Code M02 under Device Problems in the section Startup. See there for more information. In a nutshell, you may run into DNS resolution problems under very specific and rare circumstances.
Reverse Path Filter. Tests, whether a feature of the Linux kernel is enabled that breaks any VPN app on your device. We have never seen this test fail. Please let us know in our support forum, if this test fails for you.
System Property Table. Tests, whether the system property table has space left for the built-in L2TP client to store its settings. Test failure means the same as Code M04 under Device Problems in the section Startup. See there for more information. In a nutshell, you probably are unable to connect the built-in L2TP client to FEAT VPN unless you are able to free up space in the system property table of your device.
L2TP Connection 1 of 2. This test waits for the built-in L2TP client to connect to FEAT VPN. It succeeds as soon as it receives the first L2TP packet from the built-in L2TP client. So, it tests, whether the built-in L2TP client is able to initiate an L2TP connection with FEAT VPN. So far, we have seen this test fail only if the previous test, System Property Table, also fails. So, the recommended fix for that test applies. If it fails on your device and the previous test does not fail, then let us know in our support forum, you are on to something.
L2TP Connection 2 of 2. This test succeeds as soon as the L2TP connection with the built-in L2TP client is fully established. So, it tests the handshake between the built-in L2TP client and the on-device L2TP server of FEAT VPN. If this test fails, then either the built-in L2TP client or FEAT VPN sends an unexpected L2TP packet during the handshake on your device. Please let us know in our support forum. This should be easy to fix.
Intercepted UDP Ping / Download / Upload. These three tests determine whether UDP packets can be sent through the established L2TP connection. Ping sends a single UDP packet in both directions through the L2TP connection. Download sends multiple UDP packets through the L2TP connection from FEAT VPN to the built-in client. Upload sends multiple UDP packets through the L2TP connection in the opposite direction. On some Android 2.1 devices the Upload test fails because of a memory (accounting) leak in the L2TP implementation in the Linux kernel. If you are planning to use an application via the VPN that sends a lot of UDP packets through the L2TP connection, then this application may not work on your device. If you run into problems with UDP-based applications, then please let us know in our support forum.
Note that the leak also affects ICMP-based applications. So, if you ping a remote IP address through the VPN tunnel and get error messages after a few successful pings, then this may very well be a manifestation of this problem.
Bypass UDP Ping / Download / Upload. These three tests are similar to the previous three tests. However, they do not send UDP packets through the L2TP connection, but around the L2TP connection. If Upload failed in the previous three tests, then it should also fail here. If Download or Upload fail for these tests only, then don't worry. These two tests are proactive sanity checks and the functionality tested by these two tests is not currently used by FEAT VPN.
Bypass TCP Ping / Download / Upload. These three tests are like the previous three tests, just for TCP instead of UDP. They send TCP data via a TCP connection through the L2TP connection instead of UDP packets. Again, do not worry about failure of Download or Upload here.
Bypass DNS Lookup. This test is similar to the Bypass UDP Ping test. It is a real world version of this test. It performs a DNS lookup around the L2TP connection. If this test fails, please make sure that your device is connected to the Internet. This is the first test that assumes that you are connected. If the Internet connection works and the test still fails, then let us know in our support forum.
Bypass HTTP Request. This is a real world version of the Bypass TCP Upload and Download tests. It performs an HTTP request around the L2TP connection. If this test fails, please make sure that your device is connected to the Internet. If you are connected and this test still fails for you, let us know in our support forum.
VPN Tunnel. So far the tests only concerned the L2TP connection between the built-in L2TP client and FEAT VPN. The L2TP connection is the most complex part of FEAT VPN - and this is why there are that many tests for it. In contrast, this test is concerned about OpenVPN tunnels. It starts OpenVPN and tries to establish an OpenVPN tunnel to our test OpenVPN server. If it fails, it means that the OpenVPN tunnel could not be established. Please make sure that your device is connected to the Internet. If it is and this test still fails for you, then please try again a few minutes later, our test OpenVPN server may be temporarily unavailable. If the test keeps failing, then please let us know in our support forum.
VPN DNS Lookup. The complement to Bypass DNS Lookup. The DNS lookup is not routed around any VPN tunnel, but through the L2TP and OpenVPN tunnels, through the NAT on our test OpenVPN server, to a DNS server. This is the first end-to-end test in the test suite. If it fails for you, then please try again a few minutes later, our test
OpenVPN server may be temporarily unavailable. If the problem persists, please let us know in our support forum.
VPN HTTP Request. The complement to Bypass HTTP Request. Similar to the previous test, the HTTP request is not sent around any VPN tunnel, but end-to-end through the L2TP and OpenVPN tunnels to the IP address of the remote tunnel endpoint on our test OpenVPN server. If this test fails for you, then please try again a few minutes later to rule out a temporary problem with our test OpenVPN server. If the problem persists, please let us know in our support forum.
If one or more of the tests fail, FEAT VPN asks you to send us the FEAT VPN log. Please do so. It contains valuable information about the problem, which helps us to investigate it. Please also consider sending us the FEAT VPN log, if all tests pass. In this case, the log tells us that all tests passed on the Android device of your specific
make and model with your specific Android version. We regularly test FEAT VPN on more than 25 representative devices across multiple vendors and Android versions, but otherwise very similar devices can exhibit subtle differences. Having your log, even if all tests passed, allows us to obtain a more detailed picture of the robustness of FEAT VPN across all Android devices. This can then inspire future improvements to FEAT VPN.
Once the tests are finished, the Run button restarts the tests. The Send button opens your email client so that you can easily send us the FEAT VPN log from your device via email. The FEAT VPN log is a simple text file compressed with gzip that is transmitted as an email attachment. Open it and take a look, if you are interested.
Finally, push the Exit button to return to the main screen. You have successfully set up FEAT VPN.
When something goes wrong, the FEAT VPN log is your friend. It aggregates log entries from the built-in L2TP client, from OpenVPN, and from the FEAT VPN app itself. On the main screen, push the Log button to switch to the log screen, which is shown in the following screen shot:
The log can be scrolled vertically and - as some lines of the log can be pretty long - horizontally. When you scroll back, i.e., towards earlier log entries and the beginning of the log, the FEAT VPN log is locked. This means, that no new log entries are captured, the log is not updated. In this way, existing log entries are not pushed up and you can comfortably review the existing log entries. After you are done reviewing, scroll all the way to the end of the log again in order to unlock it. While the FEAT VPN log is locked, the header of the log screen says Locked.
The Send button opens your email client so that you can easily send us the FEAT VPN log from your device via email at any time. It is compressed with gzip and sent as an email attachment. Note that for performance reasons the log page never displays more than the 200 most recent entries in the FEAT VPN log. So the attached log is usually longer than what you see on the log screen. Just in case you were wondering about the size of the attachment.
The Clear button clears the log screen. It does not clear the FEAT VPN log. So, you would be able to send us the FEAT VPN log even after clearing the log screen. If you touch and hold the Clear button, the log screen is cleared and FEAT VPN logs statistics about CPU usage of the four FEAT VPN components. Each tick corresponds to one hundredth of a second of CPU time.
The Zoom In and Zoom Out buttons increase the size of the font in which the FEAT VPN log is shown. If you are interested in details, zoom in. If you are interested in an overall view or if your eyes are good, zoom out.
Push the back button of your device to return to the main screen.
Push the Tunnels button on the main screen to get to the tunnel list screen, which is shown in the following screen shot.
The tunnel list screen shows a list of all configured VPN tunnels. The screen shot has two VPN tunnels configured, they are named vpn-us and vpn-jp and have VPN servers vpn-us.corp.example.com and vpn-jp.corp.example.com.
To add your first VPN tunnel, push the Add button, which takes you to the tunnel edit screen. Other than that, there are a few other things that you can do on this screen. There are slight differences between Android tablets and Android phones:
Android tablets - A short tap on a configured VPN tunnel takes you to the tunnel edit screen and allows you to edit the tunnel. Moreover, a long tap on a configured VPN tunnel shows a delete button for the tunnel and allows you to delete the tunnel.
Android phones - A short tap on a configured VPN tunnel connects the tunnel. Moreover, a long tap on a configured VPN tunnel displays further options in a dialog box. Pushing the Edit button in the dialog box takes you to the tunnel edit screen and allows you to edit the tunnel. Pushing the Delete button in the dialog box deletes the tunnel. Finally, pushing the Cancel button in the dialog box just closes the dialog box without taking any action.
Pushing the back button of your device always takes you back from the tunnel list screen to the main screen, on tablets as well as on phones.
A new or existing VPN tunnel is configured on the tunnel edit screen, which is shown in the following screen shot.
Let us take a look at the individual settings.
Name. This assigns a name to the VPN tunnel. The name is displayed on the tunnel list screen. In addition, on Android tablets the tunnel to connect is specified by entering its name. See the section Connecting A VPN Tunnel for details on this.
Store Credentials. This tells FEAT VPN to store the user name and password(s) that you enter when establishing this VPN tunnel. When you later establish this VPN tunnel again, FEAT VPN uses the stored credentials and you do not have to re-enter them. This is convenient, but it is also risky. If an attacker gains access to your Android device, she will be able to retrieve the stored VPN credentials. FEAT VPN applies encryption and file system permissions to make credential theft harder. But it does remain a risk.
Configuration. The configuration of this VPN tunnel. FEAT VPN supports configurations in the two most common formats:
Configurations can be loaded from the tunnel edit screen. Consult the section Loading Configurations for more information.
The following configuration options need to be controlled by FEAT VPN for proper operation:
dev, dev-type, dev-node, iproute, socks-proxy, askpass, auth-user-pass, auth-retry, auth-nocache, ifconfig-noexec, route-noexec, route-delay, up-delay, persist-tun, user, group, chroot, cd, setcon, mlock, daemon, syslog, inetd, log, log-append, writepid, status, replay-persist-file
When a configuration is loaded, these options are stripped from the .ovpn file.
Address. This is the IP address or DNS name of the VPN server. it is taken from the remote option in the .ovpn file.
CA Certificate. This is the file name of the CA certificate. It is taken from the ca option in the .ovpn file.
User Certificate. This is the file name of the certificate used to authenticate with the VPN server. It is taken from the cert option in the .ovpn file.
User Key. This is the file name of the private key used to authenticate with the VPN server. It is taken from the key option in the .ovpn file.
TLS Key. This is the file name of the shared TLS authentication key for the HMAC authentication of VPN packets. It is taken from the tls-auth option in the .ovpn file.
Secret Key. This is the file name of the pre-shared static encryption key, if SSL is not used. It is taken from the secret option in the .ovpn file.
In order to save the settings for a VPN tunnel, simply push the back button on your device to return from the tunnel edit screen to the tunnel list screen. In order to abandon your changes to a VPN tunnel, push the Cancel button at the top of the tunnel edit screen.
Push the Load button on the tunnel edit screen to get to the file browser screen, which is shown in the following screen shot.
Initially, the file browser screen shows the content of the root directory of the SD card. Tap on a subdirectory to switch to the subdirectory and show its content. Push the Parent button to return to the parent directory. Push the Home button to return to the root directory of the SD card.
The current directory is always displayed above the directory content. Here's what kind content is displayed for a directory:
In particular, all other files are filtered and not displayed. We are only interested in VPN configurations, after all.
The screen shot shows that the current directory is the download directory of the web browser, /mnt/sdcard/download, which contains two VPN configurations: the ZIP archive vpn-jp.zip and the self-contained VPN configuration file vpn-us.ovpn.
Tapping on a configuration loads it and takes you back to the tunnel edit screen. Push the back button of your device to return to the tunnel edit screen without loading any configuration.
Instead of navigating through layers of subdirectories to a configuration, you can also simply push the Search button. It searches the current directory and, recursively, all subdirectories beneath it for configurations, i.e., for files with names ending in .zip or .ovpn. The Search button takes you to the search screen, which is shown in the following screen shot.
The screen shows the start directory of the search, /mnt/sdcard, and the search results: vpn-jp.zip and vpn-us.ovpn. For each result the file name of the configuration and the directory in which it is located is given. In the screen shot, both configurations were found in /mnt/sdcard/download.
Tap on a search result to load the configuration and return to the tunnel edit screen. Push the back button of your device to return to the file browser screen without loading any configuration. While the search is running, search statistics are periodically updated. Push the Cancel button to abort the ongoing search.
VPN tunnels are connected slightly differently on Android phones and Android tablets.
Android phones - Things are easy on phones. On the main screen, simply push the Tunnels button, then do a short tap on the VPN tunnel that you would like to connect.
Android tablets - Things are a little more complicated on tablets. On phones operation of the built-in L2TP client is automatic and behind the scenes. This is not possible on Android 3.x, i.e., on tablets. To connect a VPN tunnel on a tablet, push the Connect button on the main screen. This brings up the built-in L2TP client. Then, using the built-in L2TP client, establish the L2TP connection to localhost that you previously configured according to the section L2TP Configuration. The user name and password that you enter when connecting with the built-in L2TP client are used as follows:
For the interested, here is a quick look at how FEAT VPN invokes the OpenVPN client. If you are not interested, simply skip ahead to the next section Managing A VPN Tunnel.
The following options are passed on the OpenVPN command line in the given order:
errors-to-stderr, which allows FEAT VPN to receive errors from OpenVPN and log them to the FEAT VPN log.
dev-type tun, which forces OpenVPN run in TUN mode. FEAT VPN does not support TAP devices. This is one of the limitations that FEAT VPN inherits from Android's built-in L2TP client.
dev-node <UDS path>, which specifies the simulated TUN device via which FEAT VPN communicates with OpenVPN. FEAT VPN exchanges network packets with OpenVPN via a Unix domain socket.
iproute <executable path>, which specifies the external executable that is used by OpenVPN to communicate things like route updates to FEAT VPN.
setenv, which sets environment variables that are required by the external executable.
socks-proxy 127.0.0.1 1701, which specifies a SOCKS proxy that is part of FEAT VPN. This puts the FEAT VPN app between OpenVPN and the remote OpenVPN server and thus allows the app to manage the connection between OpenVPN and the remote VPN server.
ping-restart 0, which disables restarting the client, if the VPN tunnel is idle. The Internet connection of a mobile device comes and goes and we do not want to restart the client, just because you temporarily have a weak or no signal and cannot talk to the VPN server.
tran-window 28800, which allows up to eight hours without a key renegotiation. Again, this is to prevent the VPN tunnel from being taken down in case your mobile device is temporarily shut off from the VPN server because you have a weak or no signal.
verb 3, which specifies a more verbose log level to be used by default.
askpass <FIFO path>, which specifies the key password. The password is securely passed via a FIFO.
auth-user-pass <FIFO path>, which specifies the user name and password for authentication. The credentials are securely passed via a FIFO.
config <.ovpn file path>, which specifies the VPN configuration file. Note that certain options are stripped from the VPN configuration file when it is loaded. See the Adding and Editing VPN Tunnels section for more information.
When a VPN tunnel is connected, FEAT VPN writes the options that it passes to OpenVPN to the FEAT VPN log.
Once the VPN tunnel connection has been triggered, tablets and phones both automatically switch to the status screen, which is shown in the following screen shot.
The status screen can also be reached by pushing the Status button on the main screen. Pushing the back button of your device takes you back from the status screen to the main screen.
The status screen shows a message that describes the current state of the VPN tunnel. The state message can be any of the following:
Disconnected. No VPN tunnel is currently connected.
Disconnected (Lite time limit). The one hour time limit of FEAT VPN Lite has been reached for the day. In this case, you can only use FEAT VPN Lite again after midnight.
Connected [...]. A VPN tunnel is connected, traffic is being routed through the tunnel, everything is fine. The name of the connected VPN tunnel is given in square brackets.
While connected push the Disconnect button to disconnect the currently connected VPN tunnel. Push Reconnect to disconnect currently connected tunnel and immediately connect it again. Should you experience problems with a connected tunnel after it has been connected for a while, try reconnecting. FEAT VPN tries its best to keep a VPN tunnel connected and stable even in presence of flaky mobile connections and a fluctuating signal. FEAT VPN also tries its best to automatically reconnect a VPN tunnel when you switch, for example, from mobile data to Wi-Fi and back. However, if something goes wrong and FEAT VPN does not do a good job, you can always push the Reconnect button. If you have to do so, then please let us know. Maybe there is a way to make FEAT VPN automatically reconnect also in your specific scenario.
Connecting [...]. A VPN tunnel between FEAT VPN and the OpenVPN server is being negotiated. The name of the VPN tunnel that is being connected is given in square brackets.
Login is not a valid VPN tunnel name. This only applies to Android tablets. As stated above the user name of the L2TP connection established with the built-in L2TP client selects the VPN tunnel to be connected. If a user name is entered that is not the name of a VPN tunnel, this message is displayed. Moreover, a text input field is shown that contains the entered user name. This allows you to correct the user name within FEAT VPN, i.e., without having to return to the built-in L2TP client. When you have corrected the user name, push the OK button to retry with the corrected user name. Push the Cancel button to abort the VPN tunnel connection attempt.
Please enter your key password. The configuration of your VPN tunnel contains a key that is protected by a password. A text input field is shown that allows you to enter the password for unlocking the key, so that the user can be used for authentication with the VPN server. Push the OK button to retry with the entered password. Push the Cancel button to abort the VPN tunnel connection attempt.
Invalid key password. The previously entered password for the password-protected key is invalid and the key could not be unlocked. A text input field is shown that allows you to correct the password for unlocking the key. Push the OK button to retry with the corrected password. Push the Cancel button to abort the VPN tunnel connection attempt.
Note that on Android tablets FEAT VPN initially tries unlocking the key with the password that you entered in the built-in L2TP client when establishing the L2TP connection with FEAT VPN. The shown text input field thus initially contains the password that you entered in the built-in L2TP client.
Please enter your login and password. The VPN server asks you to authenticate with a user name and a password. Two text input fields are shown that allow you to enter your credentials for authentication. Push the OK button to retry with the entered user name and password. Push the Cancel button to abort the VPN tunnel connection attempt.
Invalid login or password. The previously entered user name and password are invalid and authentication with the VPN server failed. Two text input fields are shown that allow you to correct the user name and the password for authentication with the VPN server. Push the OK button to retry with the corrected user name and password. Push the Cancel button to abort the VPN tunnel connection attempt.
Note that on Android tablets FEAT VPN initially tries authenticating with the user name and password that you entered in the built-in L2TP client when establishing the L2TP connection with FEAT VPN. The shown text input fields thus initially contain the user name and password that you entered in the built-in L2TP client.
Connection error. Something unexpected went wrong. Please take a look at the FEAT VPN log for more information and let us know about this in our support forum.
This is our reference server configuration, which we use for most of our testing:
server 172.21.0.0 255.255.0.0 dev tun local x.x.x.x port 1194 topology net30 push "dhcp-option DNS 220.127.116.11" # pushing this only works, if compression is enabled on the client #comp-lzo no #push "comp-lzo no" user nobody group nogroup persist-key persist-tun ping 120 ping-restart 0 tran-window 28800 tls-auth easy-rsa-2.0/keys/tls-auth.key ca easy-rsa-2.0/keys/ca.crt cert easy-rsa-2.0/keys/demo.featvpn.com.crt key easy-rsa-2.0/keys/demo.featvpn.com.key dh easy-rsa-2.0/keys/dh2048.pem script-security 3 auth-user-pass-verify verify.sh via-env verb 4
If you are unable to connect FEAT VPN to your OpenVPN server, please try this configuration and see whether it makes things work. If it does, then please try to determine which difference between the reference configuration and your configuration it is that prevents FEAT VPN from connecting to your OpenVPN server when using your configuration. Then please report your findings in our support forum. Please also let us know in our support forum, if you cannot connect to your server when using the reference configuration.
As you can see in the reference configuration, you can push a DNS server to FEAT VPN.
The ping 120 directive is particularly interesting and you probably need to experiment with it a little to provide robust VPN services to your mobile users. Let's first take a look at the underlying problem. Here's how a mobile phone connects to your VPN server when connected to the Internet via a mobile data connection.
Mobile phones access the Internet via an operator gateway. The operator gateway is essentially a firewall with network address translation (NAT). Tunnel packets from the mobile phone reach the operator gateway via the mobile data connection. The operator gateway replaces the source IP address and the source TCP or UDP port of the tunnel packet with the IP address of the operator gateway and a TCP or UDP port of the operator gateway. The resulting modified tunnel packet is then forwarded via the Internet to the VPN server.
Suppose that the operator gateway sticks a given port x into the tunnel packet before forwarding it to the VPN server. Subsequent tunnel packets then receive the same port, x, before being forwarded. So, from the perspective of the VPN server, all tunnel packets come from port x. The operator gateway, just like any NAT-enabled firewall, remembers the port assigned to the first packet of a TCP connection or UDP conversation and assigns the same port to all subsequent packets of the same TCP connection or UDP conversation. However, if no packets are transmitted via a TCP connection or in a UDP conversation for a given amount of time, then the operator gateway drops all knowledge about the TCP connection or UDP conversation, including the port, x. The operator gateway assumes that the TCP connection or UDP conversation is not in use anymore and reuses the port, x, for a new, different TCP connection or UDP conversation.
Suppose that our VPN tunnel is idle for too long. The operator gateway then forgets everything about our VPN tunnel, in particular that it used port x for it. Suppose that we then send a tunnel packet to the VPN server. The operator gateway now does not recognize our packet as belonging to an existing TCP connection or UDP conversation. Instead, it believes that it is seeing a new TCP connection or UDP conversation. So, a new, different port, y, is assigned to our tunnel packet. The port is then inserted into our tunnel packet and sent to the VPN server.
This confuses the OpenVPN server. It originally received our tunnel packets from port x, now it receives them from port y. As the new port, y, is different from the original port, x, OpenVPN drops all packets with the new port - our tunnel hangs. As an aside, note that the float option, which is supposed to take care of changing IP addresses and ports, only seems to work for point-to-point OpenVPN configurations and not for certificate-based point-to-multi-point configurations.
So, what can we do? We can prevent our VPN tunnel from being idle for too long. This is where the ping option comes into play: We would like to make the VPN server ping the mobile client regularly in order to prevent a timeout on the operator gateway. We ping in this direction, i.e., from the server to the client and not the other way around, because tunnel packets from the server are less likely to get lost. Tunnel packets from the client travel over a wireless link and are thus prone to packet loss, in particular in case of a weak or no signal. Pinging from the server to the client is thus more reliable.
Now we face a dilemma. On the one hand, we want to ping as often as possible in order to keep the operator gateway from considering our VPN tunnel to be idle. On the other hand, we want to ping the least possible number of times, as each received ping packet wakes up our mobile device. If the mobile data connection is idle, our device turns off the radio, which results in a substantial improvement of battery life. However, if the server pings every few seconds, then the mobile data connection is never turned off and the battery drains.
We have seen mobile networks, where ping 120 on the server, i.e., one ping packet every two minutes, perfectly keeps a VPN tunnel functional. But we have also seen mobile networks, where even ping 30, i.e., one ping packet every 30 seconds, is not enough. On one of these networks we had to use ping 10, i.e., one ping packet every 10 seconds. On most phones this kept the radio constantly active and resulted in a battery life of only 5 hours.
Ultimately, configuring this option is a compromise. Suppose a scenario where most of your users are on a network in which ping 120 works. But there are also other users for whom one ping packet every two minutes is not enough. In this case it may be wiser to ask the latter users to accept that their VPN tunnel may break down when they do not use it. They can always push the Reconnect button on the status screen to reconnect and thus fix the hanging VPN tunnel without having to enter their credentials again.
Note that the same problem applies to devices that are connected to Wi-Fi networks. Wi-Fi routers are NAT-enabled firewalls, just like operator gateways. However, for Wi-Fi networks, ping 120 typically seems to work. Also, a Wi-Fi connection seems to be more benign in terms of battery use than a mobile 3G or LTE data connection.
So, if ping 120 does not work for some of your users when they are connected to the Internet via a mobile data connection, asking them to establish the VPN tunnel only via Wi-Fi may be another option to address this issue.
Push the Settings button to get to the settings screen, which is shown in the following screen shot.
It allows you to configure the following global settings.
FEAT VPN Service. Starts and stops the FEAT VPN service, i.e., the L2TP server that FEAT VPN runs on your Android device. If you temporarily do not need FEAT VPN, turn the service off to save memory. While the service is running, the FEAT VPN logo is shown in the status bar of your Android device.
Start On Boot. If this is enabled, then the FEAT VPN service automatically starts when you turn on or reboot your Android device. If you use FEAT VPN only occasionally, then you may not want to start the service automatically and ,instead, manually start it when needed using the previous setting.
Log Level. When you report a problem we may provide you with a log level string. This is a sequence of 18 letters that, when entered here, enables more detailed information about your problem to be logged in the FEAT VPN log.
Open Native Client. This setting is only available on Android tablets. If this is enabled, then FEAT VPN automatically brings up the built-in L2TP client on launch. So, you start FEAT VPN from the Android launcher, FEAT VPN comes up and instantaneously opens the built-in L2TP client, which then allows you to establish a VPN connection. This essentially saves you one click. Otherwise you would start FEAT VPN and then push the Connect button on the main screen to bring up the built-in L2TP client.
This section offers step-by-step instructions for using FEAT VPN with a few VPN service providers. This involves downloading your VPN configuration from the VPN service, possibly modifying it a little, and loading the VPN configuration into FEAT VPN.
Update: We used to provide HMA configuration files for FEAT VPN here in this section. This is not necessary any longer. HMA now uses configuration files that can be loaded into FEAT VPN unmodified.
Just follow the following four simple steps to get up and running with HMA.
HMA has illustrated step-by-step instructions for using FEAT VPN with their VPN service on their website: http://wiki.hidemyass.com/Tutorials:FeatVPN_OpenVPN_on_Android
The guys at ibVPN provide configuration files that make using their VPN service with FEAT VPN a breeze. Thanks, guys!
Here's how to use them.
iVPN.net offers VPN configurations and instructions specifically for FEAT VPN, which makes using iVPN.net with FEAT VPN a breeze. Thanks, guys!
Here's how to connect to iVPN.net.
Super VPN offers VPN configuration files that are compatible with FEAT VPN. They also provide illustrated instructions on how to set FEAT VPN up for use with their service, which makes using Super VPN with FEAT VPN a breeze. Thanks, guys!
Please take a look at their blog for more information.
The guys behind VyprVPN provide VPN configuration files that work well with FEAT VPN along with instructions for setting up the FEAT VPN app for use with VyprVPN. This makes FEAT VPN connect to the VyprVPN service after a few simple steps. Thanks, guys, for making this available!