Networking and Remote Access in Times of Confinement

Networking and Remote Access in Times of Confinement

At Interlink, we have a hybrid model of remote and physical-presence teams, so the COVID-19 pandemic called for us to garner the lessons learned by the remote team, and expand them into the rest of the company.

We have a mix of legacy and modern systems as well, which we need to access in order to efficiently do our jobs. At the onset of the Coronavirus pandemic, we happened to be evaluating alternatives to replace the legacy Virtual Private Networks (VPNs) we used to access on-premise servers from our clients.

The use of VPNs enable our developers and support agents to log into our customer's servers, as if they were on the same network as them (despite being in different countries, in some cases), and perform a series of tasks that deal with maintenance, issue-fixing, reporting, updates or new installations altogether.

With the global advent of virtualization, modern VPNs do not run as monolithic infrastructure, neither do corporate networks in general. We wanted to replace our now outdated approach, which had been serving the needs of existing customers well, but was not going to sustain our growth going forward.

Our code lives in several places, our people enjoy a wide array of mobile options, but we need to secure and protect them.

This meant we could also benefit from new protocols and security processes. But soon, countries worldwide started announcing COVID-19 containment measures, and companies started following by cancelling events, office hours, and anything requiring physical-presence. We acted fast and did the same with our people, they were to stop working from our offices immediately.

Our initial tests with Perimeter81, a virtual networking solution for corporate needs, were encouraging. With a couple of clicks, we had created our own network, with regionalized gateways in the US and France, and our own connection client to boot, courtesy of Perimeter81.

At one point we were able to see a noticeable drop in the speed of the connections, which worried us, but we continued adjusting other factors. The plan is to use it for a safe remote access to certain servers, and not for all instances where our people must access the Web.

The Perimeter81 people were very helpful in setting up videocalls and going over our network complexity, business rule needs and possible solutions to the different scenarios.

We quickly set up IPSec Tunnels with our servers and were able to access them, which gives us independence from whatever happens with the external factors of the office where our infrastructure is.

Perimeter81 enables smart networking in a plethora of distributed environments, with our own access policies and methods.

But suddenly, we were caught in the middle of validating this new approach and rolling it out to all our environments, with just about double the expected amount of users. Initially we were thinking only of technical users, but now with the new measures, we had to plan for all of our employees who would access company resources from their homes.

We had to move fast. We were considering different options but this changed our thinking towards general use-case security and remote access, not just development and support. We configured everything to protect the security of our data and our people, without compromising privacy rights.

In order to succeed, we needed to take into account different things, such as Identity Management (who are the users that get access to this and under what policies), Authentication Management (how can we create users and passwords per user, per server/application, and have the ability to change/revoke as needed), and Malware Detection.

Since we would be adding non-technical users to the remote access mix, we wanted to detect and block DNS requests that would be malicious in nature. While we do not believe in draconian restrictions, we had to consider the security of the company devices, now connected to personal Wi-Fi networks.

The surprise came when trying Cisco's Umbrella solution, which uses OpenDNS and proprietary services to enforce network security at the DNS level. After replacing the default ISP DNS from Orange, I saw a big difference in measuring the speed of my connection.

Cisco Umbrella resolves a lot of networking issues for us, while at the same time boosting our connection speeds.

It is a 500Mbps connection, but when measuring with Speedtest, I would only get values close to that figure if I would test directly at the router. At a single device connected wirelessly, I would normally obtain 200-300Mbps.

Testing has yielded positive conclusions for our core users, and now is being expanded to the rest. With Cisco Umbrella DNS we compensate for any speed reduction introduced by our virtual network perimeter.

Something distinct is happening by getting rid of Orange's DNS, and using Cisco Umbrella instead. My speeds are ranging 400-500+, my protection is comprehensive, and following company policies. It is truly a wild realization, and the browsing experience shows a big change since then.

What we did next was to set up custom DNS in our Perimeter81 network, and now we see speeds that are closer to what our connections would have been in a non-Cisco-Umbrella world.

This is the best of all worlds as we get different methods, for different use cases, and our people and data are protected wherever they work from.

We are now migrating the rest of our environments to the new networking structure and rules.