Zero trust for remote worker

Introduction

Earlier this year, suddenly mandated remote work arrangements resulted quite often in reduced device security. Many companies were unable to purchase the number of laptops they needed quickly. Supply chains of computer equipment were broken, demand for laptops exceeded supply and reality often pushed us to allow usage of private computers of employees for work. When you tried to order 100 of Dell laptops in March 2020, you had to accept at least five months-long queueing time for deliveries.

At that moment, we quite quickly understood the challenge of securing our networking in a way that would still guarantee the same high, level of network trust between workstations and remote services as we had in the BC era (BC = Before Coronavirus). How are we going to do that?

We have several services running in an AWS public cloud account, which our developers need to have access to all the time. Our IT Ops staff also connect to our customer’s private data centers.

The very moment we asked our colleagues to stay at home and work from there, we needed to ensure the following:

1. Everyone has the right access to network resources needed to do the job required.
2. We do not accidentally open doors for unauthorized access to intruders.
3. We can easily manage (extend, revoke) access remotely.
4. Networking setup on employee’s laptops is relatively easy, so that non-technical staff doesn’t have to learn about the complexities of network setup.

Is VPN any good?

The natural, almost instinctive solution was to secure connection from our employees’ laptops to the company’s offices over our corporate VPN server. While working from home, with a VPN tunnel established, employees obtain an internal IP address from the pool of the company’s addresses just as if they were physically in the office. From there, all subsequent network communication is allowed to either Amazon AWS VPCs where we host back-office applications, development environments, and production applications for our clients. While routed through the company’s office network, our connections are also egressing using the company’s public IP addresses that are whitelisted for VPN access to selected client’s private data centers.

While corporate VPN connectivity, as illustrated in the above diagram, could work, it was less than ideal for what we expected from modern networking.

We had a few reservations about it:

• All network data transfers (including music streaming ) are routed through the corporate VPNs and unnecessary saturating bandwidth of the company’s broadband connections.
• VPN seems a bit too permissive. We may not be able to control what other software/malware/trojan is running on all employee’s laptops, and opening a VPN tunnel between their home networking environment and the company’s intranet can be risky. After all, you don’t want to provide a direct, fast-lane, trusted channel through all perimeter defenses if you cannot fully trust the client device.
• Performance issues: Is the network path from our laptops to servers in the cloud really optimal when it leads via the company’s office? We don’t think so.

NetFoundry to the rescue!

Gartner predicts that “…by 2023, 60% of enterprises will phase out most of their remote access virtual private networks (VPNs) in favor of ZTNA”. Could this be the right time to jump on the Zero Trust Network Access train?

We decided to test if ZTNA implementation by NetFoundry can help us replacing VPN.

Other than many advanced networking use-cases (IOT, multi-cloud, hybrid-cloud ), NetFoundry network fabric can be also used to support the “remote work” scenario we have been after. It seemed a great starting point in our journey into the world of software-defined networking.

In order to achieve that, we simply needed to install a NetFoundry client on employee’s laptops, NetFoundry gateway on networks to which access needs to be facilitated, and centrally (through “Management and Operations Platform” web console) define a service and an AppWAN that ties together the client, the gateway and the service.

With deployment like the one above, we were able to route network traffic from a remote employee to a target service very selectively. It can be referred to as networking micro-segmentation – an approach where access to a logical segment of a target network is fine-grained. When defining a NetFoundry’s Service, one can precisely narrow the scope of access to a particular combination of protocol, port, and address CIDR. We didn’t have such a precise tool with traditional corporate VPN, which usually opens access to a large network segment.

NetFoundry setup.

It’s well documented on their website and the configuration is quite straightforward. I want to mention two concepts that looked particularly interesting to me.

NF Gateway

For those of us who set up remote access entry points to any network (Bastion hosts, Masquerade NAT, VPN) it may seem intuitive that a server would need to have a public IP address to accept remote traffic. To my surprise, I found that NetFoundry gateway can be deployed into a private subnet. It doesn’t need to have a public IP address. Of course, it still needs to be able to egress, so the routing table must point to a functional NAT instance and the VPC must have an Internet Gateway associated with it, but the NF gateway itself doesn’t need to be directly addressable from the Internet.

The diagram below shows how you could deploy NetFoundry Gateway in a private subnet and use it for accessing services in other private subnets. I used the setup below for access to an elastic search service running inside a VPC in a private subnet. I liked the idea that the gateway can be “hidden” in a private subnet and I didn’t have to worry about hardening it and securing from potential attacks from the Intenet.

AppWAN

AppWAN defines which endpoints (any combination of virtual gateways, virtual machines, IoT devices, smartphones, laptops, etc.) have permission to access a given service or set of services (typically an application).

While the internal workings of route path selection, authorization, transfer node configurations can be complex, we’re presented with a very simple and intuitive configuration screen. We simply bind together who (clients), where (gateways) and what (services) are permitted to communicate together.

Summary

NetFoundry’s SDN helped us to replace many of the concerns we had when using VPNs. The most important win for us is much-improved security. Zero-Trust and Micro-Segmentation are definitely the way to go.

Another advantage is improved latency thanks to better protocols (UDP) and smarter path optimizations (no more redundant network paths via the corporate network). We no longer need to carry all traffic from home via corporate broadband connections and unnecessarily overload the VPN concentrator there.

Happy to have found NetFoundry!