Security Archives - cloud13.ch

OCI Network Firewall Powered by Palo Alto Networks

Aug 6, 2025 | Networking, Oracle Cloud Infrastructure, Security

Enterprises running workloads in Oracle Cloud Infrastructure (OCI) often look for deeper inspection, granular control, and consistent policy enforcement. Capabilities that extend beyond the functionalities of basic security groups and route tables.

Historically, many teams implemented these capabilities by deploying virtual appliances or building complex service chains using native components. While functional, those approaches introduced operational complexity, created scaling challenges, and often led to inconsistent enforcement across environments.

To address this, in May 2022, Oracle introduced the OCI Network Firewall, a fully managed, stateful, Layer 7-aware firewalling service built into the OCI platform powered by Palo Alto Networks’ virtual firewall technology. Unlike virtual appliance deployments, this service is provisioned and managed like any other OCI resource, offering deep packet inspection and policy enforcement without requiring the management of underlying infrastructure.

How the OCI Network Firewall Works

The OCI Network Firewall is deployed as a centralized, stateful firewall instance inside a Virtual Cloud Network (VCN). It operates as an inline traffic inspection point that you can insert into the flow of traffic between subnets, between VCNs, or between a VCN and the public internet. Instead of managing a virtual machine with a firewall image, you provision the firewall through the OCI console or Terraform, like any other managed service.

Under the hood, the firewall is powered by the Palo Alto Networks VM-Series engine. This enables deep packet inspection and supports policies based on application identity, user context, and known threat signatures – not just on IP addresses and ports. Once provisioned, the firewall is inserted into traffic paths using routing rules. You define which traffic flows should be inspected by updating route tables, either in subnets or at the Dynamic Routing Gateway (DRG) level. OCI automatically forwards the specified traffic to the firewall, inspects it based on your defined policies, and then forwards it to its destination.

OCI Network Firewall use case diagram, description below

Logging and telemetry from the firewall are natively integrated with OCI Logging and Monitoring services, making it possible to ingest logs, trigger alerts, or forward data to external tools. Throughput can scale up to 4 Gbps per firewall instance, and high availability is built into the service, with deployments spanning fault domains to ensure resiliency.

OCI Network Firewall is a highly available and scalable instance that you create in a subnet. The firewall applies business logic specified in a firewall policy attached to the network traffic. Routing in the VCN is used to direct traffic to and from the firewall. OCI Network Firewall provides a throughput of 4 Gb/sec, but you can request an increase up to 25 Gb/sec. The first 10 TB of data is processed at no additional charge.

The firewall supports advanced features such as intrusion detection and prevention (IDS/IPS), URL and DNS filtering, and decryption of TLS traffic. Threat signature updates are managed automatically by the service, and policy configuration can be handled via the OCI console, APIs, or integrated with Panorama for centralized policy management across multi-cloud or hybrid environments.

Integration with Existing OCI Networking

OCI Network Firewall fits well into the kinds of network topologies most commonly used in OCI, particularly hub-and-spoke architectures or centralized inspection designs. In many deployments, customers set up multiple workload VCNs (the spokes) that connect to a central hub VCN via local peering. The hub typically hosts shared services such as logging, DNS, internet access via a NAT gateway, and now, the network firewall.

By configuring route tables in the spoke VCNs to forward traffic to the firewall endpoint in the hub, organizations can centralize inspection and policy enforcement across multiple VCNs. This model avoids having to deploy and manage firewalls in each spoke and enables consistent rules for outbound internet traffic, inter-VCN communication, or traffic destined for on-premises networks over the DRG.

OCI Network Firewall Hub and Spoke

Source: https://docs.oracle.com/en-us/iaas/Content/Resources/Assets/whitepapers/learn-oci-network-firewall-with-examples.pdf

The insertion of the firewall is purely routing-based, meaning there’s no need for IPsec tunnels or overlays to redirect traffic. As a result, latency is minimal and the setup remains relatively simple. With high availability built in and native integration into OCI’s monitoring and logging stack, the firewall becomes a part of the existing infrastructure.

Design Considerations

While the OCI Network Firewall removes much of the operational burden of managing security appliances, there are still architectural choices that influence how effective the deployment is. One key consideration is routing. Since traffic inspection is based on routing decisions, the firewall only sees traffic that has been explicitly directed through it. That means route tables must be carefully designed to forward the correct flows.

Firewall placement also plays a role in the overall design. Centralized deployment in a hub VCN can simplify management and enforce consistent policy, but it might introduce additional hops in the network path. Depending on the traffic patterns and latency sensitivity of your applications, you may need to evaluate whether east-west inspection should also be enabled or limited to specific flows.

Monitoring and visibility should be planned from the start. Logging is not retained indefinitely, so integrating logs with OCI Logging Analytics, pushing them to a SIEM, or exporting them to object storage for long-term retention is a best practice. You should also account for log volume and potential cost, especially in high-throughput environments.

Throughput limits are another factor. As mentioned before, a single firewall instance supports up to 4 Gbps, so if your architecture requires higher performance, you may need to segment inspection points or scale up to 25 Gbps upon request. Understanding these thresholds is important when designing for resilience and future growth.

Finally, while the firewall is managed, policy complexity still needs governance. Deep inspection features can be powerful but require thoughtful rule design to avoid unnecessary latency or policy overlap.

Final Thoughts

The OCI Network Firewall adds a much-needed layer of native, centralized security enforcement to Oracle Cloud. It brings next-generation firewall capabilities into the platform in a way that aligns with how modern infrastructure is built: with automation, centralized control, and reduced operational overhead. For teams that have struggled to scale or standardize firewalling in OCI using virtual appliances, this service simplifies a lot of that work.

That said, it’s still a tool. Its effectiveness depends on how well it’s integrated into your network design and how clearly your security policies are defined. For organizations moving toward more distributed architectures or running regulated workloads in OCI, it’s a step in the right direction – a platform-native way to improve visibility and control without losing flexibility.

Note: Please be aware that OCI Network Firewall design concepts and configurations are part of the Oracle Cloud Infrastructure 2025 Networking Professional exam.

From Castles to Credentials – Why Identities Are the New Perimeter

Aug 5, 2025 | AWS, Azure, Google Cloud, Networking, Oracle Cloud Infrastructure, Security

The security world has outgrown its castle. For decades, enterprise networks operated on the principle of implicit trust: if a device or user could connect from inside the perimeter, they were granted access. Firewalls and VPNs acted as moats and drawbridges, controlling what entered the fortress. But the rise of clouds, remote work, and APIs has broken down those walls by replacing physical boundaries with something far more fluid: identity.

This shift has led to the emergence of Zero Trust Architecture (ZTA), which flips the traditional model. Instead of trusting users based on their location or device, we now assume that no actor should be trusted by default, whether inside or outside the network. Every access request must be verified, every time, using contextual signals like identity, posture, behavior, and intent.

But “Zero Trust” isn’t just about a philosophical change but about practical design as well. Many organizations start their Zero Trust journey by microsegmenting networks or rolling out identity-aware proxies. That’s a step in the right direction, but a true transformation goes deeper. It redefines identity as the central pillar of security architecture. Not just a gatekeeper, but the control plane through which access decisions are made, enforced, and monitored.

The Inherent Weakness of Place-Based Trust

The traditional security model depends on a dangerous assumption: if you are inside the network, you are trustworthy. That might have worked when workforces were centralized and systems were isolated. With hybrid work, multi-cloud adoption, and third-party integrations, physical locations mean very little nowadays.

Attackers know this. Once a single user account is compromised via phishing, credential stuffing, or social engineering, it can be used to move laterally across the environment, exploiting flat networks and overprovisioned access. The rise of ransomware, supply chain attacks, and insider threats all originate from this misplaced trust in location.

This is where identity-based security becomes essential. Instead of relying on IP addresses or subnet ranges, access policies are tied to who or what is making the request and under what conditions. For example, a user might only get access if their device is healthy, they are connecting from a trusted region, and they pass MFA.

By decoupling access decisions from the network and basing them on identity context, organizations can stop granting more access than necessary and prevent compromised actors from gaining a foothold.

Identities Take Center Stage

Identities are multiplying rapidly, not just users, but also workloads, devices, APIs, and service accounts. This explosion of non-human identities creates a massive attack surface. Yet, in many organizations, these identities are poorly managed, barely monitored, and rarely governed.

Identity-Centric Zero Trust changes that. It places identity at the center of every access flow, ensuring that each identity, human or machine, is:

Properly authenticated
Authorized for just what it needs
Continuously monitored for unusual behavior

Example: A CI/CD pipeline deploys an app into production. With traditional models, that pipeline might have persistent credentials with broad permissions. In an identity-centric model, the deployment service authenticates via workload identity, receives just-in-time credentials, and is granted only the permissions needed for that task.

This model reduces privilege sprawl, limits the blast radius of compromised credentials, and provides clear visibility and accountability. It’s about embedding least privilege, lifecycle management, and continuous validation into the DNA of how access is handled.

Routing With Intent

Zero Trust doesn’t mean the network no longer matters, it means the network must evolve. Today’s networks need to understand and enforce identity, just like the access layer.

A good example of this is Oracle Cloud Infrastructure’s Zero Trust Packet Routing (ZPR). With ZPR, packets are only routed if the source and destination identities are explicitly authorized to communicate. It’s not just about firewall rules or ACLs but also about intent-based networking, where identity and policy guide the flow of traffic. A backend service won’t even see packets from an unauthorized frontend. Routing decisions happen only after both parties are authenticated and authorized.

This is part of a bigger trend. Across the industry, cloud providers and SDN platforms are starting to embed identity metadata into network-level decisions, and routing and access enforcement are being infused with contextual awareness and identity-driven policies.

For architects and security teams, this opens new possibilities for building secure-by-design cloud networks, where you can enforce who talks to what, when, and under what conditions, down to the packet level.

Identity as the Control Plane of Modern Security

If Zero Trust has taught us anything, it’s that identity is the new perimeter and that it’s the control plane for the entire security architecture.

When identity becomes the central decision point, everything changes:

Network segmentation is enforced via identity-aware rules
Application access is governed by contextual IAM policies
Monitoring and detection pivot around behavioral baselines tied to identity
Automation and response are triggered by anomalies in identity behavior

This model allows for granular, adaptive, and scalable control, without relying on fixed infrastructure or fragile perimeters. It also provides a better experience for users: access becomes more seamless when trust is built dynamically based on real-time signals, rather than static rules.

Image with no description

Importantly, this approach doesn’t require a big bang overhaul. Organizations can start small by maturing IAM hygiene, implementing least privilege, or onboarding apps into SSO and MFA, and build toward more advanced use cases like workload identity, CIEM (Cloud Infrastructure Entitlement Management), and ITDR (Identity Threat Detection and Response).

Concluding Thoughts

We need a security model that reflects that reality. Perimeters no longer define trust. Location is no longer a proxy for legitimacy. And static controls are no match for dynamic threats – it’s like using static IPs when working with Kubernetes and containers.

Identity-Centric Zero Trust offers a modern foundation and a strategy. One that weaves together people, processes, and technologies to ensure that every access decision is intentional, contextual, and revocable.

Whether you are modernizing a legacy environment or building greenfield in the cloud, start by asking the right question.

Not “where is this request coming from?” but “who is making the request, and should they be allowed?”.

Secure Cloud Networking in OCI – Zero Trust Packet Routing

Jul 29, 2025 | Networking, OCI Dedicated Region, Oracle Cloud Infrastructure, Security

Zero Trust Packet Routing (ZPR) is Oracle Cloud Infrastructure’s (OCI) move to bring the principles of zero trust to the packet level. In simple terms, it allows you to control exactly which workloads can communicate with each other, based not on IP addresses, ports, or subnets, but on high-level, intent-based labels.

Think of it as network segmentation for the cloud-native era. Done without messing with subnet layouts, static security lists, or hard-to-follow firewall rules.

ZPR allows you to define policies that are explicit, least-privilege, auditable, and decoupled from network topology. It provides an additional layer of protection on top of existing OCI security primitives, such as NSGs, Security Lists, and IAM.

Protection against internet exfiltration with Zero Trust Packet Routing (ZPR)

Key Concepts Behind ZPR

To really understand ZPR, let’s break it into four essential building blocks:

1. Security Attribute Namespaces & Attributes

These are labels that describe your cloud resources in human-readable, intent-focused terms.

A Namespace is a grouping mechanism for attributes (e.g. app, env, sensitivity).
An Attribute is a key-value pair like app:frontend, env:prod, sensitivity:high.

ZPR lets you tag resources with up to 3 attributes (1 for VCNs), and policies reference those attributes to determine which communication flows are permitted.

This is powerful because it enables semantic security policies. You are no longer relying on IP or port-based rules and are using logic that’s closer to your business model.

2. ZPR Policy Language (ZPL)

ZPR policies are written in ZPL, Oracle’s purpose-built policy language for defining allowed connections. ZPL statements follow a clear syntax:

This type of human-readable policy is easy to reason about, easy to audit, and matches well with how teams think about their systems (by role, not IP).

More policy examples can be found here.

3. Enforcement and Evaluation Logic

ZPR does not replace OCI’s native security tools but it layers on top of them. Every packet that passes through your VCN is evaluated against:

Network Security Groups (NSGs)
Security Lists (for subnets)
ZPR Policies

A packet is only allowed if all three layers agree to permit it.

This makes ZPR defense-in-depth rather than a replacement for traditional controls.

It’s also worth noting:

ZPR policies are enforced only within a single VCN.
- Inter-VCN communication still relies on other mechanisms like DRG and route tables.
ZPR policies are evaluated at packet routing time, before any connection is established.

4. Resource Support & Scope

ZPR is currently supported on a growing list of OCI resources, including:

VCNs
Compute Instances
Load Balancers
DB Systems (Autonomous/Exadata)

Also important:

ZPR can be enabled only in the home region of a tenancy
Enabling ZPR in a tenancy creates a default Oracle-ZPR security attribute namespace
Changes to ZPR policies in the Console might take up to five minutes to apply

How to Use ZPR

Step 1: Create Namespaces and Attributes

You start by creating Security Attribute Namespaces (e.g., env, app, tier) and assigning Attributes (e.g., env:prod, app:frontend) to your resources.

You can do this via:

OCI Console
CLI (oci zpr security-attribute create)
Terraform (via oci_zpr_security_attribute resource)
REST API or SDKs

You can assign up to 3 attributes per resource (except VCNs, which allow only 1).

Step 2: Write ZPR Policies Using ZPL

Once your attributes are in place, write policies in ZPL to define who can talk to whom. You can use:

Simple Policy Builder – GUI-based, good for basic use cases. It lets you select from prepopulated lists of resources identified by their security attributes to express security intent between two endpoints. The policy builder automatically generates the policy statement using correct syntax.
Policy Template Builder – Uses predefined templates It lets you select from a list of templates based on common use case scenarios that provide prefilled ZPR policy statements that you can then customize to create a ZPR policy.
Manual Policy Editor
CLI or API – For IaC and automation flows

Example: Allow backend apps in the prod-vcn to reach the database tier on port 1521 (Oracle DB):

Step 3: Assign Attributes to Resources

Finally, use the Console or CLI to attach attributes to resources like compute instances, load balancers, and VCNs.

This is the crucial step that links the policy with real workloads.

Security Advantages of ZPR

Zero Trust Packet Routing introduces significant security improvements across Oracle Cloud Infrastructure. Here’s what makes it a standout approach:

Identity-Aware Traffic Control
Policies are based on resource identity and metadata (tags), not just IP addresses, making lateral movement by attackers significantly harder.
Micro-segmentation by Design
Enables granular control between resources such as frontend, backend, and database tiers, aligned with zero trust principles.
No Dependency on Subnets or Security Lists
ZPR policies operate independently of traditional network segmentation, reducing configuration complexity.
Simplified Policy Management with ZPL
Oracle’s purpose-built Zero Trust Policy Language (ZPL) allows for concise, human-readable security rules, reducing human error.
Auditability and Transparency
All ZPR policies are tracked and auditable via OCI logs and events, supporting compliance and governance needs.
Built for Modern Cloud Architectures
Native support for dynamic and ephemeral cloud resources like managed databases, load balancers, and more.
Defense-in-Depth Integration
ZPR complements other OCI security tools like NSGs, IAM, and Logging, reinforcing a layered security posture.

Summary

Zero Trust Packet Routing marks a pivotal shift in how network security is managed in Oracle Cloud Infrastructure. Traditional security models rely heavily on IP addresses, static network boundaries, and perimeter-based controls. In contrast, ZPR allows you to enforce policies based on the actual identity and purpose of resources by using a policy language that is both readable and precise.

By decoupling security controls from network constructs like subnets and IP spaces, ZPR introduces a modern, identity-centric approach that scales effortlessly with cloud-native workloads. Whether you are segmenting environments in a multitenant architecture, controlling east-west traffic between microservices, or enforcing strict rules for database access, ZPR offers the control and granularity you need without compromising agility.

The real power of ZPR lies not just in its policy engine but in how it integrates with the broader OCI ecosystem. It complements IAM, NSGs, and logging by offering another layer of precision. One that’s declarative and tightly aligned with your operational and compliance requirements.

If you are serious about least privilege, microsegmentation, and secure cloud-native design, ZPR deserves your attention.

Momentum in the Cloud: Crafting Your Winning Strategy with VMware Cloud

Jul 27, 2023 | Alibaba Cloud, AWS, Azure, Cloud Native Apps, Data Protection, Edge Computing, Equinix, Google Cloud, HCX, Kubernetes, NSX, Observability, Oracle Cloud Infrastructure, Security, Supercloud, Tanzu Application Platform, VMware Cloud, VMware Cloud Foundation, VMware Explore, vSAN, vSphere

The time is right for VMware Cloud! In the rapidly evolving landscape of modern business, embracing the cloud has become essential for organizations seeking to stay competitive and agile. The allure of increased scalability, cost-efficiency, and flexibility has driven enterprises of all sizes to embark on cloud migration journeys. However, the road to a successful cloud adoption is often coming with challenges. Slow and failed migrations have given rise to what experts call the “cloud paradox,” where the very technology meant to accelerate progress ends up hindering it.

As businesses navigate through this paradox, finding the right strategy to harness the full potential of the cloud becomes paramount. One solution that has emerged as a beacon of hope in this complex landscape is VMware Cloud. With its multi-cloud approach, which is also known as supercloud, VMware Cloud provides organizations the ability to craft a winning strategy that capitalizes on momentum while minimizing the risks associated with cloud migrations.

The Experimental Phase is Over

Is it really though? The experimental phase was an exciting journey of discovery for organizations seeking the potential of multi-cloud environments. Companies have explored different cloud providers, tested a variety of cloud services, and experimented with workloads and applications in the cloud. It allowed them to understand the benefits and drawbacks of each cloud platform, assess performance, security and compliance aspects, and determine how well each cloud provider aligns with their unique business needs.

The Paradox of Cloud and Choice

With an abundance of cloud service providers, each offering distinct features and capabilities, decision-makers can find themselves overwhelmed with options. The quest to optimize workloads across multiple clouds can lead to unintended complexities, such as increased operational overhead, inconsistent management practices/tools, and potential vendor lock-in.

Furthermore, managing data and applications distributed across various cloud environments can create challenges related to security, compliance, and data sovereignty. The lack of standardized practices and tools in a multi-cloud setup can also hinder collaboration and agility, negating the very advantages that public cloud environments promise to deliver.

Multi-Cloud Complexity

(Public) Cloud computing is often preached for its cost-efficiency, enabling businesses to pay for resources on-demand and avoid capital expenditures on physical infrastructure. However, the cloud paradox reveals that organizations can inadvertently accumulate hidden costs, such as data egress fees, storage overage charges, and the cost of cloud management tools. Without careful planning and oversight, the cloud’s financial benefits might be offset by unexpected expenses.

Why Cloud Migrations are Slowing Down

Failed expectations. The first reasons my customers mention are cost and complexity.

While the cloud offers potential cost savings in the long run, the initial investment and perceived uncertainty in calculating the total cost of ownership can deter some organizations from moving forward with cloud migrations. Budget constraints and difficulties in accurately estimating and analyzing cloud expenses lead to a cautious approach to cloud adoption.

One significant factor impeding cloud migrations is the complexity of the process itself. Moving entire infrastructures, applications, and data to the cloud requires thorough planning, precise execution, and in-depth knowledge of cloud platforms and technologies. Many organizations lack the in-house expertise to handle such a massive undertaking, leading to delays and apprehensions about potential risks.

Other underestimated reasons are legacy systems and applications that have been in use for many years and are often deeply ingrained within an organization’s operations. Migrating these systems to the cloud may require extensive reconfiguration or complete redevelopment, making the migration process both time-consuming and resource-intensive.

Reverse Cloud Migrations

While I don’t advertise a case for repatriation, I would like to share the idea that companies should think about workload mobility, application portability, and repatriation upfront. You can infinitely optimize your cloud spend, but if cloud costs start to outpace your transformation plans or revenue growth, it is too late already.

Embracing a Smart Approach with VMware Cloud

To address the cloud paradox and maximize the potential of multi-cloud environments, VMware is embracing the cloud-smart approach. This approach is designed to empower organizations with a unified and consistent platform to manage and operate their applications across multiple clouds.

Single Cloud Operating Model: A single operating model that spans private and public clouds. This consistency simplifies cloud management, enabling seamless workload migration and minimizing the complexities associated with multiple cloud providers.
Flexible Cloud Choice: VMware allows organizations to choose the cloud provider that best suits their specific needs, whether it is a public cloud or a private cloud infrastructure. This freedom of choice ensures that businesses can leverage the unique advantages of each cloud while maintaining operational consistency.
Streamlined Application Management: A cloud-smart approach centralizes application management, making it easier to deploy, secure, and monitor applications across multi-cloud environments. This streamlines processes, enhances collaboration, and improves operational efficiency.
Enhanced Security and Compliance: By adopting VMware’s security solutions, businesses can implement consistent security policies across all clouds, ensuring data protection and compliance adherence regardless of the cloud provider.

Why VMware Cloud?

This year I realized that a lot of VMware customers came back to me because their cloud-first strategy did not work as expected. Costs exploded, migrations were failing, and their project timeline changed many times. Also, partners like Microsoft and AWS want to collaborate more with VMware, because the public cloud giants cannot deliver as expected.

Customers and public cloud providers did not see any value in lifting and shifting workloads from on-premises data centers to the public. Now the exact same people, companies and partners (AWS, Microsoft, Google, Oracle etc.) are back to ask for VMware their support, and solutions that can speed up cloud migrations while reducing risks.

This is why I am always suggesting a “lift and learn” approach, which removes pressure and reduces costs.

Organizations view the public cloud as a highly strategic platform for digital transformation. Gartner forecasted in April 2023 that Infrastructure-as-a-Service (IaaS) is going to experience the highest spending growth in 2023, followed by PaaS.

It is said that companies spend most of their money for compute, storage, and data services when using Google Cloud, AWS, and Microsoft Azure. Guess what, VMware Cloud is a perfect fit for IaaS-based workloads (instead of using AWS EC2, Google’s Compute Engine, and Azure Virtual machine instances)!

Who doesn’t like the idea of cost savings and faster cloud migrations?

Disaster Recovery and FinOps

When you migrate workloads to the cloud, you have to rethink your disaster recovery and ransomware recovery strategy. Have a look at VMware’s DRaaS (Disaster-Recovery-as-a-Service) offering which includes ransomware recovery capabilities as well.

If you want to analyze and optimize your cloud spend, try out VMware Aria Cost powered by CloudHealth.

Final Words

VMware’s approach is not right for everyone, but it is a future-proof cloud strategy that enables organizations to adapt their cloud strategies as business needs to evolve. The cloud-smart approach offers a compelling solution, providing businesses with a unified, consistent, and flexible platform to succeed in multi-cloud environments. By embracing this approach, organizations can overcome the complexities of multi-cloud, unlock new possibilities, and set themselves on a path to cloud success.

And you still get the same access to the native public cloud services.

What does VMware Cloud Disaster Recovery have in common with Dell PowerProtect?

May 4, 2023 | AWS, Azure, Cloud Native Apps, Data Protection, ESXi, Kubernetes, Security, VCPP, VMware Cloud, VMware Cloud Foundation, vSphere

It was at VMware Explore Europe 2022 when I ran into a colleague from Dell who told me about “transparent snapshots” and mentioned that their solution has something in common VMware Cloud Disaster Recovery (VCDR). After doing some research, I figured out that he was talking about the Light Weight Delta (LWD) protocol.

Snapshots

Snapshots are states of a system or virtual machine (VM) at a particular point in time and should not be considered a backup. The data of a snapshot include all files that form a virtual machine – this includes disks, memory, and other devices like network interface cards (vNIC). To create or delete a snapshot of a VM, the VM needs to be “stunned” (quiesce I/Os).

I would say it is common knowledge that a higher number of snapshots negatively impact the I/O performance of a virtual machine. Creating snapshots results in the creation of a snapshot hierarchy with parent-to-child relationships. Every snapshot creates a delta .vmdk file and redirects all inputs/writes to this delta disk file.

VMware vSphere Storage APIs for Data Protection

Currently, a lot of backup solutions use “VMware vSphere Storage APIs for Data Protection” (VADP), which has been introduced in vSphere 4.0 released in 2009. A backup product using VADP can backup VMs from a central backup server or virtual machine without requiring any backup agents. Meaning, backup solutions using VADP create snapshots that are used to create backups based on the changed blocks of a disk (Changed Block Tracking aka CBT). These changes or this delta is then written to a secondary site or storage and the snapshot is removed after.

Deleting a snapshot consolidates the changes between snapshots and previous disk states. Then it writes all the data from the delta disk that contains the information about the deleted snapshot to the parent disk. When you delete the base parent snapshot, all changes merge with the base virtual machine disk.

To delete a snapshot, a large amount of information must be read and written to a disk. This process can reduce the virtual machine performance until the consolidation is complete.

VMware Cloud Disaster Recovery (VCDR)

In 2020, VMware announced the general availability of VMware Cloud Disaster Recovery based on technology from their Datrium acquisition. This new solution extended the current VMware disaster recovery (DR) solutions like VMware Site Recovery, Site Recovery Manager, and Cloud Provider DR solutions.

VMware Cloud Disaster Recovery is a VMware-delivered disaster recovery as a service (DRaaS) offering that protects on-premises vSphere and VMware Cloud on AWS workloads to VMware Cloud on AWS from both disasters and ransomware attacks. It efficiently replicates VMs to a Scale-out Cloud File System (SCFS) that can store hundreds of recovery points with recovery point objectives (RPOs) as low as 30 minutes. This enables recovery for a wide variety of disasters including ransomware. Virtual machines are recovered to a software-defined data center (SDDC) running in VMware Cloud on AWS. VMware Cloud Disaster Recovery also offers fail-back capabilities to bring your workloads back to their original location after the disaster is remediated.

VMware Cloud DR Architecture

Note: Currently, VCDR is only available as an add-on feature to VMware Cloud on AWS. The support for Azure VMware Solution is expected to come next.

To me, VCDR is one of the best solutions from the whole VMware portfolio.

High-Frequency Snapshots (HFS)

One of the differentiators and game-changers are these so-called high-frequency snapshots, which are based on the Light Weight Delta (LWD) technology that VMware developed. Using HFS allows customers to schedule recurring snapshots for every 30 minutes, meaning, that customers can get an Recovery Point Objective (RPO) of 30min!

To enable and use high-frequency snapshots, your environment must be running on vSphere 7.0 U3 or higher.

With HFS and LWD, there is no Changed Block Tracking (CBT), no VADP, and no VM stun. This results in better performance when maintaining these deltas.

Transparent Snapshots by Dell EMC PowerProtect Data Manager (PPDM)

At VMworld 2021, Dell Technologies presented a session called “Protect Your Virtual Infrastructure with Drastically Less Disruption [SEC2764S]” which was about “transparent snapshots” – image backups with near-zero impact on virtual machines, without the need to pause the VM during the backup process. No more backup proxies, no more agents.

Dell Transparent Snapshot Architecture

As with HFS and VCDR, your environment needs to run on vSphere 7.0 U3 and higher.

How does it work?

PowerProtect Data Manager transparent snapshots use the vSphere API for I/O (VAI/O) Filtering framework. The transparent snapshots data mover (TSDM) is deployed in the VMware ESXi infrastructure through a PowerProtect Data Manager VIB. This deployment creates consistent VM backup copies and writes the copies to the protection storage (PowerProtect appliance).

After, this VIB (Data Protection Daemon (DPD) which is part of the VMware ESXi >7.0 U3 image has been installed on the ESXi host) tracks the delta changes in memory and then transfers the delta changes directly to the protection storage.

VMware Data Protection Daemon

Note: PPDM also provides image backup and restore support for VMware Cloud on AWS and Azure VMware Solution, but requires VADP.

Light Weight Delta (LWD)

It seems that LWD has been developed by VMware but there is no publicly available information out there yet. I only found this screenshot as part of this Dell article:

VMware Light Weight Delta

It also seems that Dell is/was the first who could leverage the LWD protocol exclusively but I am sure it will be made available to other VMware partners as well.

A Closer Look at VMware NSX Security

Dec 21, 2022 | Edge Computing, ESXi, Networking, NSX, Security, vSphere

A customer of mine asked me a few days ago: “Is it not possible to get NSX Security features without the network virtualization capabilities?”. I wrote it already in my blog “VMware is Becoming a Leading Cybersecurity Vendor” that you do not NSX’s network virtualization editions or capabilities if you are only interested in “firewalling” or NSX security features.

If you google “nsx security”, you will not find much. But there is a knowledge base article that describes the NSX Security capabilities from the “Distributed Firewall” product line: Product offerings for NSX-T 3.2 Security (87077).

Believe it or not, there are customers that haven’t started their zero-trust or “micro-segmentation” journey yet. Segmentation is about preventing lateral (east-west) movement. The idea is to divide the data center infrastructure into smaller security zones and that the traffic between the zones (and between workloads) is inspected based on the organization’s defined policies.

Perimeter Defense vs Micro-Segmentation

If you are one of them and want to deliver east-west traffic introspection using distributed firewalls, then these NSX Security editions are relevant for you:

VMware NSX Distributed Firewall

NSX Distributed Firewall (DFW)
NSX DFW with Threat Prevention
NSX DFW with Advanced Threat Prevention

VMware NSX Gateway Firewall

NSX Gateway Firewall (GFW)
NSX Gateway Firewall with Threat Prevention
NSX Gateway Firewall with Advanced Threat Prevention

Network Detection and Response

Network Detection and Response (standalone on-premises offering)

Note: If you are an existing NSX customer using network virtualization, please have a look at Product offerings for VMware NSX-T Data Center 3.2.x (86095).

VMware NSX Distributed Firewall

The NSX Distributed Firewall is a hypervisor kernel-embedded stateful firewall that lets you create access control policies based on vCenter objects like datacenters and clusters, virtual machine names and tags, IP/VLAN/VXLAN addresses, as well as user group identity from Active Directory.

If a VM gets vMotioned to another physical host, you do not need to rewrite any firewall rules.

The distributed nature of the firewall provides a scale-out architecture that automatically extends firewall capacity when additional hosts are added to a data center.

Should you be interested in “firewalling” only, want to implement access controls for east-west traffic (micro-segmentation) only, but do not need threat prevention (TP) capabilities, then “NSX Distributed Firewall Edition” is perfect for you.

So, which features does the NSX DFW edition include?

The NSX DFW edition comes with these capabilities:

L2 – L4 firewalling
L7 Application Identity-based firewalling
User Identity-based firewalling
NSX Intelligence (flow visualization and policy recommendation)
Aria Operations for Logs (formerly known as vRealize Log Insight)

What is the difference between NSX DFW and NSX DFW with TP?

With “NSX DFW with TP”, you would get the following additional features:

Distributed Intrusion Detection Services (IDS)
Distributed Behavioral IDS
Distributed Intrusion Prevention Service (IPS)
Distributed IDS Event Forwarding to NDR

Where does the NSX Distributed Firewall sit?

This question comes up a lot because customers understand that this is not an agent-based solution but something that is built into the VMware ESXi hypervisor.

The NSX DFW sits in the virtual patch cable, between the VM and the virtual distributed switch (VDS):

NSX Distributed Firewall

Note: Prior to NSX-T Data Center 3.2, VMs must have their vNIC connected to an NSX overlay or VLAN segment to be DFW-protected. In NSX-T Data Center 3.2, distributed firewall protects workloads that are natively connected to a VDS distributed port group (DVPG).

VMware NSX Gateway Firewall

The NSX Gateway Firewall extends the advanced threat prevention (ATP) capabilities of the NSX Distributed Firewall to physical workloads in your private cloud. It is a software-only, L2 – L7 firewall that includes capabilities such as IDS and IPS, URL filtering and malware detection as well as routing and VPN functionality.

If you are not interested in ATP capabilities yet, you can start with the “NSX Gateway Firewall” edition. What is the difference between all NSX GFW editions?

VMware NSX GFW Editions

The NSX GFW can be deployed as a virtual machine or with an ISO image that can run on a physical server and it shares the same management console as the NSX Distributed Firewall.