We have identified an issue with the new NDIS6 compatible TAP driver that is being installed with the latest version of OpenVPN. The issue causes very slow DNS resolution through the VPN service, which makes it so that pages take a very long time to load, or fail to load completely.
The NDIS6 TAP driver is bundled with the "I006" versions of OpenVPN. The driver was updated to fix some long-standing stability issues with Windows 8 and Windows 8.1.
If you are having this issue in Windows Vista, 7, or 8, we recommend that you uninstall the I006 version and install the I003 version that contains the older TAP drivers. This appears to fully resolve the issue.
As was the case before, if you are using the I003 version of the TAP driver with Windows 8 or 8.1, you have to be extremely careful and restart your machine before each time you sign on to the service. This is because Windows improperly handles the older TAP driver and it enters an error state where it doesn't initialize properly.> read more
We are currently investigating a problem with Google DNS that is causing long hangs for users when they are resolving domain names (when you first visit a site by entering the URL in the address bar, it is slow).
We will be issuing a rolling restart of all clusters to resolve the issue by pushing a different DNS server to our customers.
Downtime for each cluster should be less than 1 second. You may need to reconnect to the service is your client fails to auto-resume after the restart of the cluster.
I will update this post when the process is completed.
Update1: The Chicago cluster has been switched to a new set of DNS servers. Performance should now be back to normal for all users on that cluster.
Update2: The Phoenix cluster has been switched to a new set of DNS servers. Performance should now be back to normal for all users on that cluster.
Update3: The New York City cluster has been switched to a new set of DNS servers. Performance should now be back to normal for all users on that cluster.> read more
OpenVPN for Windows has received a minor update that fixes some OpenSSL vulnerabilities (that do not impact VikingVPN).
The update includes a new Windows TAP driver that is supposed to have better support for the updated standards for NDIS6 and the current Windows 8 network stack. The new TAP driver has been in beta testing for quite some time and now is in the official client as most of the crash bugs have been worked out.
We are currently evaluating the NDIS6 driver in Windows 8 and 8.1 in our labs to see if stability has been improved over the old drivers. As it is now, we have recommended that our users restart their Windows 8 devices every time they wish to connect to our service to prevent a critical bug where the old TAP driver would enter an error state and not function properly.
We are working on updating our connection guides to more current graphics, and revamping our videos to reflect the latest changes to the installation process for Tunnelblick and OpenVPN both.
Tunnelblick has streamlined the config file import process, removing a couple of steps from the process.
OpenVPN-GUI has been updated with new Icons, so we plan to update the videos and guides to avoid confusion with the different look of the app.> read more
We have completed the expansion of our Chicago network! This is a large scale expansion of our network in order to keep speeds high and continue our commitment to 99.999% uptime. "Five 9's" uptime allows us only around 15 minutes of downtime per year, per cluster.
This update is designed to be completely transparent to the user. You should only notice faster speeds while on the service and do not need to make any changes.
> read more
We are currently migrating our services away from our current provider due to unresolvable issues with the spam filters of our current mail system. Our new system will allow us more granular control of our email filters and also allow us to send out mass emails when needed (for emergencies only).
The migration is not expected to interrupt any services, including customer care.
We have implemented a small change to our configuration server and client side in order to resolve issues with OpenVPN Connect on iOS and Android devices.
The change makes it so that our service will not timeout during our extraordinarily strong 4096-bit handshake on a device with a slower processor. We use an extremely strong ephemeral RSA key in order to give our users the maximum amount of protection that is physically possible on most devices without serious performance problems.
The issue was that the OpenVPN Connect app has an undocumented change that makes it so that if connecting to a server takes too long, the app will timeout and not connect to the service.
For a lot of older phones (Galaxy S2, iPhone 3, etc) the handshake can take in excess of 30 seconds, causing the timeout and failure to connect.
There is new OpenSSL vulnerability notice circulating the web. It is known as the "crypto bypass" flaw. This flaw allows a man-in-the-middle attacker to decrypt information between a client and a server.
VikingVPN is immune to this attack because of our use of the HMAC firewall feature built into OpenVPN. It is not possible to establish a man-in-the-middle attack because the client and server both will drop all network traffic received from outside sources.
We have already updated our servers to close the flaw, but the impact to our users is nil. There will likely be another version of OpenVPN posted on the official site to close the vulnerability, as it uses an integrated OpenSSL 1.0.1 library that is vulnerable in certain configurations (again, not ours).
The updated version of the OpenVPN client will be located at: http://openvpn.net/index.php/download/community-downloads.html> read more
We are preparing a network expansion in Chicago to accommodate a surge in users connecting to that cluster. We will be expanding the capacity of the network by 50% in order to keep our strong lead in both speed and reliability.
Our network is evaluated constantly for slowdowns, and as a premium VPN service we watch user density closely to make sure that our users never experience speeds that we would ourselves find unacceptable.
The upgrade should be transparent to our user base and will be completed with no downtime.