TunnelHound

Four reasons why business VPNs are still a necessity

2020-12-17T00:00:00+00:00

The IT buzzword of the day in Silicon Valley is zero-trust networking, which refers to a model of corporate network security where services are exposed directly to the web, and each secured individually against outside attackers. Having gained notoriety for their use at large corporations, such as Google, it may seem like the noble VPN will soon find itself relegated to the junk heap.

However, we think that VPNs will still be necessary for most businesses, including yours. Here’s why.

1. Not all services can be accessed over the internet

Google uses SSH, etc. Many businesses need more complicated protocols such as RDP, etc, which are blocked on public networks.

This is also why you need to make sure your VPN solution can ensure connectivity, even in challenging network environments. For example, TunnelHound can maintain connectivity, even when only insecure HTTP access is allowed.

2. You’re stuck using legacy services

Large companies can bully their software vendors into adopting new features that allow their services to be exposed directly to the internet, or to build their own solution. Most companies cannot, and are stuck relying on software that cannot be easily changed. A VPN and firewall provides the perfect means to secure these services while still allowing remote access.

3. Ensuring connectivity wherever your business goes

As your business expands, chances are your employees will end up traveling to places you may not have expected, including countries that may limit their connectivity. VPNs provide an easy means around this. By allowing an easy way for your employees to navigate their internet traffic through your company’s routers, you can provide an easy means for your employees to get around this when meeting prospects in foreign jurisdictions.

4. Monitoring and compliance

If your business is involved in certain industries, it may be necessary to meet certain compliance requirements to maintain best practices. VPNs provide a way to centralize these policies so that you remain compliant, instead of leaving it up to chance. By allowing IT administrators to remotely configure how employee internet traffic is routed, a VPN makes sure that data in motion remains compliant with relevant laws and industry requirements.

Conclusion

Why NFTables is better than IPTables, and how to switch

2020-12-04T00:00:00+00:00

If you’ve spent much time around the Linux networking stack, chances are you’ve heard of IPTables. If you haven’t, IPTables is the framework that decides what to do with incoming network packets. It can be used to set up everything from simple firewalls up until complicated stateful routers and NATs. First released in 1998, this venerable software package has powered many networks for a venerable two decades.

TunnelHound does lots of routing. IPTables would have been the easy, obvious choice for constructing the TunnelHound state machine. However, like a lot of legacy software, IPTables has its limits that can make it difficult to scale to the kinds of routing problems many organizations face today. In 2014, a new filtering package NFTables was merged into the Linux kernel meant to fix some of these limits. Six years later, it’s safe to say that NFTables is the future of packet filtering. Here’s what you need to know and why you ought to switch.

Differences between IPTables and NFTables

Before we start on the differences between NFTables and IPTables, it’s worth pointing out the two are more similar than different. Both perform the same basic task – filtering packets that arrive at a Linux host and deciding what to do with it. Both frameworks offer CLI tools to interact with the framework (iptables for IPTables and nft for NFTables). As they say, the differences are in the details, and, as we’ll see, these differences matter a lot when it comes to building performant and scalable filtering applications.

Difference 1: Syntax

IPTables offers a basic command-line interface to interact with the kernel. Rules are created by calling the iptables command using a getopt_long() based parser.

NFTables also allows you to specify rules on the command line, but with its own custom EDSL instead. This makes rule specifications more concise.

Here’s an example IPTables based rule to drop any packets coming in on port 80.

iptables -A INPUT -p tcp --destination-port 80 -j DROP

Here’s the corresponding NFTables rule.

nft add rule inet firewall filter tcp dport 80 drop

Some of these syntactic changes allow you to significantly reduce complexity. For example, suppose you want to disallow TCP ports for SSH, HTTP, and HTTPS. In IPTables, this would require you to make three separate rules ¹. In NFTables, you can specify values as sets. This is not shorthand for creating multiple rules. Rather it creates one rule with multiple disjoint matchers.

nft add rule inet firewall filter tcp dport '{80, 443, 22}' drop

As another added bonus, you can specify multiple actions in the same rule. This functionality is much more difficult than in IPTables and would require you to make another table and add a JUMP action. For example, to both drop and count the dropped packets. For example, to accept traffic from IP network 1.2.3.0/24 on port 25, count the number of packets received, and log new connections, you can add one simple rule.

nft add rule inet firewall \
  filter ip saddr 1.2.3.0/24 tcp dport 25 \
         counter \ # Count all packets arriving at port 25
         accept  \ # Accept the packet too
         counter ct state new \ # When the connection is new
           log prefix "New SMTP connection" accept # Log it

In the rule above, there are three actions: counter, accept, and log. The rule is evaluated left-to-right, so all packets from the given source address to TCP port 25 trigger the counter and accept rules, which count the packet and accept it, respectively. The latter part of the rule only matches packets that represent new connections. If the connection is new, then the packet is logged as well.

Difference 2: Complexity

NFTables is a lot simpler than IPTables. Whereas IPTables comes with many different table sets, one for each protocol (iptables, ip6tables, arptables, ebtables, etc), NFTables has no built-in tables. A major performance bottlenecks with IPTables was that executing rulesets for empty tables actually took up a surprisingly large (read: non-zero) amount of time. This means that simply loading IPTables in the kernel could slow down your networking stack.

NFTables on the other hand has no built-in tables. Instead, tables are constructed by the administrator, and then “hooked” into various parts of the networking stack. For example, in the command-line above, we blocked incoming TCP connections on port 80 by adding a rule to the INPUT table, which is a pre-defined table provided by IPTables. The nft command-line above assumed we have a chain named filter in the firewall table of the inet “family”. By itself, this table and chain won’t do anything. It has to be added as a hook into the input part of the networking stack.

For example, to add the tables above, we have to run the following nft commands.

nft 'add table inet firewall'
nft 'add chain inet firewall filter { type filter hook input priority 0; }`

The hook part says that this chain is a filter type chain will be called whenever an input packet arrives. The best part is that before you add this chain, no extra execution time is spent in the kernel when processing input packets.

Difference 4: Efficiency

In IPTables, the rule set is maintained as a binary blob. This blob gets read from the kernel, manipulated, and written back atomically every time you invoke the iptables command. If changing rules often, this can be a problem, because the time complexity scales linearly with the size of the rules. NFTables uses a linked-list based approach to store rules, so inserting and deleting new rules takes constant time.

Difference 5: Upgrades

In IPTables, each rule was a representation of functionality provided by the kernel. For example, the iptables rule above to match incoming traffic on port 80 was translated into a kernel object representing the rule “Match TCP traffic on port 80.” NFTables takes a much lower-level approach. Instead of providing rules to the kernel, NFTables rules are compiled into a bytecode format which can match on any field in the packet headers. This means that rule functionality is actually determined in userspace. The corresponding NFTables rule above would be translated into bytecode that said something like “examine the 16-bit field at offset XXX in the header and match if it is 80 in network byte order,” where XXX is the offset of the destination port in the combined TCP/IP header. This may seem more complex, but actually it simplifies things quite a bit.

Most importantly, in IPTables, if you wanted access to a new rule type, this would often require a kernel upgrade. Although your iptables command may support a rule, if your kernel version didn’t match, you would be unable to use it. This could be a major problem for some implementations because distributions often ship a several year-old kernel for stability reasons. You were stuck with the choice to accept a potentially unstable kernel you had to build yourself, or to resign to not using the new features.

With NFTables, however, this problem is gone. Simply updating the nftables package is enough to give you access to the latest features. This is good news to system administrators: kernel upgrades necessitate downtime, or significant planning, whereas userspace changes are much more easily accomplished.

Difference 6: IPv4 and IPv6 interoperability

In IPTables, rules for IPv4 and IPv6 had to be specified using two separate commands iptables and ip6tables. NFTables lets you use the pseudo inet protocol to write rules that correspond to either protocol. For example, the nft command:

nft add rule inet firewall filter tcp dport '{80, 443, 22}' drop

Drops TCP traffic on the given ports for both IPv4 and IPv6. To write a rule specific to one protocol, you can specify either protocol specifically.

nft add rule ip firewall filter tcp dport 80 drop

would only block HTTP traffic on IPv4.

nft add rule ip6 firewall filter tcp dport 443 drop

would correspondingly block HTTPS traffic on IPv6 only.

Difference 7: Sets

Suppose you wanted to create an automatic IP blacklisting service (like fail2ban) using IPTables. Every time you wanted to ban an IP, you would add another rule:

iptables -A INPUT -s banned.ip -j DROP

Because of the efficiency problems identified above, for large public-facing services, this banning procedure takes longer and longer the more addresses you add. Moreover, the networking performance degrades as more rules are added to the rule set ².

As stated above, NFTables allows O(1) rule insertion, but if that were all, it would still suffer from the linear-scaling rule execution time.

Fortunately, NFTables provides sets, a typed collection of objects. Because sets are based on hash tables, they add little overhead to our rules. We began to approach sets above when we specified filters that matched more than one port. For example, in the command

nft add rule inet firewall filter tcp dport '{80, 443, 22}' drop

the part in braces represents an anonymous set representing three ports. NFTables adds the ability to name sets, and then add and remove elements of sets at runtime.

For example, to add a set named blacklisted_ips that can contain IP addresses,

nft 'add set ip firewall blacklisted_ip4s { type ipv4_addr; }'

Now, we can add a rule to block any IP in the named set.

nft add rule ip firewall filter ip saddr @blacklisted_ip4s drop

Upon set creation above, the set is empty. Instead of adding a new rule whenever our service wanted to block an IP, we can now add elements to the set.

nft add element ip firewall blacklisted_ip4s 44.92.123.21, 123.231.132.213

Or remove them:

nft delete element ip firewall blacklisted_ip4s 44.92.123.21

No more linear scaling for repeated rules! NFTables rocks for scalability.

Difference 8: Maps!

If that were not amazing enough, NFTables extends sets yet again by supporting mappings. For example, suppose you wanted to build a public-facing endpoint that internally routed traffic to different hosts (with only internal addresses) based on the TCP port. Suppose your HTTP server is at address 192.168.1.100 and your SSH server at 192.168.1.102 in your private address space. In IPTables, you’d again have to write two separate rules for this source NAT. In NFTables, you can just write a mapping (below, we’ve assumed you’ve created and hooked up the appropriate tables and chains for NAT).

nft add rule ip nat prerouting dnat tcp dport { 80: 192.168.1.100, 22: 192.168.1.102 }

Just like sets, we can even create named maps, and then modify elements at runtime. This would allow you to set up a rule like the above where you can change the address for each port at runtime (for example, when bringing hosts up and down).

nft 'add map ip nat porttoip { type inet_service: ipv4_addr; }'
nft 'add element ip nat porttoip { 80: 192.168.1.100 }'
nft 'add rule ip nat postrouting dnat tcp dport @porttoip'

Switching to NFTables

Most major distributions have support for NFTables. Some, like Debian, use NFTables by default already. Here are guides for various distributions:

Ubuntu
Arch
Debian – default packet filtering framework starting from Buster
Gentoo
Fedora – already installed by default

The xtables-translate commands let you translate iptables/ip6tables/ebtables/etc rules into nft’s accepted format. Here’s an example from the NFTables wiki:

> iptables-translate -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
nft add rule ip filter INPUT tcp dport 22 ct state new counter accept

> ip6tables-translate -A FORWARD -i eth0 -o eth3 -p udp -m multiport --dports 111,222 -j ACCEPT
nft add rule ip6 filter FORWARD iifname eth0 oifname eth3 meta l4proto udp udp dport { 111,222} counter accept

If you have an existing iptables ruleset installed, you can translate the entire ruleset:

> iptables-save > rules.txt # Save all iptables rules to a file
> iptables-restore-translate -f rules.txt # Translate all rules in the file to nftables

Note that if you decide to switch to nftables it’s best to purge your iptables rules and unload the kernel module. Using both frameworks is possible, but can lead to strange bugs. You can use iptables -X to delete all non-default chains, and iptables -F to reset all chains. Then unload iptables by using modprobe -r iptables.

Conclusion

NFTables is the new kid on the block, with significant advantages over IPTables for packet filtering. What it lacks in years is more than made up for by the extended functionality, the ease of use, and the independence from the underlying kernel. Nevertheless, many users haven’t yet made the switch. We hope that this guide has inspired you to take NFTables for a spin!

More information

We only touched the surface of what NFTables is capable of in this post. Over the next few months, we’ll be posting more about how we use NFTables to enable certain features in TunnelHound. In the meantime, you can browse NFTables’s extensive documentation³.

We’d like to know what you think of NFTables? Questions? Are there advantages of IPTables we didn’t mention? Let us know on social media or reach out to us.

Unless you use the multiport matcher, but that’s limited to fifteen ports. Moreover, NFTables lets you do this with any kind of parameter, not just ports. For example, you can only accept certain ICMP requests:
```
nft 'add rule inet firewall ip protocol icmp icmp type {echo-request, redirect} accept'
nft 'add rule inet firewall ip protocol icmp drop
```
This example drops all ICMP packet types unless they are pings (echo-request) or port redirects (redirect). ↩
This is because IPTables processes rules in order. The more rules in the ruleset, the longer the filtering will take ↩
Some cool features we have not even mentioned are concatenations, which extend maps even further; intervals, which simplify adding multiple elements to sets and maps; and stateful objects, which let you build more sophisticated counters and quota systems. ↩

Setting up a WireGuard VPN on Amazon EC2 to access a private VPC

2020-11-28T00:00:00+00:00

These days, many businesses choose to host their entire infrastructure on a cloud provider, like Amazon. This has a number of benefits, such as the ability to quickly scale up or down or reductions in initial capex. One of the difficulties with cloud environments is offering secured access to private cloud resource with VPNs. The native cloud solutions, like Amazon VPN, can be costly. For example, running an Amazon Client VPN costs $0.15/hr and then an additional $0.05/hr for every client connected. For a small company with four employees connected 8 hours every weekday, this can add up to almost 200 / month. If your employees keep their laptops on all day, costs can quickly escalate to several hundreds of dollars a month. That’s not to mention bandwidth costs.

The main way around this is to set up an EC2 server as a VPN gateway. There are a few options here, such as OpenVPN, but the latest entrant into the arena is WireGuard®, a Linux native VPN, that is easy to set up, fast, and cryptographically secure.

Unfortunately, WireGuard can be a bit of a pain to set up properly, and unlike more established players such as OpenVPN, it can be difficult to integrate into a cloud environment without developing custom solutions.

In this HOWTO, we’ll go through the steps of setting up an Amazon VPC (virtual private cloud) and then securing external access to private resources by setting up a WireGuard gateway. We’ll create the following network topology:

The two hosts are named Host A and Host B. Host B will only have a private IP and be inaccessible from the internet. Host A will have both a public and private IP, but will not be accessible via SSH except through the private IP address. Finally, Host C will serve as a WireGuard gateway and offer configured clients the ability to connect to Host A or B via the private IP.

In order to simplify set up and offer an easy management portal to network administrators and a self-service portal to network users, we’ll use TunnelHound, a WireGuard portal software that comes with pre-built Amazon AMIs and Docker images.

Let’s get started!

Requirements

To get started with this HOWTO, you will need the following:

An Amazon Web Services account
Access to the AWS web console

Creating a VPC

The first step in creating the topology above is to create an Amazon VPC. Our VPC will exist in the 172.16.0.0/20, which provides 4094 addresses and up to 4096 distinct subnets.

We’ll assign subnets 172.16.0.0/24 and 172.16.1.0/24 to the private hosts in the Amazon cloud. Subnet 172.16.2.0/24 will be assigned to VPN clients. This provides 253 private host addresses and 253 VPN addresses (one is consumed by the WireGuard gateway on each subnet).

To create an Amazon VPC, navigate to the Amazon VPC console. Take note of the region in the upper right hand corner to make sure all resources are created in the proper Amazon region.

To create the VPC, click on the VPC link on the console.

Then, click on the orange Create VPC button in the upper right-hand corner. This will bring up the following page.

Fill in the details as follows:

Name tag – Any name is fine here
IPv4 CIDR block – Type in 172.16.0.0/20 here, which is the CIDR block of the private network we’re creating.
IPv6 CIDR block – Leave this blank for now. You can add IPv6 support into this VPC if you’d like, but TunnelHound currently doesn’t work with IPv6
Tenancy – Don’t change this

Now click the Create VPC button

Creating the subnets

Our VPC will consist of two subnets. First, the subnet 172.16.0.0/24 which is for our private hosts running on Amazon EC2. Secondly, subnet 172.16.1.0/24 will be for our EC2 hosts that need both public and private addresses. Finally, 172.16.1.0/24 will be for our client connections.

Since only the 172.16.0.0/24 and 172.16.1.0/24 subnets will contain Amazon resources, we’ll only need to create an AWS subnet for this subnet. The other subnet will be managed by a route in our Amazon VPC that will direct all traffic to the WireGuard gateway.

To create the private subnet, click the Subnets link in the Amazon VPC console sidebar.

Then click the Create Subnet button. In the subsequent form, choose the VPC you just created in the step above.

Create the first subnet by filling in the form as follows:

The, create the second subnet, by clicking the Add new subnet button. Then, add the details for the second public subnet.

Fill in the following details, then click Create subnet.

Adding an internet gateway

At this point, our network exists, but cannot access the internet. To access the internet from a VPC, we need an internet gateway.

We can create an internet gateway, by navigating to the Internet Gateways console from the Amazon VPC navigation bar at the left. Click the Create internet gateway button, choose a name for the gateway, and save the gateway. Now, attach the gateway to the VPC created above, by clicking on the Actions dropdown, and selecting Attach to VPC. In the selection box, type in the VPC ID of the VPC created above. Then click the button to attach the gateway.

Route Table setup

Now we’ll set up the routing table for our VPC. Again, navigate to the Route Tables console on the Amazon VPC navigation bar at the left of the page. There will be a routing table already associated with your VPC which you can find by filtering the list for your VPC id.

Go to the Subnet Associations tab, and click Edit Subnet Associations. Choose both the subnets you configured above, and click Save.

Now, in the Routes tab, we’ll need to direct all internet traffic to the internet gateway. Click the Edit Routes button, and then the Add Route button. In the Destination box, enter 0.0.0.0/0. In the Target selection box, first choose Internet gateway, then select the gateway created above. Click Save Routes to propagate the route information.

Creating the hosts

Now, it’s time to create Host A and B. We’ll be using an Amazon Linux AMI for these hosts. Navigate to the EC2 dashboard. Then, choose Launch instance to start the Launch instance wizard.

Choose the Amazon Linux machine image, which is usually at the top of the AMI list. Choose an appropriate instance size. For this tutorial, t2.nano is probably appropriate.

In the Configure Instance tab, choose the VPC we created above (you can search it by name). Choose the public subnet and make sure you have asked for a public IP to be assigned to the instance.

In the Add Tags tab, you can tag this image with the name Host A.

In the Configure Security Group tab, create a new security group and grant SSH access via the internal subnet.

You can now click Review and Launch make sure to choose an SSH key you have access to.

Now, for Host B, choose the same as Host A, except place Host B in the private subnet we configured above and do not ask for a public IP. Re-use the security group above.

Setting up WireGuard and connecting via SSH

If you notice now, you can’t SSH into either Host A or Host B. This is because SSH is only allowed for connections coming from the private VPC network, which your computer is not on. We’ll now set up a TunnelHound instance to secure external traffic into the internal network.

Launching the TunnelHound service

TunnelHound provides pre-built AMIs available in most AWS regions. To launch a TunnelHound instance, select the appropriate AMI from the list here. Click the Launch AMI… link next to the appropriate region to automatically be redirected to the launch instance wizard.

Setup for the VPN appliance is basically the same as Host A, but with some differences.

Firstly, you’ll need to create a new security group for the TunnelHound host because it will need to be publicly accessible via WireGuard. WireGuard runs on any UDP port, but for this example, we’ll choose 51821. Also make sure to enable ports 443 and 80, which is required to configure the TunnelHound appliance. These ports can be left open.

For instance type, choose t2.micro or t2.nano. In general, your VPN host needs to be appropriately scaled based on the expected number of concurrent connections, but for most small networks, a t2.micro or t2.nano instance is appropriate.

In the Configure Instance tab, choose the VPC and public subnet configured above and again, make sure to request a public IP.

In the Configure Security Group tab, enable SSH access via the internal VPC and then enable UDP access on port 51821 to anywhere. This port is secured via WireGuard, so it is safe to expose publicly.

Now, launch the instance. When the confirmation page appears, click on the instance ID as shown below to be taken to the instance details page.

You will now be taken to a listing table containin your instance. Note the public IP address for your instance. Once the instance state changes to Running, navigate to https://<your ip address>. You may need to wait a few minutes or re-attempt to connect in order to wait for the appliance to finish booting.

You’ll likely meet a page now that the certificate authority is invalid. TunnelHound uses a self-signed certificate to secure communications between clients and the server. This is good enough for now, but in production, you’ll likely want to set up Let’s Encrypt or a custom certificate.

Accept the ‘invalid’ certificate to begin the TunnelHound setup. You’ll now be taken to the TunnelHound setup wizard. The first step is to create an administration account. Enter your name, e-mail, and a password. Then click Next to set up the administrator.

You can skip the e-mail configuration. This is only necessary for multi-user setups. You can also skip the license setup. Out of the box, TunnelHound supports up to six devices and three separate users. You’ll have to pay for more users by purchasing a license.

Click through the remaining parts of the wizard, to be taken to the TunnelHound dashboard:

Setting up the endpoint

To create a VPN, we’ll need to set up an endpoint. Click the Admin menu, and then the Endpoints item.

Then, click the Add Endpoint button, and fill in the form as shown below:

Now, navigate back to the TunnelHound dashboard, and click the Add Device button. Fill in the form as shown below:

Click Add Device to set up the device.

Setting up your device

You’ll now see a dialog containing instructions on how to set up your device. We’ll be following the generic Linux instructions. You’ll need to make sure your computer is set up for WireGuard and has the wg-quick command installed.

First, download the configuration file. Then, place it in your home directory, and rename it to <interface>.conf, where <interface> is the name of the local WireGuard interface you want to create. Something like wg0.conf is probably good enough. Then run,

sudo wg-quick up wg0.ini

Congratulations! You’re now connected to the VPN. If you now navigate to the private IP address of the TunnelHound instance, you should be able to log in.

SSHing into Hosts A and B

You can now SSH directly into Host A or B using their private ip.

ssh -i <path/to/id.pem> ec2-user@<host.a.or.b.ip>

For us, Host B, which is contained completely in the private subnet, has IP 172.16.0.125.

You can similarly, log in to Host A. To confirm that it’s working, try bringing down the interface by running

sudo wg-quick down wg0

Now, if you try SSHing again, you’ll notice that traffic no longer flows.

Going further

You can now use AWS security groups to configure your hosts – even your public ones – to only offer certain services on your internal network. Using TunnelHound, you can invite users to join your VPN and let them manage their own access. Administrators can delete devices, revoke credentials, and manage access all from one convenient internal dashboard. Larger deployments can purchase a TunnelHound license to increase usage limits and get priority support.

That’s it! In a few easy minutes, we were able to set up a simple VPN to protect our private cloud resources. We used TunnelHound to provide a WireGuard® compatible VPN and Amazon EC2 and VPC to provide isolated cloud computing resources. For more information, see the TunnelHound documentation.

Introducing TunnelHound

2020-10-12T00:00:00+00:00

Setting up a WireGuard® VPN used to involve sorting through endless manual pages, messing around with error-prone configuration, crossing your fingers, and lots of swearing. But no more! Introducing TunnelHound, the first commercial provisioning server for WireGuard®. Set up a WireGuard® VPN in minutes, with support for SAML SSO auto-provisioning, user self-service, mandatory expirations, diagnostics, etc.

What is WireGuard®?

WireGuard® is the easiest to use, secure, maximally awesome VPN solution on the planet. But don’t just take our word for it. Here’s what Linus Torvalds, the author of the Linux kernel has to say about it:

Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn’t perfect, but I’ve skimmed it, and compared to the horrors that are OpenVPN and IPSec, it’s a work of art.

What is TunnelHound?

TunnelHound is a commercial provisioning server for WireGuard. That means that it helps you:

Set up a WireGuard cloud VPN
Provide secure access to your business network to your employees, contractors, and other agents
Allow users to administer their own WireGuard keys and devices
Set up Linux IP routing for access control, throttling, and logging

Why TunnelHound v vanilla WireGuard®?

TunnelHound offers a number of advantages to using WireGuard directly:

Simplified deployment – No need to mess around with configuration files
User self-service – Let your users administer their own devices. Simplify your IT workload by letting users perform most common tasks
Secure peer creation – The user self-service portal means that administrators never have to deal with creating private keys. Your server only ever sees the public key.
Automatic integration – TunnelHound lets your organization’s users sign in automatically via SAML, thus removing the need to manually create users (available in enterprise plans only)
Polished user experience – Your web designer probably doesn’t want to futz around with the command line. TunnelHound provides a modern, polished user experience with detailed instructions on how to set up VPN connections on all modern operating systems.
Automatic updates – Licensed TunnelHound appliances automatically update with little downtime
Commercial support – All licensed TunnelHound installations come with our Epic support! This means we’ll get back to your support inquiry within 24 hours. Enterprise plans come with phone support, for additional peace of mind.

How do I get TunnelHound?

You can get TunnelHound on almost any Linux device via Docker or directly on Amazon AWS as an AMI.