Created on 07-14-2023 09:33 AM Edited on 09-09-2024 07:22 AM By Jean-Philippe_P
Description
This article describes the correct order of steps required to properly deploy FortiNAC in an environment.
Scope
FortiNAC.
Solution
FortiNAC deployment can be seen as a configuration in 6 stages.
Stage 1. Licensing and VM sizing.
FortiNAC supports 3 license types: BASE, PLUS, and PRO.
The customer should be aware of which features are desired and understand which license level supports them.
Page 10 of the FortiNAC datasheet will provide the necessary information.
In FortiNAC running CentOS, it is possible to check the license level from the CLI:
licensetool
In FortiNAC-F, the license level and license status can be checked with:
get system status
get system license
It is also important for administrators to understand how Endpoint Licenses are consumed because if licenses run out, new Hosts (rogues) connecting to the network will not be able to register and gain access.
How endpoint licenses are consumed is described in Technical Tip: What consumes endpoint licenses and tracking it.
VM Sizing.
FortiNAC defines the size of the environment based on the total switch port count, not the total number of devices.
Ports in the network = total number of switch ports + maximum number of concurrent wireless connections.
Depending on the network environment size, the customer should increase VM resources (CPU, Memory, Storage) based on the number of ports in the network.
Note: Failing to respect the necessary sizing will result in FortiNAC having performance issues, such as being slow to enforce control (changing VLAN), having slow GUI operation, or not being able to access the GUI at all.
The 'VM Server Resource Sizing' section on Page 14 of the FortiNAC data sheet provides the necessary information.
In FortiNAC running CentOS, it is possible to collect sizing information from the CLI:
df -h
free -h
lscpu
In FortiNAC-F, run:
get hardware status
Technical Tip: Performance issue and some general recommendations provides further details and recommendations related to performance.
Stage 2. Define Network requirements/Configuration Wizard.
FortiNAC uses two interfaces:
Once FortiNAC is deployed and an IP has been assigned to Eth0, it will be possible to access the FortiNAC GUI.
At this point, the configuration wizard is needed to apply the full configuration, including the network type and isolation subnets.
The image below shows a summary of the Config Wizard before being applied:
It is recommended to use an L3 Network -> Layer 3 network: Routed Network with multiple scopes for each isolation network.
This way, it will be possible to scale and add Branch office networks when the network expands. FortiNAC is not an Inline solution but can sit on the edge and manage all sites.
The L3 Isolation Network is a shared state that includes all other separate states (registration, remediation ...).
So for simple deployment, only an isolation network will be required with defined scopes, which FortiNAC can provide with DHCP, DNS, and captive services, depending on the host state. This is known as state-based control.
See the diagram on page 73 of the deployment guide for an example of the necessary configuration.
The customer will need to configure at least 2 VLANs/Subnets.
Once the configuration wizard is applied, the user must reboot FortiNAC as prompted on the GUI for the changes to take effect.
Further details regarding deployment and the Configuration wizard guide are provided below:
FortiNAC configuration wizard.
Stage 3. Establish Visibility.
The Visibility stage is when FortiNAC collects information for all endpoints in the network such as connected Switch ports, SSID, AP, VLAN, etc.
To establish visibility, the customer should initially perform the following:
To add network devices, the customer needs to have an SNMP account with R/W privileges and CLI credentials.
FortiNAC uses SNMP, CLI, and a REST API (in some supported models) to model devices and read information from them to learn connected endpoints.
Example with FortiGate integration:
'Right-click' the container and select 'Add Device':
Figure 3. Adding a new device in FortiNAC.
The validate credential button should give the successful results for both SNMP and the CLI:
Important: Do not proceed with the next steps if either the CLI or SNMP returns an error or failure. If not configured properly, the customer may experience different issues such as L2/L3 polling not working, being unable to read VLANs, or FortiNAC being unable to change VLANs on the affected switch.
Depending on the switch model, FortiNAC will use different protocols/methods to read/write VLAN or learn endpoints.
Relevant documentation regarding adding devices to FortiNAC inventory:
Learning Endpoints.
FortiNAC can learn endpoints in the following ways:
Link up/link down traps sent by the switch.
Note: Configuring link up/link down in scenarios with FortiGate-FortiSwitch (FortiLink Mode) requires that the link traps appear to be sourced from the managing FortiGate, not the FortiSwitch directly. This is accomplished by enabling NAT in the applicable firewall policy on the FortiGate. See pages 25-27 of the FortiSwitch integration guide for details.
MAC learned traps sent by the switch with the MAC address (recommended method).
FortiNAC documentation below contains information on how to configure MAC notification traps for some specific Vendors:
Configuring traps for MAC notification.
Important: Only enable one endpoint learning method on network devices. If the customer enables MAC Notification traps on a network device, Link Up and Link Down traps must be disabled. They are redundant, cause additional traffic, and prevent the MAC Learned event messages from being generated on FortiNAC.
Polling network devices (manually/scheduled).
Manual/scheduled polling can be checked for the respective network device under Network -> Inventory -> Select device -> Polling.
FortiGate-FortiNAC integrations provide the ability to improve and optimize polling by using a REST API. The API key allows FortiNAC to bypass the need to authenticate every time it connects, improving performance. For this, it is necessary to create a REST API admin in FortiGate and then include the API key in the respective model configuration in FortiNAC.
In FortiNAC-F, the API key can be configured directly from the GUI by 'right-clicking' the FortiGate device model in Inventory and then selecting 'Model Configuration'. Paste the API key in the FortiGate API Token section and then select Apply.
It is also important to note that L3 devices that are added in FortiNAC will not be automatically included in the L3 polling feature. For Manual/Scheduled L3 polling to appear, the device must be included in the L3 group manually.
'Right-click' the FortiGate device model in Inventory View and select Group Membership.
Enable the 'L3 (IP->MAC)' group and select OK. After refreshing the GUI, the L3 polling entry will show up in the 'Polling' tab of the modeled device.
Integrate with Directory Services.
Integration with the directory can be used to authenticate remote users.
See the following documents for the steps:
Stage 4. Define Registration Methods.
Once a host is learned from FortiNAC, it will be marked with the Rogue(?) host state.
This means that FortiNAC has not yet categorized or profiled this device as a known device type and will keep it in the isolation subnet/registration VLAN. This way, FortiNAC will not allow access without first acknowledging what kind of device it is dealing with. This is known as State-based control and has precedence over Network Access policies, which will be configured later.
There are multiple methods to register devices depending on the scenario and customer requirements.
The most commonly used methods are provided below:
This method is beneficial in OT environments and for registering IoT 'headless' devices that have no user associated with them. FortiNAC leverages multiple methods to learn information from connected rogues and then profile or categorize them accordingly.
Device profiling rules should be prioritized as 'Already collected information' (such as Vendor by MAC, Location by traffic origin), information that might have to be read (such as an open TCP port), and information that is required to be received (such as OS information via DHCP or active scan). Already collected information has less overhead than information that needs to be collected prior to profiling.
See FortiNAC device profiler configuration for more information.
Portal Registration.
Useful for Guests/Contractors who need a limited account duration, also used for remote LDAP users.
Related documentation:
802.1x Registration.
When a customer is using FortiNAC as a local radius or proxy radius, the customer can leverage 802.1x to automatically register hosts by associating them with the logged-in user after successful authentication.
Dot1x auto registration for testing purposes can be enabled on a single port by editing the port properties as shown below:
Related documentation:
Methods that also collect application inventory:
Persistent agent:
MDM Solution (FortiClient EMS or other).
Guides:
FortiClient EMS device integration.
Third-party MDM device integration.
In some cases, customers may want to register hosts manually depending on the scenario. See this section of the FortiNAC administration guide for steps.
Stage 5. Enforce Control.
FortiNAC enforces control in two ways:
Depending on whether the host state is Rogue(?), At-Risk(+), Disabled(X), or Unauthenticated(A), FortiNAC will provide the respective captive service.
These are NOT trusted states and when enforcement is enabled for the respective state, FortiNAC will perform isolation actions.
To enable enforcement, the switch ports or SSID where hosts connect must be part of the respective system group. These groups are created by default when FortiNAC is deployed and have specific functions as described.
See this section of the administration guide for more information.
Forced Authentication Host marked with (A) |
Ports that participate in forced authentication when unauthenticated users connect. If a port is in this group when a host connects to this port and is unauthenticated, the port is put into an isolation VLAN and the host is forced to authenticate. |
Forced Registration Host marked with (?) |
Ports that participate in forced registration when unregistered hosts connect. Add switch ports that participate in forced registration when an Unregistered Host connects to the Forced Registration port group. Only ports that participate have their VLAN ID set to the Registration VLAN when an unregistered host connects. |
Forced Remediation Host marked with (+) |
Ports that participate in forced remediation VLAN switching when hosts connect. |
Physical Address Host marked with (X) |
Devices that participate in the enabling and disabling of hosts. Add switches that participate in host disabling to this group. If a host is connected to a switch that is not in the physical address filtering group, and that host is disabled through FortiNAC, the host remains connected to the network and is displayed as in violation. Add the switch regardless of whether a host is disabled through a Dead End VLAN, or through MAC address security. |
For example, Rogue(?) devices are host state enforced with the forced registration group.
Depending on the design, the customer should put all the needed ports in a port group and then make this group a member of the enforced system group.
For a simple test with one port, it is possible to go to the network device in Inventory view, select the port, and select Group Membership.
Enable membership for enforcement groups.
In the example below, a new port group was created under System -> Settings -> Groups.
Port 5 of the FortiSwitch is included in this group.
After, apply the forced registration on all members of the Test_Group_isol by making it a member of the forced registration system group.
Under System -> Settings -> Groups, edit the forced registration and select the test group to make it part of 'Forced Registration'.
This way, new ports can be added as members to 'Test_Group_Isol', and all of them will be treated with the same enforcement when the group is added to other system groups.
In wireless scenarios, FortiNAC will model switch ports where Access points are connected as Uplink ports.
All MAC addresses seen by FortiNAC in a connected uplink port are ignored. It is important to verify the validity of any uplinks defined by FortiNAC based on the number of MAC addresses learned off the port (Threshold uplink).
The Uplink port types are described in this link.
To have state-based control applied, apply group membership on the SSID itself where hosts will be connecting.
In Network -> Inventory -> Select WLC/Device -> Select the SSID tab and 'right-click' the SSID by selecting group membership.
In this case, the SSID 'Guest' has been added to the Forced Registration and 'Role based Access' system groups. This way, wireless-connected hosts will be initially isolated and be forced to register based on any method preferred and then have VLAN access dynamically changed based on their role after being registered/classified by FortiNAC.
Additionally, by modifying the 'GUEST' SSID configuration, it is possible to apply a unique configuration independent from the base model configuration of the FortiGate.
This configuration takes precedence over the base model configuration.
As seen in the entered configuration, a RADIUS Server inherited from the base model config of the FortiGate root VDOM is currently being used, but a custom Logical network configuration for Network Access is also in use.
In another SSID, it is possible to use a completely different RADIUS configuration and Access VLANs for the same logical networks.
This allows great flexibility in enforcing control by using the same logical network names for different locations.
Enforcement of groups is detailed in this guide.
The following articles provide additional information regarding State based control and troubleshooting Captive Portal issues:
Technical Tip: 'State based Control' concept and VLAN changes
Technical Tip: Captive Portal is not showing for Rogue Hosts
Control through Network Access policies.
Network access policies are applied once the host is categorized by FortiNAC and is now a known/trusted device type.
Configure the User host profile under Policy & Objects -> User/Host Profiles.
Configure Logical network in Network -> Logical networks.
Define Logical network access Value in the model configuration.
In this case, a logical network has been added in the FortiGate model configuration under Virtualized devices -> 'root' VDOM.
The Access Value VLAN 70 was assigned. At this point, hosts matching the respective policy that has the 'Guest_Network' logical configuration will be moved to VLAN 70.
To enforce control through Network Access Policies, the Port group should also be part of the 'Role Based Access' system group:
See the system groups section in the FortiNAC administration guide.
Related documentation:
Control is enforced for wireless scenarios through RADIUS where the VLAN access value is returned with an Accept-Accept response after successful authentication or through SNMP/CLI/REST_API in wired scenarios.
Note: There are cases where customers are using RADIUS for enforcement even in wired scenarios. In such cases, the SNMP/CLI account used to model the device should have READ-ONLY permissions. If accounts for SNMP have write privileges, FortiNAC may automatically change the VLAN through SNMP or the CLI, causing unexpected results and VLAN switching failures.
Stage 6. Incident Response.
FortiNAC can integrate with third-party devices to listen for their input and generate alarms that can perform actions depending on administrator needs. While collecting the information, FortiNAC will use parsers to generate events from the collected messages.
If the events generated match a security rule, an alarm will be created that can take actions such as alerting the administrator through email or disabling the affected switch ports.
See the security incident configuration guide for steps
Related documentation:
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.