After more experiments and thought, I consider attempting to detect a valid internet connection before launching OpenVPN a bug rather than a feature. It should be removed, allowing OpenVPN to launch and fail or succeed on its own.
In addition, wget
is being launched to detect an internet connection by connecting to http://myip.com.tw/ every 10 seconds. This is being done in the background with no notification to the user of the device.
I can easily think of four use cases where detecting an internet connection before launching the OpenVPN client causes problems. I have experienced all of them.
Information Leaks
Because a wget
connection to http://myip.com.tw/ is made before launching the OpenVPN client, it is impossible to create an OpenVPN client connection without leaking information to that site, in the clear (it’s not an https connection), and open to all the hops in between. While I’m not overly sensitive to information leaks I’ve seen posts by others in this forum that are extremely sensitive to these leaks. Separate from the check for OpenVPN, because this is also done every 10 seconds, information is constantly being leaked.
Failure on Restrictive Networks
If the device is on a restrictive network that blocks this check, OpenVPN will never be allowed a chance to succeed because it is never launched. If the network blocks access to this site, blocks access to port 80, etc., this check fails. For example, if a network severely restricts outbound traffic and only allows it on port 22 this check fails, however OpenVPN should be allowed to proceed if the user was successfully able to set up an OpenVPN server on port 22 somewhere. Launch OpenVPN anyway and allow it to fail or succeed on its own.
Failure on Private Networks
This check makes using OpenVPN connectivity between sites with no internet access impossible. For example, if you have two networks (labs) each on different private subnets with no internet connectivity and you wish to connect them using these devices with OpenVPN you can’t do it because the Admin Panel is enforcing internet connectivity as a requirement before OpenVPN is launched. Again, launch OpenVPN and allow it to fail or succeed on its own.
Failure on IPv6-only Networks
The check is used to detect an IP address but only supports IPv4 addresses. If the device is on an IPv6-only network the check will fail because http://myip.com.tw is an IPv4 only site. Even if the site was IPv6 enabled the check would still fail because the grep
expression to which it is piped only checks for IPv4 addresses. Admittedly, a user will never see this situation because I have been unable to set this device up on an IPv6-only network anyway, but this is still a breaking point that must be remediated if you ever decide to make the Admin Panel useful on IPv6-only networks. Apparently this IPv6-only situation does happen and is something Microsoft wrote about less than 2 months ago. I sometimes use an internet connected IPv6-only network for testing.
Work-around
For anyone where these checks are causing a problem or you don’t want your information leaked, you can use the following script as a work-around. You may wish to use something more robust than this script but it will at least get you started. If you wish to monitor all the calls to wget
and how often they’re made, leave the logging enabled otherwise you may comment the logging out.
Rename /usr/bin/wget
to /usr/bin/wget-original
then drop this script into a file at /usr/bin/wget
and don’t forget to make it executable.
#!/bin/ash
EXTERNAL_IP=192.168.1.1
LOG_TAG=wget
echo "$@" | logger -t "$LOG_TAG"
echo "$@" | grep -e '^-t 2 -T 6.*http://myip.com.tw/$' > /dev/null
if [ $? -eq 0 ]; then
logger -t "$LOG_TAG" "Injecting fake IP $EXTERNAL_IP"
echo "$EXTERNAL_IP"
exit 0
fi
/usr/bin/wget-original "$@"
I used an MT300N-V2 on 3.005 (gl-mt300n-v2-3.005-1031.bin) for my testing.