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.
- Define network environment size and choose the correct licensing depending on the features needed.
- Define network requirements, isolation subnets (Configuration Wizard).
- Establish Visibility.
- Define Registration Methods.
- Enforce Control.
- Incident Response.
Stage 1. Licensing and VM sizing.
- Licensing.
FortiNAC supports 2 license types: 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.
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 provide further details and recommendations related to performance.
Stage 2. Define Network requirements/Configuration Wizard.
FortiNAC uses two interfaces:
- Eth0/ Port1 (FortiNAC-F) - used for visibility, control and management.
- Eth1/ Port2 (FortiNAC-F) - used to provide DHCP, DNS and Captive Services based on the host state in isolation.
Once FortiNAC is deployed and an IP has been assigned to Eth0/port1, it will be possible to access the FortiNAC GUI on:
https://<FortiNAC IP Address>:8443/
https://<FortiNAC Host Name>:8443/
At this point, access the configuration wizard to apply the full configuration, including the network type and isolation subnets.
Any further changes in terms of routing or system configuration are all performed through the Configuration Wizard. Do not make routing or Interface IP address changes through CLI or shell. Everything is done automatically by reapplying the Configuration Wizard each time a change is required.
As isolation network DHCP scopes are configured, static routes are automatically created for those networks, specifying the gateway for the corresponding port2 interface or sub-interface.
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 a 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.
- Stub VLAN: this is where the FortiNAC isolation interface resides.
- Isolation VLAN: this is where FortiNAC will put Rogue hosts (not profiled hosts) (FortiNAC eth1 IP could also reside in this network).
- The FortiNAC Eth1 IP address will act as a DHCP and DNS server for all added Isolation subnets.
- The routed VLAN interfaces in Isolation should be configured through ACL to speak only with Eth1 IP address.
- All Isolation Subnet gateways in L3 Switches should have an IP-Helper pointing to Eth1 IP address.
- At this point, FortiNAC will provide Isolated hosts with an IP address from the defined DHCP scope in the L3 Isolation network.
- Isolated Hosts will be provided an IP configuration with the FortiNAC Eth1 IP address acting as a DNS server.
- All HTTPS/HTTP requests from these hosts will be filtered to FortiNAC, which presents the captive portal to them for registration/mediation depending on the host state (Rogue/At-Risk).
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 are provided below:
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:
- Create Containers.
These are logical groupings of network devices. For example, it may be necessary to create a container for firewalls where all branch firewalls are added, then create another container for L2 Switches etc. This way, the customer has better organization of network equipment in the inventory view. See the administration guide for more information about containers. - Add Network devices.
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.
- FortiNAC listens for traps from that device. When FortiNAC receives a linkup trap, it polls the switch to read the available host information.
- It may result in being resource-intensive.
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).
- MAC Notification Traps are traps that send host information when the host connects or disconnects without FortiNAC needing to poll them.
- This is less resource intensive and also provides a faster FortiNAC database update with host information.
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.
- Contact Status Polling - This is a ping that FortiNAC performs against the switch to check if it is online.
- Layer 2 (L2) polling - FortiNAC reads the network device's MAC address table.
- Layer 3 (L3) polling - FortiNAC reads the network device's ARP table.
Figure 5. FortiNAC polling tab.
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.
Figure 6. API token configuration for the FortiGate model.
It is also important to verify 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.
Figure 7. Group membership for Network Inventory Devices.
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.
- User records are created in FortiNAC in the moment the host where it logs in, registers on the network and FortiNAC finds the user in the LDAP directory.
- An example would be a Host registering to a User through 802.1x or through the Persistent Agent. During the registration process FortiNAC will collect user information and look it up in the LDAP directory. If it finds the user, it associates it with the Host record and then creates the user record in User & Hosts -> User Accounts.
- Manually created user IDs (local user) with an ID that is the same as a user in the directory, will be overwritten by the directory data. It is important to have unique Local Admin users that do not match the user ID in LDAP. If this happens, the user might experience registration issues and unexpected policy enforcement.
- "Select groups tab" in LDAP configuration - The groups selected here are only used in order to select Group membership filtering when applying Network Access Policies. Each time a user registers to the host, FortiNAC will make that Host Member of the Group selected for sync. Only the selected groups for sync can be used for policy matching criteria.
- "Search branches tab" in LDAP configuration - This tells FortiNAC where the user and group information is located in the Directory. If the filter is too narrow, FortiNAC will not be able to locate Users and this will fail the registration/authentication process.
See the following documents for the steps:
- FortiNAC administration guide - configuration.
- FortiNAC administration guide - directories.
- Technical Tip: Best practices for LDAP configuration.
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.
There are multiple methods to register devices depending on the scenario and customer requirements.
The most commonly used methods are provided below:
- Device Profiler.
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:
- Guest contractor templates - FortiNAC administration guide.
- Technical Tip: FortiNAC guest captive portal configuration.
-
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:
Figure 8. Dot1.X Auto registration setting for individal port.
Related documentation:
- Local RADIUS server - FortiNAC documentation
- Wired devices and 802.1x - FortiNAC administration guide
- WiFi 802.1x-based network using FortiNAC local radius server - FortiNAC 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:
- State-based control.
- Network Access Policies.
- State-based Control.
Depending on whether the host state is Rogue(?), At-Risk(+), Disabled(X), or Unauthenticated(A), FortiNAC will provide the respective captive service.
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.
- Enforcement on Wired Ports.
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.
- Enforcement for Wireless Scenarios.
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.
- NAC policies will be applied to guests depending on the filters defined in the user/host profile.
- Once a host matches a policy, the configuration attached will be applied. The configuration is associated with a logical network defined in the model configuration of the device where the host is connected. The logical networks contain VLAN access values, which can be different on each device model configuration. This will result in fewer NAC policies and greater ease of administration when organizing policies for control.
- Once a policy is matched, FortiNAC will apply the local configuration to the port, which will result in a VLAN change.
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 documents:
Network access - FortiNAC administration guide.
Implementation - FortiNAC administration guide.
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 documents:
