1. Home   /  
    2. Trends   /  
  2. SDN for building corporate networking
SDN for building corporate networking

SDN for building corporate networking

Introduction

When your company runs multiple geographically dispersed offices, you are most likely faced with a requirement to ensure resources in one office branch are made available to other locations too. The resource you need to share may be as trivial as an internal web application your employees use for reporting timesheets, accessing a CRM system, or could be a shared network drive that is stored in the company’s primary office location. Regardless of the nature and purpose of a particular network resource, you have the right (and often an obligation) to guarantee that internal data exchange is transmitted over a secure and dedicated transmission channel. Historically, companies rented dedicated business lines from local ISPs. They also used VPN extensively to ensure point-to-point encryption. The emergence of SD-WAN made it possible to gain a bit more control over configurations. Still, it requires the presence of specialized, expensive network controllers in office branches to facilitate WANs. Can we go one step further and abstract away from highly specialized networking hardware equipment? Can we embrace SDN fully?

The Challenge

When building corporate WANs, we need to think carefully about several challenges ahead of us.

  • security: this is probably the most critical deciding factor when building corporate networks. You’re unlikely to choose any particular network type (Internet, WAN) unless connections are encrypted, and there is a sufficient level of privacy, data integrity, and authentication/authorization mechanism between endpoints. But while the need for data-in-motion encryption is obvious, you also need to think about device/endpoint security too. If workstations get compromised in one office branch through malware/trojans, will the potential back door become an open gateway to LANs of other office branches? You may partially rely on local device security applications (antivirus, website filtering). Still, with more and more businesses arranging for their employees’ remote work, the importance of concepts such as traffic Micro-Segmentation and ‘Zero Trust’ is on the rise.
  • dedicated vs public links: regional availability of broadband and its relatively low price makes it a decent candidate for use in building corporate WANs. However, It suffers from somewhat unpredictable latencies, and its security is simply non-existing. On the other hand, purchasing private circuits based on MPLS is often price-prohibitive; there is much less competition among network operators offering MPLS VPN solutions. Private circuits often offer better SLAs and the ability to configure QoS parameters for different classes of application workloads (VOIP, HTTP, FTP), but you will require additional on-premise hardware (CE routers) and are more experience some consequences of an MPLS provider lock-in: less resilience in case of ISP’s downtime and high costs of the net lease. Also, with many companies mandating ‘work from home’ policies and the role of office networks being re-defined, private circuits may be destined for extinction.
  • branch networking topology and the cloud: office branches can be connected in several different ways, most notably in a ‘hub-and-spoke’ topology where each regional branch is connected to the main branch only, but not directly to any other regional office. Such setup helps central management of security, control over QoS configurations, but often results in poor network paths if two regional branches must exchange data with each other through the ‘hub’. It also often creates unnecessary bottlenecks at the hub when there is heavy inter-site traffic, or there is no early Internet breakout at the branch level.

An opposite configuration is the “mesh” topology, where each office branch maintains a direct tunnel with every other branch. This particular layout results in complex configurations and the need to maintain decentralized security configurations.

The cloud also has a profound impact on how corporate networks look like these days. With me and more services being relocated to the cloud, we should care more about the quality and security of connectivity between regional branches, main office, and cloud regions.

  • internet breakout: Companies may want to route web traffic destined for public Internet from all its branches to the central HQ office over private connections. It allows for central and consistent management of firewalls and web filters at but also means more traffic is flowing over the hub and more bandwidth must be allocated to it. Alternatively, you may want to allow each branch to split traffic and let Internet-bound communication to break out early, at the branch level. It, however, often reduces security and increases management overhead when policies are managed locally and independently.
  • agility: building corporate networks may take time. Setting up MPLS-VPN requires that you engage with ISP that will have to provide required hardware instractruture (customer and provider edge routers). Software-only solutions have an advantage of the much-reduced delivery time of both the initial network setup and much quicker turnaround for subsequent changes (relocating branch, migrating servers/services to the cloud).

Solution 1: The old-school way.

Let’s have a look at how most often regionals branches have been connected to the main office network so far. VPN is still the most commonly used service used for extending local branch networks and providing a secure tunnel over which corporate data is transmitted.

In the diagram below, you can see each local network maintains two connections. One is a rented line secured with a VPN and intended only for sending traffic to network addresses located in the “main branch” network. The other is a local Internet connection over which all non-corporate web traffic is directed. It’s used for sending Internet-destined data directly to the Internet in order to reduce the load on spoke-to-hub link and in turn, to reduce costs and improve on overall user experience.

Branch connectivity

As illustrated above, the company maintains two lines: a secure one (VPN) and an Internet one. Some of the major security risks with the above topology are:

  • VPN alone doesn’t work as a network firewall. Should a computer in a regional branch become infected with a trojan virus, attackers may be able to use it as an entry point to the entire corporate network.
  • VPN isn’t flexible enough to selectively control the level of access that legitimate users should have to individual services hosted in the “main branch”. It opens the whole corporate network, and you will need to limit access through other means.

Solution 2: Software Defined Networking.

Let’s have a look at how we can modernize the corporate network with NetFoundry’s software-only solution.

A few essential building blocks of a NetFoundry network:

  • client: a type of NetFoundry endpoint that you can install on your end device/application to send packets from it (laptop/desktop/mobile/app).
  • gateway: a type of NetFoundry endpoint that you can install on your local area network in order to send and receive packets between your LAN and a NetFoundry Network. It most often is used to facilitate access to services from the NetFoundry network. While clients can only send requests to the NetFoundry network, gateways are able to receive requests. It can also act as a proxy.
  • service: defines resources on your local network that you want to make available over your NetFoundry network. Every service must be assigned to a gateway, which is the exit point for traffic egressing NetFoundry toward the service host. Therefore, the egress gateway must be able to reach the service host to function correctly. By default, packets arriving at the service host will have a source IP address of the egress gateway.
  • AppWAN: a policy that determines which services your endpoints (clients and gateways) have permission to access. AppWANs mandate privileged access, at the most granular levels.

a) Gateway-Only approach:

We can deploy NetFoundry gateways to each office local network. Within the “Main branch” LAN, the gateway will act as an entry point to services hosted there (shared drives, CRM web application, etc.).

As regional branches do not host any service, the role of the NetFoundry Gateways will be different there. It will act as a client proxy, that is, when a local desktop and laptop computer sends traffic to the corporate network, the gateway will subsequently forward it to the Main branch gateway over the NetFoundry network.

It is important to note that only services specified in AppWAN policies can be accessed through the NetFoundry Gateway. All other traffic (to the Internet) should not be directed via NF Gateway.

Branch connectivity

The solution above improves the VPN solution in regards to:

  • Eliminates the need for dedicated lines from an ISP for the sole purpose of the WAN as it’s now built on top of the Internet connection. NetFoundry provides a secure overlay on top of the Internet that supports strong encryption, authentication, and authorization.
  • VPN services have been removed. NetFoundry improves over VPN by reducing latencies thanks to protocol optimizations (UDP, QUIC) and more intelligent route selection.
  • Added more security: while VPN connected entire LANs, NetFoundry only allows traffic between precisely specified services and endpoints.

However, several issues still exist:

  • We have not achieved proper micro-segmentation yet. Any laptop/desktop device allowed to send traffic to the local NetFoundry gateway will have the same permissions to access remote services as the gateway itself.
  • We need to run a gateway instance (a virtual machine) in every regional branch and manage LAN routing table in each regional office so that Intenet -bound traffic is not directed at the NetFoundry gateway. The gateway should only receive data destined for corporate’s private network.

b) Full Micro-Segmentation:

Instead of the “Net Foundry Gateway”, we could set up “Net Foundry Client” software on every desktop/laptop device. The client software from NetFoundry intercepts egressing network requests at source and intelligently decides whether the path to the destination service should be routed over the NetFoundry fabric or not. With “Net Foundry Client” installations, we no longer need “gateways” in regional branch offices.

The biggest win, however, is that we gain proper micro-segmentation and only this is a truly “Zero Trust” network. Every client has it’s own identity, and we’re able to assign permissions to individual services with very fine-grained precision. We can configure AppWANs in a way that permissions to access a specific web service hosted in the “Main branch” network are assigned to only “Desktop 1” client.

Conclusion

Gartner analysts recommend that Zerto Trust Networks should be adopted to replace VPN solutions, which are slowly being phased out. Networking architectures based on the “Software Defined Perimeter” model (link) much better implement “Zero Trust” design principles. According to the model, connections are made of discrete, one-to-one, dynamic sessions between a client and a resource to which the client is requesting access. Outside of such authenticated, authorized and encrypted micro-segments of individual pairings, other resources stay inaccessible. Micro-segmentation and Zero trust seem to us a significant improvement in security over existing VPN solutions. They remediate the biggest flaw of VPN use-case for connecting office branches, namely the fact that VPN can be used a backdoor as it opens entire network subnets, and once a client is authenticated it becomes “trusted” to all services within the network the client obtained an IP address from. An additionally added security enhancement is that SDN gateways can be placed inside private subnets as they do not require public IP addresses attached to them, therefore reducing the size of the attack surface for potential intrusions.

References:
1) “Zero Trust Networks: Building Secure Systems in Untrusted Networks” by Evan Gilman and Doug Barth
2) “Market Guide for Zero Trust Network Access” – Gartner (ID-G00726817)
3) https://netfoundry.io/resources/#whitepapers