ZTNA: Is it really the end of VPNs?

ZTNA: Is it really the end of VPNs?

The Zero Trust Network Architecture (ZTNA) movement has been around long enough that many vendors have proclaimed the “end of the VPN era” (1)(2)(3).  While ZTNA offers valuable security benefits, we can’t help but wonder if this declaration is premature and naive.

Don’t get me wrong – ZTNA is a powerful approach to secure applications. By assuming all users are potential threats, it verifies, identities, and permissions before granting access to resources. However, relying solely on layer 7 (L7) solutions like those described by ZTNA advocates may leave your organization vulnerable to other types of attacks.

The Limitations of L7 Security

ZTNA’s focus on the application layer can’t address issues at the network layer. Few enterprises have HTTPS/web-based only infrastructure. It is more complicated than that at the network layer. This means that even with a robust ZTNA solution in place, you’re still exposed to threats like DNS spoofing, IP spoofing, and lateral movement.

Perhaps at the heart of our disagreement, if we had to pick “no vpns” vs. “everything is a vpn”, we would lean toward the latter. Your carrier network uses virtual private networks, your cloud subnets at AWS and Azure are virtual private networks, your VMware infrastructure running NSX is a virtual private network, and so it goes throughout the infrastructure used by well-secured enterprises. Oh and you’re technically reading this blog through a tunnel (encrypted communication channel established between your browser and the web server using TLS/SSL cryptography).

A Combined Approach is Key

Instead of relying solely on a simplistic definition of ZTNA, we recommend a combined approach that incorporates multiple security layers. This includes:

  1. Network segmentation: Divide your network into smaller segments based on business needs, reducing the attack surface and limiting lateral movement.
  2. Encryption: Encrypt sensitive data in transit using technologies like Wireguard, OpenVPN (SSL/TLS), and IPsec.
  3. ZTNA: Implement ZTNA to verify identities and permissions at the application layer.
  4. Network security appliances: Use network security appliances like firewalls, intrusion detection systems (IDS), and next-generation firewalls (NGFW) to detect and prevent threats at the network layer.

While ZTNA is an essential approach to a comprehensive network security strategy, it’s not a panacea for all network security issues. By combining multiple security layers, you can create a robust defense that addresses various threat vectors.

Don’t fall prey to the hype – take a balanced approach to securing your organization’s network.

Moving to IPv6 – herein lies madness (Part 2)

Moving to IPv6 – herein lies madness (Part 2)

This post is short and essential.

The are two Internets now: the IPv4 Internet and the IPv6 Internet.

The IPv6 Internet is not related to the IPv4 Internet as you have configured it inside, outside, or at the edge of your Enterprise.
IPv6 is not the next version of the Internet protocol; it is the next Internet.

This is the best way to think about it in order to have a more intuitive feel of what is happening underneath it all.

AND – the two Internets never meet. Meaning they are side by side, and applications can move data between them, but in their essence they are different Internets.

Both Internets move across the same layer 2 and physical links, and the protocols above them largely work the same on both, but they are distinct at layer 3, where addressing and naming and routing and firewalling and flow control and many other Internet-y things happen.

A computer may exist on either or both Internets concurrently; an application may bind a network socket to either or both; but they are entirely separate and unrelated.

You will hear about NAT64 (and some NAT46) and the implicit description that addresses are being translated from 6-to-4. I am sure that is the name that will “win” in the industry, but this is a place where we will stand apart. We are calling it Proxy64 and Proxy46, as that is a more realistic and familiar description of what is actually happening. It is not address “translation” in the long standing sense, it is packet TRANSMOGRIFICATION* (according to rules which are in some ways “NAT-like.”) It pulls the payload out of an IPv6 packet and creates an entirely new IPv4 packet. (Some concepts don’t even translate well between the two; these cases are handled by different sofware anywhere from “poorly” to “confusingly.”)

Cohesive’s VNS3 6.6.x is moving out into customer’s hands and with it, our Proxy64 and Proxy46 plugins for communicating between the two Internets.

Let us know how we can help your teams get connections up and running at cloud edge using IPv6.

(ps. If you are just coming up to speed on IPv6 here is a good primer from Microsoft. The “producer-centric” nature of IPv6 comes through, but is a good summary of the industry description and belief systems (don’t let the ‘dotnet’ in the URL scare you).

*Yes that is a C&H reference

Moving to IPv6 – herein lies madness (Part 1)

Moving to IPv6 – herein lies madness (Part 1)

Well, it’s finally happened. It’s the “year of IPv6” for the enterprise.
With this transition will come a significant amount of “cognitive load” for enterprise application and infrastructure administrators.

After a decade or more, it appears there will finally be a broad-based move to Internet Protocol version 6. All it took was for Amazon to announce a price increase for the use of IPv4 (Internet Protocol version 4) addresses.

IPv6 has been being deployed incrementally since 2012 – but for many of us it has been via background adoption by consumer products that we may not even been aware of; cable companies and mobile phone vendors providing the infrastructure to our homes and devices.

For the b2b software and infrastructure technology used by the enterprise, it remains new and novel. For example, Amazon Cloud has supported some IPv6 for a number of years, both dual stack and single stack, whilst Microsoft Azure Cloud only began in earnest in 2023. Both platforms still have significant limitations and fragmentation of support across products.

So if the tech titans are just getting their heads around IPv6, what are us “normies” supposed to do?

At Cohesive Networks, our plan was to start slipping in support over the course of this year, finishing sometime in 2025 for an expected enterprise demand in 2026. Why haven’t we supported to date? Frankly, “no one uses it” – in that of the SaaS, PaaS, and BPaaS companies we support, none of them have asked for it……until the AWS price increase. Our metal-based competitors like Cisco and Palo Alto have supported it for years, but from our broad experience working with our customers, and our customer’s customers, and our customer’s customer’s outsourced network support people, the feature was a tree falling in the forest.

While there is a need to expand the available address pool, there is conflict and confusion between the “producer-centric” intelligence that created IPv6 and its revisions and implementations to date, and the practical needs, the “consumer-centric” needs, of the people just trying to get their jobs done.

There is a disconnect between the simple needs that we satisfy with IPv4; deploy a server, deploy 10 servers, deploy a cluster of a couple hundred servers; and the massive scale of IPv6 which immediately confronts its business consumers.

At Cohesive, we have done a decent job of reducing much of networking and security to “addresses, routes, and rules.” But even for us, helping customers deal with three hundred forty undecillion, two hundred eighty-two decillion, three hundred sixty-six nonillion, nine hundred twenty octillion, nine hundred thirty-seven septillion addresses is a challenge.

Ok, that number above is the whole space, so maybe I am being overly dramatic.

Let’s just get an AWS VPC or Azure VNET with a single IPv6 subnet; that should be easier to deal with.
Minimal size is a /64, that sounds better. Oops, that is 18,446,744,073,709,500,000 addresses! (For those of you speaking it aloud, that’s eighteen quintillion, four hundred forty-six quadrillion, seven hundred forty-four trillion, seventy-three billion, seven hundred nine million, five hundred thousand addresses).

And for every virtual network/subnet – another eighteen quintillion.

Now, if I have 10, 100 or 1000 servers to deploy – what does it matter? Just use some addresses and carry on.
True enough, but the fact that they come from a potential space of 1.8 x 10^19 is serious cognitive load that is presented to the infrastructure operators, and it is naive to think this doesn’t come at a cost. As computer memory went from 512k on a “FAT MAC” to 96G on my MacbookPro, I didn’t have to confront the gap between 524,288 bytes and 103,079,215,104 bytes in the normal course of my work.

So what do we do? Well for our part, as we release VNS3 6.6 (with IPv6), we are reducing some of this cognitive load and will be working with our customers to ever-simplify the move to IPv6.

In the meantime, here is a Google Spreadsheet we created for our internal use to help us get our heads around the magnitude of the IPv6 space. Feel free to share: https://docs.google.com/spreadsheets/d/1pIth3KJH1RbQFJvZmZmpBGq6rMMBhqEmfK-ouSNszNY/edit#gid=0

Stand Apart – but be Cohesive

I received a number of congratulations on the LinkedIn platform last month when apparently it let people know I have been with Cohesive Networks for 9 years.

As I reflected on this one thing stands out in relief, and that is Cohesive has always “stood apart” within the markets it serves.

Cohesive Networks exists at the confluence of virtualization, cloud, networking and security. We are of course a part of this commercial market but have not been re-directed by every twist and turn of these markets that have come and gone. Flavor and fashion are often the order of the day, and no doubt we have adopted some of the descriptive labels through time. But the labels have not swayed us from our essential mission, getting customers to, through and across the clouds safely.

If you look at the Gartner hype cycle for cloud networking it provides a gallery of differentiators through time: network observability, container/kubernetes networking, multicloud networking, SASE, SSE, Network-as-a-Service, SD-branch, network automation, network function virtualization, software defined networking, zero trust networks, software-defined WAN, micro-segmentation. If you look at these different facets, the tools, techniques, and knowledge to implement these are not that different. What is different is the packaging and the go-to-market.

Because we have been providing a virtual network platform since the clouds began, we have had customers use us for all of these functions. As a result the good news is we have been less “swayed” by flavor and fashion, which has done well for our existing customer. The bad news is we haven’t always best communicated our value to the potential new customer who may be thinking very much in the context of one of these re-packaged approaches.

Our usual inbound leads are “Hi, I think we need your stuff” or “Hi, we are using a lot of your stuff, can we discuss volume discounts and support plans”.

This communication posture stems from the fact that we have often been ahead of our competitors in either implementation or insight, or both. We were the first virtual network appliance in the EC2 cloud, IBM Cloud, many of the “clouds no-more”, and at later dates among the first network and security appliances in Azure and Google.

Cohesive’s patents are for “user controlled networking in 3rd party computing environments”. It is a subtle distinction – but powerful, between what an infrasturcture administrator, network administrator or hypervisor administrator could do at that time, and the freedom of our users on that infrastructure to create any network they wanted. These are encrypted, virtual networks that their infrastructure providers know nothing about, can not see, nor control. Our users in 2009 and beyond could create any secure, mesh, over-the-top network they wanted without the need or expense of the network incumbents who came before us. These customers find us significantly easier, significantly less expensive and made for the cloud without “metal” roots dragging them back to the ground.

When we showed this capability to investors, partners, infra providers, acquirerers – many of them said “I don’t get it” or “we’ll do better (someday)” or “you have to do all this in hardware” and more. By comparison, the customers who found us through web search, cloud conferences, and cloud marketplaces said “that’s what I need” and a subscription cloud networking company was born.

Looking back, it is shocking that our first offering was “virtual subnets”. It is amazing to think about it, but we sold subnets! At that time any cloud you used put your virtual instances in a very poorly segmented 10.0.0.0/8 subnet of the compute virtualization environment. People wanted to control addresses, routes, and rules, and our encrypted mesh overlay provided it. That was our first product-market fit, and of course that has evolved considerably.

This set us on the path of listening to our customers, and asking ourselves quite fundamentally what a network is, and what is it used for, and by whom?

So while we stood apart, of course we were Cohesive.

Networks are all about standards and interoperability, we just did it our own way.

The feedback from customers was “yes” and “more please”. The feedback from the experts often remained “huh”. So we pressed forward in our own autonomic and somewhat autistic manner, only listening to certain market signals and obsessively working to fulfill a vision of networking and security that says “networks are addresses, routes and rules, everything else is implementation detail the customers should rarely see.”

Now in 2024 and beyond, as the chaotic streams of the changing cloud markets, Internet Protocol v6, and the needs for secure AI and private AI collide, my guess is we will still stand apart while still being Cohesive.

Navigating the Cloud Transition: Simplified Solutions for Legacy Applications

Navigating the Cloud Transition: Simplified Solutions for Legacy Applications

 source:Dall-E

Overcoming the Complexities of Cloud Migration with Cohesive Networks’ VNS3 Plugin System

Transitioning legacy applications to the cloud can be a daunting task. The challenges are numerous: complex network reconfigurations, increased costs, extended downtimes, and potential security risks. These hurdles are particularly pronounced for applications that rely on broadcast functionality, a common feature in many legacy systems yet challenging to implement in cloud environments – and entirely missing from the offerings of today’s major cloud providers.

Addressing the Core Challenges:

Complex Network Reconfiguration:
Legacy applications often depend on specific network features, like Layer 2 broadcast, which aren’t natively supported in cloud environments. Reconfiguring these applications for cloud networks usually means extensive and costly alterations.

Cost and Resource Allocation:
Moving to the cloud shouldn’t mean breaking the bank or pushing back deadlines. Traditional methods involve hiring specialists or investing in extensive development work, leading to spiraling costs and repeated delays.

Downtime and Operational Delays:
Every minute your application isn’t fully operational impacts your business. Lengthy transitions and testing periods are common with traditional cloud migration methods. The more your application has to change to fit a new environment, the greater the chances for costly mistakes.

Security Concerns:
Adapting legacy applications to the cloud can introduce vulnerabilities, especially when modifying network architectures. New code means new bugs, and new configuration introduces opportunities for human error.

The VNS3 Solution

At Cohesive Networks, we’ve developed a new plugin for our VNS3 software that specifically addresses these issues for applications requiring broadcast functionality. Our solution allows for a seamless and efficient transition to the cloud, without the need for extensive network reconfiguration or application rewriting.

Ease of Use:
With our plugin, most broadcast-dependent applications can be migrated to the cloud with minimal setup and no changes to the existing code or application workflow.

Cost-Effective:
Our approach significantly reduces the need for expensive network specialists, extensive redevelopment, offering a more budget-friendly solution.

Minimized Downtime:
Our streamlined process ensures a faster and smoother transition, reducing operational disruptions. HA and failover options mean that you won’t sacrifice the inherent reliability of cloud environments.

Secure Transition:
VNS3 maintains a strong security posture throughout the migration process, ensuring your data and applications are protected.

Your Path to Cloud Efficiency

Embrace the future of cloud networking with Cohesive Networks. VNS3 isn’t just a tool; it’s a comprehensive solution that makes your cloud networking efficient, secure, and cost-effective. Experience a smoother transition and enable your applications to thrive in a new cloud environment with ease and confidence.

Contact a Cohesive Networks expert today for real solutions that provide real value.

Apple VisionPro – No security issues yet!

Apple VisionPro – No security issues yet!

Cohesive Networks VNS3 6.0 - Clientpacks Page

This front image of the Apple VisionPro augmented reality headset is apt at the moment.

It is dark and we can’t see clearly yet, which is OK, because it allows us the opportunity to prognosticate.

In addition, no network or security issues yet!
We still have time to panic.

Although devices are not a normal topic for us at Cohesive Networks, as CTO, I thought I would ruminate a bit at LinkedIn in a post on The Apple Impact (2023).

Whilst the future is a bit murky, the AI breakout and VisionPro for AR (augmented reality) will combine in interesting ways: compelling, practical, frightening, and unanticipated.

From a Cohesive point of view, as we provide over-the-top networks and security to, through and across the clouds, both of these trends are going to have an impact with Large Language Models deep in the clouds, and augmented reality as the lens from below, piercing the cloud cover.

From a personal point of view:

“Vision Pro emerges at the same time as the artificial intelligence breakout. What will these gods of unknown intention be whispering in our ears? I can’t quite yet imagine these two emergent technologies combined and how it could bring about completely new social environments – with all the good and all the terrible amplified.”

We would love to hear what you think.