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 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:
- 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, 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:
Figure 1. Configuration Wizard summary.
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.
Figure 2. FortiNAC network configuration example using the shared VLAN state called 'Isolation'.
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 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.
- All Isolation Subnet gateways in L3 Switches should have an IP-Helper pointing to Eth1 IP.
- At this point, FortiNAC will provide Isolated hosts with an IP from the defined DHCP scope in the L3 Isolation network.
- Isolated Hosts will be provided an IP configuration with the FortiNAC Eth1 IP 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 in order 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:
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:
Figure 4. Credential Configuration confirmation.
IMPORTANT: Do not proceed with the next steps if either the CLI or SNMP return 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:
- Administration guide: add or modify a device.
- Administration guide: add or modify a pingable device.
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.
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).
- 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 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.
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.
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. 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:
Device Profiler.
This method is beneficial in OT environments and for registering IoT 'headless' devices which 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 receives (such as OS information via DHCP or active scan). Already collected information has less overhead than information that needs to be collected prior 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.
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.
- 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.
Figure 9. Custom group membership for Wired ports.
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'.
Figure 10. Add custom groups to the 'Forced Registration' system group.
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 upon the number of MAC addresses learned off the port (Threshold uplink).
The Uplink port types are described in this link.
In order 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.
Figure 11. Enforcement for SSID objects.
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.
Figure 12. SSID Configuration tab.
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 same logical network names for different locations.
Enforcement of groups is detailed in this guide.
2. 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.
Figure 13. Logical Network Configuration in the model config.
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 is able to integrate with third-party devices in order 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:
