4.7.2.3. Architecture
This section outlines the necessary nodes for the use case, offering essential information on its architecture, including components, simplified architecture, and recommended sizing.
4.7.2.3.1. Components
2SRA module deployment requires a Backend composed of additional components; the integration and users authentication with the corporate identity manager, the management of the GAuth OTP, the centralization of logs, traffic monitoring, among others.
4.7.2.4. ON Core
ON Core provides the centralized management console of the solution. It is where the Visibility policy engine for discovery resides. This device runs the logic that processes and validates asset profiling based on multiple conditions and characteristics. It also runs plugins to enrich profiling in a active or passive way.
It is a mandatory component of the solution and includes critical components such as:
Policy Engine: It is the solution’s brain. All modules are implemented using this component.
CMDB: It is the memory of the solution where all the configuration, assets and its features are saved.
VPNGW: Allows the remote centralized management of the VPN Gateway nodes and its configuration.
The administration portal is the control panel for the solution.
Note
It is a critical component in the solution. The implementation of one or more nodes will depend on the requirements of the deployment, and the final architecture design to provide high availability.
If this component is offline, we would not be able to stablish VPN connections, authenticate users, etc.
4.7.2.5. ON Analytics
ON Analytics is based on the ELK Stack, receives the platform logs, structures, metadata and builds the datalake to show dashboards and reports in real time to allows the specific searches.
It is a mandatory component of the solution that includes non-critical components such as:
Aggregator: an enrichment of all the information generated by any component of OpenNAC Enterprise.
Search Engine: based on an elastic search engine that allows you to easily search the information generated and collected by the OpenNAC Enterprise components.
Dashboards and reports: The solution includes a set of dashboards and reports based on common technical information gathered. You can create and generate your own custom dashboards.
Note
ON Analytics is a non-critical component for the solution, therefore, it does NOT require high availability. The implementation of one or more nodes will depend on the requirements of the deployment, and the final architecture design. If this component is outlined, the main functionality of OpenNac Enterprise modules would continue working, with the exception that during the outlined period we would no longer have the ability to process and display the information of the solution.
In deployments where a large amount of data is generated, it may be necessary to deploy multiple Analytics nodes to load balancing the storage. Analytics has two types of roles, typically within the same node, a role with aggregation functions (Aggregator) that receives information through Filebeat and process logs with Logstash, the other role (Analytics) with data management functions performed by ElasticSearch and visualization through Kibana.
4.7.2.6. ON Agent
The Agent is a software that is installed in the end for VPN connection establishment, monitoring and the hardware/software posture of the device. It is required for the Secure Remote Access (2SRA) module.
Allows you to manage and perform a detailed analysis of the device inventory (for example, OS patches, health and security features, deployed applications, etc.)
Establishment of the VPN tunnel, and validation of credentials using 2FA. 3. ON Agent
4.7.2.7. ON Sensor
ON Sensor is based on IDS technology, it processes the traffic generated in the network. Performs a deep analysis of network protocols that are being used by ingesting the traffic through a port-mirror (SPAN, RSPAN or ERSPAN).
It is an optional component that provides:
Network Behavior Monitoring. Provides metadata of network traffic that is captured by copying the traffic through the port-mirror configured on the network device. It is capable of decoding multiple standard protocols and applications, providing information from layer 2 to layer 7.
Note
ON Sensor is is a non-critical component for the solution, therefore, it does NOT require high availability. If this component is outlined, the main functionality of OpenNAC Enterprise modules would continue working, with the exception that during the outlined period we would no longer have the ability to have advanced visibility, analysis and monitoring of network behavior.
4.7.2.8. VPNGW
The VPN Gateway provides the ability to establish the VPN from a remote location to the corporate network. It maintains the system update packages and the object base (networks, hosts, protocols, means of authentication, etc.) to distribute among the different VPN Gateways.
The Administration Portal VPNGW module provides the centralized management of all the VPNGW nodes.
It is a mandatory component for the Secure Remote Access (2SRA) module, which includes critical features such as:
Manage VPNGW: This section allows you to manage the VPN Gateway nodes, configure workers and also manage the OpenVPN, WireGuard and Shorewall protocols.
CMDB: From this section you can manage your Objects, Radius authentications, Certificate authorities, and Server certificates.
FARM: This section allows you to manage and configure the nodes that you have previously created in the “Manage VPNGW” section.
Note
It is a critical node in the solution and high availability deployment is recommended. The deployment of one or more nodes to provide high availability will depend on the deployment requirements, and the final architecture design. With this module offline we would lose the ability to establish VPN connections
4.7.2.8.1. Standard Architecture
A reference architecture requires the components described above and depends on the network architecture available to the customer, as well as the number of end users on the network. Based on the criticality of the components and location in the network, the following should be considered points:
The VPN Gateway needs to have internet access for clients to connect. It is the only component that needs to be exposed to the internet, and it is recommended to install it in a DMZ network separate from the published, internal servers, and the others solution components.
4.7.2.8.2. Hight Availability Flow
In any robust and reliable system, ensuring uninterrupted access and seamless operation is crucial. High Availability (HA) refers to the ability of a system or infrastructure to remain operational and accessible, even in the face of hardware or software failures, network issues, or other disruptive events. It involves creating a resilient architecture that can handle failures and seamlessly switch to alternative resources or nodes
Understanding this flow will provide insights into how High Availability is achieved in the 2SRA use case, ensuring reliable connectivity and continuity for critical network services.
Note
Deployment in high availability will depend on the customer’s requirements. If a HA deployment is required, it will be necessary to add additional components (two or more VPN Gateways).
Configure the Agent profile by specifying the Farm ID you want to connect to. This ID ensures that the Agent device seamlessly integrates with the correct Farm.
Create a Farm.
Add the nodes to the Farm, and the Farm synchronizes configurations across the nodes, guaranteeing consistency and optimal functioning within the Farm environment.
The Agent device initiates a connection request to the network using the configured Agent profile.
The authentication process is triggered to verify the identity and authorization of the Agent device.
The Farm employs a load balancing algorithm to randomly assign the authentication request to an available node within the Farm.
The assigned node performs the authentication process, validating the Agent device’s credentials, and allows the connection.
To ensure the stability and correctness of the connection, a periodic handshake protocol is implemented every 3 minutes.
In the event of a lost connection, the Agent device initiates a reconnection process.
The reconnection process follows the entire flow anew, with the Farm randomly reassigning the request to a different available node within the Farm.
Once a new node is assigned, the authentication and connection process resumes seamlessly, ensuring uninterrupted network connectivity.
4.7.2.8.3. Standard Sizing
Based on the reference architecture, the standard sizing of the solution for 2SRA module to support up to 1.500 network users and average traffic of 400kbp.
4.7.2.8.3.1. Sizing
Concurrent user growth is achieved by adding more nodes in an N + 1 scheme through a RADIUS proxy or load balancer.
Component |
Number |
CPU |
Memory |
Disc/Type |
Network Int. |
|---|---|---|---|---|---|
VPN Gateway |
4 Cores |
8 GB |
100 GB/SSD |
2 NIC** |
|
ON Core |
8 Cores |
16 GB |
160 GB/SSD |
2 NIC** |
|
ON Analytics |
8 Cores |
16 GB |
300 GB/SSD |
2 NIC** |
|
ON Sensor |
8 Cores |
16 GB |
100 GB/SSD |
|
|
ON Agent |
N |
Note
** The 2 network interfaces are mainly for service and management (internal communication between the different nodes)
*** In some cases, it is recommended to have at least 2 NICs for active-passive port-span.
4.7.2.8.4. Component flows
The following tables outline the firewall rules for the nodes involved in the 2SRA use case:
ON CORE
Resources |
Minimum |
Recommended |
|---|---|---|
Memory |
16 GB |
64 GB |
CPU |
8 CPU |
16 CPU |
Disk Size |
200 GB |
200 GB |
Disk Type |
SCSI/SATA |
SSD |
Network |
2 NIC** |
2 NIC** |
Note
** The 2 network interfaces are mainly for service and management (internal communication between the different nodes)
4.7.2.8.5. Administration Portal
The machine that holds the Administration portal is the ON Core. This administration portal serves as the primary interface for configuring, operating, and monitoring OpenNAC Enterprise technologies.
For more information, see the Administration Portal section.
4.7.2.8.6. Installed Packages
This section provides a comprehensive list of installed packages on the ON Core component, along with their respective descriptions. These packages play a crucial role in supporting various functionalities and services, ensuring a robust and efficient operating environment.
ON ANALYTICS
The dimension of Network Access solution infrastructure can be directly inferred from the expected workload in terms of users, IPs, types of authentication or use cases deployed that the NAC must sustain. The workload may be complicated to estimate, but this is a crucial exercise to build an efficient NAC Architecture. In general, you can increase its capacity by adding more nodes of some components. The current user’s growth is achieved by adding more nodes in an N + 1 scheme through a load balancer.
When the network requires capturing 10 Gb, it will be necessary to implement hardware sensors with cards compatible with accelerated drivers from pFring.
The hardware specifications for ON Analytics are:
Resources |
Minimum |
Recommended |
|---|---|---|
Memory |
16 GB |
64 GB |
CPU |
8 CPU |
16 CPU |
Disk Size |
200 GB |
According to the architecture |
Disk Type |
SCSI/SATA |
SSD |
Network |
2 NIC |
2 NIC** |
Note
* It depends on the amount of information that needs to be stored.
ON SENSOR
The dimension of Network Access solution infrastructure can be directly inferred from the expected workload in terms of users, IPs, types of authentication, or use cases deployed that the NAC must sustain. The workload may be complicated to estimate, but this is a crucial exercise to build an efficient NAC Architecture. In general, increased capacity is achieved by adding more nodes of some component. The current user’s growth is achieved by adding more nodes in an N + 1 scheme through a load balancer.
When the network requires capturing 10 Gb, it is necessary to implement hardware sensors with cards compatible with accelerated drivers from pFring.
The minimum recommended specs for the ON Sensor are:
Resources |
Minium |
Recommended |
|---|---|---|
Memory |
16 GB |
64 GB |
CPU |
8 CPU |
16 CPU |
Disk Size |
200 GB |
300 GB* |
Disk Type |
SCSI/SATA |
SSD |
Network |
2 NIC and 1 NIC*** |
2 NIC and 1 NIC*** |
Note
* It depends on the amount of information that needs to be stored. *** In some cases, it is recommended to have at least 2 NICs for an active-passive port-span.
Supported Network Cards
Capacity |
Medium |
Network Card |
|---|---|---|
1Gb |
Copper |
Intel 8254x/8256x/8257x/8258x |
1Gb |
Fiber |
Intel 82575/82576/82580/I350 |
10Gb |
Fiber |
Intel 82599/X520/X540/X550 |
40Gb |
Fiber |
Intel X710/XL7100 |
Installed Packages
ON VPNGW
4.7.2.8.7. Sizing an OpenNAC VPNGW
The dimension of Network Access solution infrastructure can be directly inferred from the expected workload in terms of users, IPs, types of authentication or use cases deployed that the NAC must sustain. The workload may be complicated to estimate, but this is a crucial exercise to build an efficient NAC Architecture.
The hardware specifications for the VPN Gateway are:
Resources |
Minimum |
Recommended |
|---|---|---|
Memory |
16 GB |
32 GB |
CPU |
8 CPU |
16 CPU |
Disk Size |
200 GB |
200 GB |
Disk Type |
SCSI/SATA |
SSD |
Network |
2 NIC |
2 NIC** |
Note
** The 2 network interfaces are mainly for service and management (internal communication between the different nodes).