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 proxies. Each n2x.io network is associated with a single connectivity zone.
Choosing the Right Zone
The location of your connectivity zone can influence network performance. Services utilizing components within a zone may introduce latency between nodes and users, as well as between n2x.io nodes themselves.
To minimize latency and ensure optimal network performance, it's recommended to select a connectivity zone geographically close to where your n2x.io nodes will be deployed. This allows for faster communication between network components.
During network creation within the n2x.io platform, you'll be presented with available connectivity zones. Choose the one that best aligns with 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 situations where direct communication isn't possible. This could be due to firewall restrictions or other network configurations. In such scenarios, relays come into play to bridge the gap and ensure seamless communication between nodes.
n2x.io offers two types of relays:
-
Platform-provided Relays: These relays reside within the n2x.io network connectivity zones. They are readily available to facilitate communication between
Connected Nodes
whenever direct connections are unavailable. -
Auto-discovered Relays (Connected Nodes): n2x.io can also leverage certain
Connected Nodes
in your network topology as relays. These nodes must haveTCP/UDP port 57775
exposed to the internet to be eligible for this role.
By enabling communication between nodes that cannot connect directly, relays play a crucial role in maintaining network connectivity and ensuring the smooth flow of data 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 to enable communication between n2x.io nodes and the platform's data and control planes. Ensuring these requirements are met is crucial for proper node functionality.
The tables below detail the specific ports and protocols used for communication, categorized by node type:
Connected Nodes
Port | Protocol | Direction | Usage |
---|---|---|---|
443 | TCP | Node to Control plane (Outbound) | Communication with the control plane for management purposes (gRPC) |
1883 | TCP | Node to Control plane (Outbound) | Communication with the control plane for messaging (MQTT) |
57775 | TCP/UDP | Node to Node (Bidirectional) | Data transfer between nodes within the network |
Stubby Nodes
Port | Protocol | Direction | Usage |
---|---|---|---|
443 | TCP | Node to Control plane (Outbound) | Communication with the control plane for management purposes (gRPC) |
1883 | TCP | Node to Control plane (Outbound) | Communication with the control plane for messaging (MQTT) |
Communication Modes in n2x.io
n2x.io establishes a secure communication network with end-to-end encryption between your Connected Nodes
. This network utilizes a concept called a full mesh of encrypted tunnels", enabling direct peer-to-peer communication between nodes. However, the specific way this communication occurs depends on the reachability of a specific port (TCP/UDP port 57775
) on the nodes.
Direct Connection (Preferred)
Direct connection is the preferred method for communication between nodes in n2x.io. It occurs when both nodes can directly reach each other on TCP/UDP port 57775
. This allows for the most efficient and low-latency data transfer within your network.
Indirect Connection (Fallback)
If a direct connection cannot be established due to firewall restrictions or other network configurations, n2x.io intelligently utilizes relays to facilitate communication. In this scenario, the platform chooses a suitable relay server within the network and routes communication between the nodes through it. While indirect connections may introduce some additional latency compared to direct connections, they ensure that communication remains functional even when direct paths are unavailable.