Technical Tip: Troubleshooting domain resolution in the the isolation network

[FortiKoala]

Description

This article describes how isolated hosts are unable to download AntiVirus/OS updates while in remediation or access certain pages. 

This can occur if certain domain names are unable to be resolved properly. 

See also related KB articles:

Captive Portal page secured with SSL certificate not building or slow to build.

Windows Critical and Security Updates scan hangs

Scope

FortiNAC v8.x, v9.x, vF7.x.

Solution

When a device is connected to an isolation VLAN (e.g., Registration, Quarantine, DeadEnd), the NAC Server/NAC Application Server acts as the DNS server. 

Upon receipt of a DNS request from the isolated host, the appliance returns the IP address of the isolation interface (eth1) unless the domain is listed on the Allowed Domains page.

If a request for a domain listed in the Allowed Domains page is received, the appliance sends a request to the customer's DNS server for resolution. 

To provide appropriate IP resolution to isolated devices for completing actions such as updating AV programs and SSL certificate authentication, this list should be updated as necessary.

Step 1: Identify which domains resolve to the isolation interface

1. Login to the appliance CLI

CentOS:  Login as root and enter:

cd /var/named/chroot/var/log/

FortiNAC-OS:  Login as admin and enter:

execute enter-shell

cd /var/named/chroot/var/log/

2. Generate a list of domains resolving to the isolation interface IP address.  Run one of the following commands:

Option 1: Generates a list of domains all isolated hosts attempted to access.   

grep PassThru named.log* | cut -d' ' -f11 | sort | uniq -c | sort -rg 

Option 2: Generate a list of domains a specific isolated host attempted to access.

grep <IP-Address-of-Host> -A1 named.log | grep PassThru | cut -d' ' -f10 |sort | uniq -c | sort -rg

Example:

grep 192.168.4.5 -A1 named.log | grep PassThru | cut -d' ' -f10 |sort | uniq -c | sort -rg

Note: 

If no results return, change the column value (-f) from 10 to 11.

3. Review the resulting list.  The most commonly attempted domains are at the top of the file along with the number of times the domain was attempted to be accessed unsuccessfully.

Output example (actual list will be much longer): 

2556 udbn4b.centralus.cloudapp.azure.com  
2276 www.msftconnecttest.com 
1584 wu-bg-shim.trafficmanager.net

Step 2: Add Domains to the Allowed Domains List.

1. Use the results from the previous step to determine which domains should be added to the Allowed Domains list for proper IP resolution. Depending upon company policies, it may not be desirable to add all the missing domains. For a list of domains, see Domains to Add to Allowed Domains List reference manual in the Document Library.
2. Add the domains to the Allowed Domains List and save.  For instructions see section Allowed domains in the Administration Guide.
3. Verify the domain resolves to the appropriate IP address the 'dig' command in the CLI.  For instructions see KB article Verify IP resolution of a domain when in isolation.

Note:   

The 'dig' command can be used to view the IP resolution of a specific domain, including any c-names used during resolution. 

Those c-names should also added to the Allowed Domains List .

Step 3: Re-Test.

1. Flush the DNS cache on the computer.  This ensures new DNS queries are sent and the domain names added to the list are resolved properly.
2. Reconnect to the portal and confirm behavior.
3. If the behavior persists, additional domains may need to be added.

Return to step 1 (Identify domains that are not resolving) to re-evaluate.