Description
This article describes an example of how to set up FortiNAC and Persistent Agent communication in a simplified network.
Scope
FortiNAC and Persistent Agent.
Solution
- Network design and IP planning.
Below is an example of a network diagram when FortiNAC is deployed as a L3 routed (recommended and most used type):
FortiNAC can apply these network configurations by following the configuration steps in ConfigWizard:
- Configuring port1 (management interface):
- Configuring port2 (isolation interface) and DHCP pools with network details for isolation networks. In smaller setups, to simplify the configuration, only the Layer 3 Isolation can be configured to handle all types of isolated hosts. In larger setups, using a dedicated remediation network may be required.
The service 'nac-agent' at the interface level configuration needs to be allowed for both ports, as shown below (in FortiNAC CLI):
config system interface
edit port1
set mode static
set ip 10.6.2.61/24
set allowaccess http-adminui https-adminui nac-agent ping radius-auth snmp ssh
edit port2
set mode static
set ip 0.0.0.0/0
set allowaccess dhcp dns http https nac-agent ping
Note:
It is important that the Agent (installed in the end host) can always reach FortiNAC (isolation or management interface). If the end host ends up in a subnet/VLAN that can not reach FortiNAC, the host status may remain in the old state (At-Risk and not communicating), which may affect the policy evaluation and end up in a locked state with no network communication.
To temporarily solve this, all the hosts can be marked as safe by going to System -> Settings -> Control -> Quarantine and applying Set all hosts 'Risk State' to 'Safe'.
The host status can be checked from Admin UI or CLI with the following command:
diagnose host list host-name Win11-Sop | grep Status
Status = Security_Risk_Connected_AgentNotCommunicating
The end user will be presented with a portal page, showing the reason for the isolation, the parts of the Scan that are failing, instructions to follow (optional), and a button to trigger a rescan of the system after the conditions are met. Typically, the remediation steps may require Operating System or Antivirus updates, specific configurations, or processes running/not running in the end host.
-
Agent installation on the end host.
Usually, the agent deployment in the end host is done through the use of Software management programs (like GPO). Captive portal or manual installation (Technical Tip: Manually install and configure 'Persistent Agent' on Windows OS) can also be used, more information can be found there: Deployment Methods.
-
Agent discovering FortiNAC server.
Agent communication can be considered as a standard client-server communication. The connection is started from the client (Agent), and for this, the agent should be able to discover the domain/IP of the FortiNAC server.
- While the host is in an isolation network, FortiNAC will offer DHCP and DNS services, and the agent can auto-discover the IP/domain of FortiNAC (isolation port) through the built-in SRV DNS records in the DNS service. If required, this can be checked from the CLI:
execute enter
cat /var/named/chroot/etc/domain.zone.isol
...
_bradfordagent._tcp SRV 0 0 4568 fnac76.eb.lab.
*.isol.eb.lab. IN A 10.6.3.61
-
When the host is moved to the production network, certain configurations are required to allow the Agent to discover the FortiNAC server domain and reach the management port IP.
A similar approach can be followed to add this information as SRV records in the production DNS server. This procedure is covered in detail in this article: Technical Tip: Agent DNS records (SRV) and checks on Microsoft environment. Alternatively, this information can be manually configured in the end host or pushed through a central management system, more details can be found in Persistent Agent on Windows of the Administration Guide.
Note:
It is important to notice that while the host resides in a production subnet/VLAN, it should discover and reach FortiNAC in the management port and not in the isolation port. This will make sure not to cause any routing issues.
-
Common misconfigurations and troubleshooting commands.
The Agent logs on the end host contain a lot of useful information to help troubleshoot any possible misconfiguration. More information on how to access and read the logs can be found in this article: Troubleshooting Tip: Agent logs on end hosts.
- Service status.
Verify that the service is running under the name 'FortiNAC Persistent Agent Service'. The service can also be restarted each time there is a configuration change to speed up the communication process:
-
The end host is not able to reach FortiNAC.
Check the registry editor on the end host and verify that the 'ServerIP' and 'lastConnectedServer' are showing the right values. Make sure that the end host can resolve the domain to IP and there is no network limitation (routing or firewall) that blocks the connection (TCP port 4568) to FortiNAC. The path is: 'Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Bradford Networks\Client Security Agent'.
The Agents packet exchange can also be checked from FortiNAC CLI with the following command (replace x.x.x.x with the IP of the end host):
execute tcpdump -i any port 4568 and host x.x.x.x -v
11:44:13.188622 port2 In IP (tos 0x0, ttl 127, id 30726, offset 0, flags [DF], proto TCP (6), length 52)
10.6.250.11.57896 > isolation.isol.eb.lab.4568: Flags [S], cksum 0x02d8 (correct), seq 3804530989, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:44:13.188665 port2 Out IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
isolation.isol.eb.lab.4568 > 10.6.250.11.57896: Flags [S.], cksum 0x117b (incorrect -> 0xa1a1), seq 3052317495, ack 3804530990, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
11:44:13.189111 port2 In IP (tos 0x0, ttl 127, id 30727, offset 0, flags [DF], proto TCP (6), length 40)
10.6.250.11.57896 > isolation.isol.eb.lab.4568: Flags [.], cksum 0xd962 (correct), ack 1, win 1026, length 0
-
IP connectivity is verified, but the connection is not started.
A valid certificate needs to be applied for the Agent service in FortiNAC. Using the built-in self-signed certificate is not supported; some details are shown in the SSL certificates of the Administration Guide. Usually, a certificate generated from a private CA is sufficient as long as the end host has that root CA in their Trusted Root CA Store. In case the trust chain includes other intermediate CAs, those need to be uploaded together with the certificate. The trust chain can be checked in the 'Certificate Hierarchy' drop-down field:
More details on how to troubleshoot certificate issues are shown in this article: Technical Tip: Persistent Agent fails to communicate with 'SSL_get_verify_result' log entry.
-
The host is using a NIC that is considered an invalid OUI.
This scenario can be checked further by enabling the following debug in FortiNAC CLI:
diagnose debug plugin enable PersistentAgent
diagnose tail -F output.nessus | grep "Invalid OUI"
More details on how to troubleshoot this scenario can be found in this article: Troubleshooting Tip: Persistent Agent not able to start communication.
Related articles:
Troubleshooting Tip: Agent logs on end hosts
Technical Tip: Agent DNS records (SRV) and checks on Microsoft environment
Technical Tip: Monitor Custom scans to ensure a quicker response to host compliance
Technical Tip: Notify when a host is at risk state
Technical Tip: An example of a simple network deployment of FortiNAC with FortiGate/FortiSwitch
Technical Tip: Comprehensive guide for a simple FortiNAC deployment
Technical Tip: How to download the FortiNAC Persistent Agent and Dissolvable Agent
Troubleshooting Tip: New vendor OUI missing from the database
