How to Decommission On-Premise Private Networks

I have been having some interesting customer discussions lately around the future of Enterprise Networking. For most customers today, Hybrid cloud is the reality and the new norm. This involves traditional on-premise private networking interconnected to various cloud datacenters through traditional methods such as VPN.

I have had some customers though who are interested in going 100% cloud and are curious about how that might be accomplished. Particularly in the Enterprise space, there is a need for a global network backbone, a network core, and remote access / VPN in addition to various service layers. There are a lot of network services and complex configurations that either need to remain in a co-lo data center or be ported to the cloud.

Now these days it is possible to lift and shift these last components to the cloud. Nearly every cloud provider has all the analogs needed or have the ability to deploy a virtual appliance for any of your major network appliance boxes. Platform network services are available as well as VSAs from every manufacturer. Whether you use Cisco, Palo Alto, etc, etc, there are Virtual models of your favorite appliances available so you can mirror your on-prem configuration in the cloud. This is essentially the traditional “lift and shift” but with Networking equipment in scope rather than workloads.

As we all know, Lift and Shift isn’t the ideal. It doesn’t take advantage of modern services that are available, doesn’t usually map cleanly to the strengths of the cloud data center, and is generally very expensive. It also hold on to some legacy architecture which will continue to require legacy skillsets in addition to the new cloud skill sets that are required.

So what is the new way? Or rather, what is a better way to provide private network services and all of their important features without keeping a physical presence and without doing a legacy lift and shift? Everybody has some ideas and for the most part they still have one foot in legacy, trying to keep vendor relations and skillsets relevant.

I recently had a potential customer challenge me to solve this problem as an academic exercise / B2B interview.

Defining the Business Requirement

The Internet Provides:

•A resilient network infrastructure
•Optimized routing between resources
•Support for all protocols and standards
•Ability to move / relocate resources

So why use a complex and expensive Private Network?

This is by no means a complete list, however, here are some of the core features provided by a Private Network. These all map to common business requirements and generally provide services that are not available on the public internet.

Global Network Backbone
•Provides Private Communication
•Provides geographical security boundaries

Regional Network Core
•Provides network segmentation and routing
•Provides insertion point for policy and security

Network Perimeter
•Provides access to the internet
•Provides security boundary for internal network

•Allows remote end-points to participate with internal network

• Provides Network redundancy / Resilience
• Provides cost based / optimal routing

• Provides various levels of access control

• Provides physical autonomy for services
• Enables zero Trust Models
• Enables principal based access control

Identity Provider
• Provides authentication
• Provides federation and SSO
• Provides MFA
• Provides Security Principals and Groups

• Netflow

Net Properties of a Private Network





The goal of a private network is to provide connectivity to private resources, privacy of data and communications, control over access, and in many cases, visibility into access patterns, failed events, auditing, etc.

A Modern Approach

So how can we achieve these same core capabilities and even some/all of their granular sub-capabilities without investing in these big network appliances and service layers?

An Ideal Solution would have these qualities

  • Use the public internet as a global backbone
  • Utilize a Zero-Trust / no access default
  • Provide the optimal route between resources
  • Provide private communication over the wire at all times
  • Allow for centralized and discrete Access Control to resources
  • Provide an audit trail for compliance and security purposes
  • Not require proprietary or expensive hardware

Thought Process

The internet itself provides a resilient, performant, and inexpensive access layer. Anyone has access to this default fabric from just about anywhere and over a wide variety of mediums.

The best path between any two devices is generally via their public IP addresses or the public IP address of their local internet gateway.

Various technologies exist for authenticating, authorizing, and securing access between resources

Zero Trust, not just at the authentication layer, but also at the access layer would prevent brute force or exploit attack vectors on internet accessible resources.

Point to Point VPNs would allow secure communication between any two devices but also allow access to services that are not presented over public IP addresses.

A persistent private ID for each resource would support full mobility of resources between remote offices, cloud regions, etc.

An installable OS / network extension would be ideal as opposed to a physical appliance based approach

A solution that could utilize existing cloud-based identity providers would be simple and facilitate central management as well as taking advantage of native features in that IDP such as MFA, Risk-based conditional access, SSO, etc, etc, etc.

A solution with a simple and central management interface could easily take the place of countess devices and the administrative burden / complexity that that bring.

So where to start?

It occurred to me that a point to point / mesh VPN with central management would knock most of these requirements out easily. I did some research and found a solution that I thought would work well. I did some testing and came back with this:

  • Point to Point communication between clients over the public net
  • Superior NAT traversal
  • Strong key-based encryption
  • Persistent private IP addresses with a variety of DNS options
  • Zero-Trust default
  • Centrally managed Access Control and Endpoint visibility
  • Makes use of common IDPs such as Azure AD or Google
  • Inherits the advanced security features from these IDPs
  • A variety of ACL types including user and group based ACLs
  • Software only / agent based on all major OSs including mobile devices
  • Ability to create proxies to bastioned resources or resources that don’t support the client
  • Ability to create routes between remote data centers and maintain ACLs for those address spaces
  • Audit logging at top of feature roadmap


I am seriously impressed. The first thing that jumped out at me is how powerful Zero-Trust is when combined with Principal (user/group) based ACLs. Being able to control resources based on group membership is hugely beneficial for a large number of reasons.

I took this another step further. Most resources support AD-integrated or LDAP based authentication. Making use of groups I was able to secure resources such that not only is login prohibited without the right group membership but all network access is also prohibited. I was able to test a scenario where a network resource was unreachable and login was not allowed even if it were reachable. Then simply by adding a user into an Active Directory group, I was able to grant both network access and login access. Furthermore, the access mechanism (the client) requires MFA to login to the network. An extra data point here is also that the network resource is bastioned and has ZERO internet access at all. This create several layers of security that are difficult to achieve with a legacy network.


As you can see, there is no network access to my Virtual Center server. It is on a bastioned private network and I am on the public internet. The security group that I will use to grant access is empty.

Granting Access

As you can see in the top right, I’m logged in via SSO


In conclusion I think its possible to create equivalent enterprise services to the ones we use on prem today. I think we can do it without a lot of complexity, and I think we can do it with a smaller team than ever before. Taking a completely bastioned service and exposing access over the public net through an Active Directory group membership is something I have never personally experienced using complex and expensive private networking products. I know its possible but the implementation overhead and capital expenses are formidable. I think that this approach could be a win.

Wrapping Up

•Challenge Traditional Approaches to Infrastructure, Security, and Access
•Cloud and Hybrid Cloud Infrastructures can be significantly simpler but must be embraced
•The answer may be throwing out attachment to legacy services
•Leverage Modern Authentication and IDPs wherever possible
•Network with people who are learning and doing interesting things

Comments are closed.

Blog at

Up ↑

Create your website with
Get started
%d bloggers like this: