VyprVPN Router Alpha setup instructions!


  • Cisco E4200 v1
  • Cisco E3200
  • Asus RT-N66U
  • Asus RT-AC66U

Please visit this URL to download setup instructions and VyprVPN Router Alpha firmware:


You will find a folder for each of the supported routers. Each folder contains:

  1. A PDF file with instructions.
  2. The firmware file (.bin or .trx).
  3. A checksum.txt file with an MD5 checksum of the firmware. It’s optional, but a good idea to validate the MD5 checksum: https://help.ubuntu.com/community/HowToMD5SUM. Thank you Ubuntu for an OS Agnostic page covering MD5 checksum validation!

It’s Alpha, Right?

Remember that this is alpha software, and there may be some bugs in your usage of it. We want to hear all of your experiences, good or bad. In the coming weeks we’re going to be working to improve debugging in general and fix a couple of outstanding, known issues, including:

  • Debugging: Incorporating our standard “Contact Support” functionality into the VyprVPN application on the Router so you can easily send us logfiles for debug purposes.
  • Debugging: Switching our application logging to be compatible with syslog so you can log things onto a local PC for ease of access/troubleshooting the hard things.
  • Debugging: Investigate enabling crash dumps so when a process dies unexpectedly, we can get debug information out of the crash.
  • Known Bug: Router goes non-responsive. One of our internal alpha testers reported this problem, a reboot fixes the issue. (Troubleshooting in progress.)
  • Known Bug: After waking my device from sleep, it cannot access the Internet until I reconnect the VyprVPN connection. Rebooting the router also fixes the issue, but it’s more than you need to do. (Troubleshooting in progress.)


Let us know how it goes. This is the tip of the iceberg of what we’re going to do in the router space, and we’re interested in any feedback you have. In the coming days I’ll be putting together a public FAQ for the VyprVPN Router Alpha – I already have some Questions I know we’ll be seeing, and we’ve got some answers. We didn’t want to stall getting the firmware in your hands for that.

If something goes wrong please make a post here in the forum. You can contact support – but know that they’re going to be a bit slower on helping with these issues as they will be working hand-in-hand with the router development team. If you need to send logfiles, other information of a sensitive nature, or are just uncomfortable using a public forum for support, please use support@goldenfrog.com instead.

Good luck, and enjoy!
Michael (MikeDoug) Douglass

On March 21st, Firmware and Application v0.5 were officially released!

You should receive notification within your routers for a VyprVPN firmware update to v0.5.  Please use the update process to upgrade.  Should you have any problems, 0.5 is also available at the download site: https://truck.it/p/0weTKggQAb

VyprVPN Firmware 0.5:

  • Caught up with the latest Shibby Tomato changes (lots of changes here!)
  • Application download script updates status file atomically

VyprVPN Application 0.5:

  • Contact Support page
  • Improved analytics information
  • Fix SSL socket handling to timeout bad connections properly

It feels like an eternity since I’ve been up here with an update for you all, but I’m finally back and we’ve got some good stuff for you.

In the interface you should be informed that VyprVPN Application 0.5.1 is now available. Please use this interface to perform an upgrade of the application and let me know any feedback you have on that process. IF anything goes wrong please reboot your router – when you reboot you will automatically retrieve the 0.5.1 application.

VyprVPN Application 0.5.1:

  • Contact Support page now functions when logged out (requires email address).
  • Upgrading or Installing the application informational screens no longer indicate a router reboot is underway.
  • Fixed firmware upgrade defect.
  • The Per Device VPN interface now retrieves hostnames more reliably.
  • Syslog support for Per Device VPN network configuration changes.

The last item is a very notable one – if you have been experiencing issues where your devices periodically stop working on the network, this is the debug information we need for that. We are essentially logging before we make any network configuration changes to support a per device item. In order for this debug information be effective, this is what we will need from you:

  1. Setup a free syslog server on your PC (there’s several including Kiwi for Windows) or use a Unix-like system with syslog already on it.
  2. Configure Tomato to forward all syslog entries to that device.
  3. Wait for the problem to happen.
  4. Send us the syslog along with as precise a description including when you noticed a machine not working on the network as well as the last time you know it was working.

That set of information will help us debug what is going on with the devices, and hopefully determine a fix for the issue. If needed, we can provide more detailed instructions for setting up a syslog server and configuring Tomato to do remote syslogging. As it stands, it sounds like the people with this problem currently have either set the syslog work up already, or are technically capable already.