I’m beyond thrilled to get to write this blog post announcing the release of Enclave Gateway! This is a big addition to the Enclave platform, and unlocks all sorts of interesting use-cases that extend Enclave’s support further into the IoT, cloud access and cloud migration space.
With Enclave Gateway, you can configure a deployed Enclave Agent on any Linux system to provide a “Gateway” to any local or reachable subnet, including the entire internet. You can then define a “Gateway Access Policy” that enables any system running the Enclave Agent to use your Gateway, meaning that system will be able to reach IP addresses on the exposed subnet.
Let’s get into this a little more, look at what we can use Enclave Gateway to achieve, and how we switch it on!
No idea what Enclave is? We create zero-fuss, zero-trust network connectivity between systems anywhere on the internet, without opening any of your firewalls, adding edge devices, or changing your infrastructure. You can start a free trial at https://enclave.io.
Where We Were
Prior to Enclave, how did we provide access to the office network from home? You may have deployed a VPN device on your network edge…
As we’ve said before, this is something of a liability. Having an edge device with an accessible public IP leaves you open to phishing attacks, DDOS attacks, and is generally a bad idea.
Now, with Enclave, you deploy our agent on any system that can run it (which is a pretty long list). Then any other system in your organisation that also runs the agent can connect to it, without that pesky edge device.
That solves our access to our Windows or Linux database server, but what about our old mainframe and our printer? We can’t run the Enclave Agent there…
Gateway
With Enclave Gateway, deploy the normal Enclave Agent onto any Linux device in your network as normal. This could be on a VM, a Raspberry Pi, or basically anything that can run Linux and has a network connection. Once you’ve done this, indicate in our portal that it can be used to provide access to one or more subnets.
We will automatically discover any private subnets directly connected to the device. You can also add any subnet reachable from the device, including the entire internet with
0.0.0.0/0… (more on that later).
Now, Enclave is default-deny across the board, right? That’s part of its design. So simply allowing a system to be a gateway doesn’t actually create any connectivity.
As with our existing “direct” connectivity, gateway connectivity must be defined in a policy before it can take effect.
Gateway Access Policies can be created and managed from the same policies page you’re used to. When you create a new policy, simply choose the new policy type.
The new policy type works slightly differently to the default “direct” policies. For direct policies you specify sender and receiver tags (such as ‘developers’ and ‘db-server’) to build direct connectivity.
With gateway policies, you define sender tags, and receiver subnets, via one or more gateways.
Once the above policy takes effect, any enrolled systems tagged with the ‘developers’ tag in that screenshot will automatically be able to reach any devices in the destination subnet by the actual IP address of the device you want to reach.
So, Dave can reach his mainframe now…
Further Restricting Access
From within a Gateway Access Policy, once you’ve defined the subnet(s) you want to provide access to, you can also further restrict the policy to a subset of the network available via the gateway, all the way down to a single IP address. So you can define a policy that only allows access to the printer (for example).
All the existing trust requirement features can also be applied to gateway policies, so you can require user login to be able to connect to a specific device IP, or indicate that you can only reach the office network if your device is located in the UK.
Using Enclave as an Internet Gateway
I briefly hinted earlier about Enclave supporting access to 0.0.0.0/0. Specifying that a gateway provides access to this network means Enclave can route all internet traffic for connected systems. This allows us to route traffic to cloud services via the company network (or any gateway device).
This lets you apply restrictions in your cloud services (for example, Conditional Access Policies for Office365) that mean users can only login when connected via the Enclave Gateway.
Support
If you have any questions/issues with the new features, please head over to our community forums at community.enclave.io or join us on Slack at https:/enclave.io/slack.
Happy networking!