Architecture

This document explains the architecture of the n2x.io SASE platform, highlighting its key components and their functionalities.

Layered Design

The n2x.io platform adopts a layered approach, consisting of three distinct planes:

• Data Plane: Responsible for transporting data across the network. The virtual network paths that carry data packets from their origin to their intended destinations.

• Control Plane: Governs the overall operation of the platform. It dictates how various components and services interact with each other to ensure smooth data flow and security enforcement.

• Management Plane: Provides the user interface for interacting with the platform. Through this plane, users can manage and control their services within n2x.io, including configuration and policy definition.

Benefits of Layered Architecture

This layered approach offers several advantages:

• Modularity: Each plane has dedicated functionalities, making the platform easier to maintain and update.
• Scalability: The horizontal scalability of components within each plane allows n2x.io to adapt to growing demands.
• Security: The separation of user interaction (management plane) from data flow (data plane) enhances overall security.

Core Components

The n2x.io platform leverages several key components to deliver its SASE functionalities:

Managers

These are internal components residing within the management plane. They act as intermediaries between the user interfaces and the control plane.They are globally scoped, meaning they operate across all regions, and are horizontally scalable for high availability.

Controllers

Controllers are the operational backbone of the n2x.io platform. They are responsible for configuring and managing network components such as nodes, proxies, and relays to execute user-defined functions.

Operating within specific regions, controllers are horizontally scalable to accommodate varying workloads. They function akin to BGP route reflectors in traditional networks, facilitating multi-cloud connectivity. However, unlike BGP, controllers leverage gRPC and MQTT protocols to accomplish the same feature.

When creating your n2x.io account, you'll select the region where your controllers will be deployed to best align with your network requirements.

Connectivity Zones

Connectivity zones are internal components within the n2x.io platform that act as deployment locations for network elements like Relays and Secure Gateways. Each n2x.io network is associated with a single connectivity zone.

Choosing the Right Zone

The location of your connectivity zone can have a significant impact on network performance. Services that rely on components within a particular zone may introduce latency, both between nodes and users, as well as between n2x.io nodes themselves.

To minimize latency and ensure optimal network performance, it is recommended to choose a connectivity zone that is geographically close to where your n2x.io nodes will be deployed. This proximity helps facilitate faster communication between network components.

When creating a network within the n2x.io platform, you will be presented with a list of available connectivity zones (e.g. eu-south, eu-west, or us-central). Choose the one that best matches the planned location of your n2x.io nodes.

Tenants

A n2x.io tenant functionality allows you to create logical partitions within your n2x.io account, enabling segregation and isolation of resources. This is particularly useful for managing complex deployments or separating resources for different teams or projects.

Network Topology

Network Topology is essentially an abstraction layer that you create by deploying and interconnecting various network components with a hierarchical structure: networks, subnets and nodes within your n2x.io tenant.

Think of the Network Topology as an overlay built on top of your existing cloud and on-premises infrastructure. This overlay provides a secure and manageable way to connect and orchestrate your network resources within the n2x.io platform.

Networks

Networks are fundamental building blocks within the n2x.io platform. They serve as logical groupings for your IP subnets, facilitating efficient organization and management of your network infrastructure. While you can create an unlimited number of networks within your tenant, each network can accommodate up to 255 subnets.

By default, n2x.io isolates subnets within a network, ensuring inherent security boundaries. However, you can configure a network to allow communication between subnets by enabling the routed subnets option. This flexibility lets you tailor your network configuration to your specific needs.

Furthermore, networks are linked to a connectivity zone, establishing a connection to a specific area or domain within the n2x.io environment. This association helps in defining the scope and reach of network connectivity within the n2x.io architecture.

Subnets

A subnet within the n2x.io network is a logical subdivision that connects devices (nodes). Each subnet can accommodate a maximum of 255 nodes. Configured with a /24 IPv4 prefix from the network IP range, a subnet provides the necessary addressing for connected nodes.

Furthermore, every subnet is associated with a security policy that is enforced at the node level. This distributed firewall protection ensures the network's security by regulating traffic and access across the nodes within the subnet or from different subnets.

Nodes

An n2x.io node represents any device you connect to the platform within a specific tenant. This can include virtual machines (VMs), Kubernetes pods, bare-metal servers, Docker containers, laptops, or workstations.

n2x.io offers two main integration modes for nodes, providing flexibility in how you connect your resources: connected nodes or stubby nodes.

Up to 255 nodes can be connected to a n2x.io subnet at maximum capacity. When a node is connected to a subnet, it is assigned at least one IP address from the subnet's IP range.

Relays

While n2x.io's connected nodes can establish peer-to-peer connections, there may be cases where direct connection isn't possible due to NAT or firewall restrictions. In such situations, relays step in to bridge the gap and ensure seamless communication between nodes.

n2x.io provides two types of relays:

• Platform-Provided Relays (Shared)

  n2x.io offers multiple public relay nodes distributed across various locations, grouped by network connectivity zones. These relays are always available to facilitate communication when direct connection are not possible.

• Auto-Discovered Relays (Dedicated)

  Alternatively, n2x.io can designate specific connected nodes within your subnet as relays. To be marked as relays, these nodes must have a public address or NAT and allow inbound TCP/UDP port 57775 from the internet.

By enabling communication between nodes that cannot connect directly, relays play a crucial role in maintaining network connectivity and ensuring a smooth data flow within your n2x.io environment.

Secure Gateways

Secure Gateways are specialized components within n2x.io's network connectivity zones. They play a vital role in facilitating services like Identity-Aware Proxy.

Secure Gateways provide:

• Centralized Access Control: The secure gateway offers a single point of control for managing application access permissions.

• Simplified User Access: Users can access authorized applications without installing additional software.

• Enhanced Security: The secure gateway enforces authorization policies at the application layer, bypassing the limitations of network-level firewalls. This can potentially lead to a more robust security posture.

End-to-End Encryption

End-to-end encryption is a method of secure communication that ensures that only the sender and the intended recipient can access the data.

With n2x.io end-to-end encryption, the data is encrypted on the sender's device, transmitted over a point-to-point tunnel, and then decrypted on the recipient's device. This means that even if a third party intercepts the communication, they will not be able to read the data.

End-to-end encryption provides a high level of security, as there is no need to trust any third party to protect the data.

Network and Security Requirements for n2x.io Nodes

This section outlines the protocols and ports required for n2x.io nodes to communicate with the platform's data and control planes. Ensuring these requirements are met is essential for proper node functionality.

The tables below specify the ports and protocols used for communication, categorized by node type:

Connected Nodes

Stubby Nodes

Security Software Considerations

On Windows devices, certain Endpoint Detection and Response (EDR) or Extended Detection and Response (XDR) solutions may interfere with node operation by performing real-time scans on the database. This can lead to data corruption and service disruption.

To prevent this, we recommend excluding the following directories from real-time scanning in your EDR/XDR solution:

• C:\Program Files\n2x\db
• C:\Program Files\n2x\cache

This exclusion helps ensure stable node performance by preventing unintended interference with the database files.

Communication Modes in n2x.io

n2x.io establishes a secure, encrypted communication network between your Connected Nodes.

This network operates using a full mesh of encrypted tunnels, enabling direct peer-to-peer communication whenever possible. However, the connection type depends on the nodes' reachability. There are two possible connection modes:

• DIRECT – Preferred, for optimal performance.
• INDIRECT – Used when direct communication is not possible.

Direct Connection (Preferred)

A direct connection is the most efficient communication method in n2x.io. It occurs when both nodes can reach each other directly on TCP/UDP port 57775, ensuring low-latency and high-performance data transfer.

Indirect Connection (Fallback)

If a direct connection cannot be established due to NAT or inbound firewall restrictions, n2x.io automatically falls back to relays to facilitate communication. In this scenario, the platform selects an optimal relay server to route traffic between the nodes.

While indirect connections introduce some additional latency compared to direct connections, they ensure that communication remains uninterrupted even when direct paths are unavailable.