ZTNA vs IP/MAC Access Control
Overview
ZTNA vs IP/MAC Access Control
- ZTNA access proxy allows users to securely access resources through an SSL encrypted access proxy. This simplifies remote access by eliminating the use of VPNs.
- IP/MAC based access control combines IP/MAC with uses ZTNA tags for identification and security posture check to implement role-based zero trust access.
(refer to the official Fortinet documentation)
In essence, the fundamental difference between ZTNA Access Proxy and IP/MAC Access control uses case lies within the endpoints’ location and connection to on-premises network.
ZTNA Access Proxy enforces device verification and posture check (via ZTNA tags) when accessing internal resources from outside of the corporate network without VPN connection.
IP/MAC Access Control is applied to clients inside the network as well as external machines connected via VPN tunnel. Posture check and role-based access control enforced by the same ZTNA tags.
ZTNA Access Proxy
ZTNA Access Proxy relies on device’s verification via certificate authentication as well as posture check with the means of ZTNA tags.
- SSL certificate based authentication: https://docs.fortinet.com/document/fortigate/7.0.9/administration-guide/102072/ssl-certificate-based-authentication
- Endpoint posture check: https://docs.fortinet.com/document/fortigate/7.0.0/endpoint-posture-check-reference/345666/endpoint-posture-check
- Zero Trust Tagging Rules: https://docs.fortinet.com/document/forticlient/7.0.7/ems-administration-guide/937027/zero-trust-tagging-rules
Two main types of ZTNA Access Proxy are HTTPS Access Proxy and TCP Forwarding Proxy.
- ZTNA IP MAC based access control example: https://docs.fortinet.com/document/fortigate/7.0.9/administration-guide/477578/ztna-ip-mac-based-access-control-example
- ZTNA HTTPS access proxy example: https://docs.fortinet.com/document/fortigate/7.0.9/administration-guide/325639/ztna-https-access-proxy-example
One of the key differences between HTTPS Access Proxy and TCP Forwarding Proxy is how to access a protected internal resource from the endpoint.
HTTP Access Proxy protected web server is accessed via the Proxy Gateway address when navigating via the browser. The endpoint itself has to have a capacity to resolve the Proxy Gateway address which points to the FortiGate’s public facing ZTNA server.
On the other hand, TCP Forwarding protected resource can be accessed only via the Destination Host address. This address has to be resolved by the FortiGate, otherwise, the endpoint would fail to establish connection.
With the latter method, FortiClient modifies the device’s host file (https://docs.fortinet.com/document/forticlient/7.0.7/administration-guide/814327/fqdn-based-ztna-tcp-forwarding-services)
IP/MAC Access Control
Fundamental components of the IP/MAC Access Control are ZTNA tags and FortiClient’s connection relative to FortiGate.
Based on the connection – whether it’s VPN tunnel or FortiGate serving as default gateway – firewall will use either endpoint’s source IP-address or MAC-address to match the device’s traffic to ZTNA tags received from EMS. Then, the filtering will be performed based on the firewall policies.
As opposed to ZTNA Access Proxy there’s no ZTNA certificate in this architecture as the endpoints are either VPN-connected or located on-premises.
FortiGate – FortiClient\EMS Tag Sharing Mechanics
Overview – Key Points
- EMS – FortiGate communication is handled by the NAC daemon on the firewall
- FortiClient – FortiGate ZTNA server relationship is handled by the WAD daemon
- IP/MAC addresses are very important for the IP/MAC based Access Control since FortiGate uses the incoming traffic's IP/MAC information to determine which tags are associated with the endpoint making connection. Note, ZTNA doesn't require neither IP nor MAC to determine which tags are associated with endpoint establishing the connection.
- When it comes to ZTNA, FortiGate uses incoming client's certificate CN to query EMS and verify what tags are applied to client based on FortiClient’s UUID (CN of the certificate)
- The FortiClient\EMS Endpoint Sharing setting determines what endpoints' IP/MAC information is sent to the FortiGate in question:
- Share FortiClients connected to selected fabric devices - only sends IP/MAC of endpoints having FortiGate is Default Gateway
- Share all FortiClients - send IP information of all EMS-connected endpoints
- (for more information refer to https://docs.fortinet.com/document/forticlient/7.0.7/ems-administration-guide/507968/configuring-ems-to-share-tagging-information-with-multiple-fortigates)
- EMS and FortiGate communicate over API calls when it comes to Zero Trust tags and endpoint information exchange
- The two primary API endpoints discussed in this document are \tags and \sysinfo
- The \tags endpoint delivers Zero Trust tags and IP/MAC addresses of the FortiCliens having the tags assigned
- The \sysinfo endpoint delivers devices’ system information (AV signatures, FortiClient version installed, etc.)
Case 1 – FortiClient directly connected to the ‘Main FortiGate’
Topology
Overview
- For directly connected FortiClients, FortiGate sends gateway list to EMS. If the former requires further updates about tags, EMS can rely on the gateway list to identify which clients are directly connected to the firewall and send the tags associated with them. EMS retrieves the information about FortiClient endpoints’ gateways (MAC- and IP-address) via Telemetry protocol.
- For directly connected endpoints, FortiGate requests tag information in bulk. It sends its own interface’s MAC and IP (which is the gateway for the endpoints).
- FortiGate requests /tags information periodically (scheduled API call)
CLI Commands
# diagnose endpoint record list
Returns endpoint information including UUID, IP-address, FortiClient version, etc.
# diagnose firewall dynamic list
Returns both IP- and MAC-address associated with the tagged FortiClients.
# diagnose test application fcnacd 8
Returns the IP-addresses of the endpoint
Case 2.1 – FortiClient connected to the ‘Other FortiGate’
Topology
Overview
FortiClient is located behind the ‘Other FortiGate’ while the ‘Main FortiGate’ is the one that has firewall policies with the Zero Trust Tags applied.
EMS is set to share endpoints connected to ‘this fabric device’ which in this case is Other FortiGate.
Outcome:
EMS won’t share neither IP information associated with tagged FortiClients nor endpoint information with the Main FortiGate.
CLI Commands
# diagnose endpoint record list
Returns no records related to endpoint information.
# diagnose firewall dynamic list
Returns no IP - tag information associated with the endpoints.
Case 2.2 – FortiClient connected to the ‘Other FortiGate’
Topology
Overview
FortiClient is located behind the ‘Other FortiGate’ while the ‘Main FortiGate’ is the one that has firewall policies with the Zero Trust Tags applied.
EMS is set to share all endpoints connected to it.
Outcome:
EMS will send IPs associated with all tagged FortiClients connected to it.
EMS won’t send any endpoint information to the Main FortiGate.
Remember: The FortiClient\EMS Endpoint Sharing setting only affects the /tags API endpoint (not /sysinfo endpoint).
CLI Commands
# diagnose endpoint record list
Returns no records related to endpoint information.
# diagnose firewall dynamic list
Returns all IP-addresses associated with the tagged FortiClients behind Other FortiGate.
Case 3 – FortiClient connects via ZTNA to ‘Main FortiGate’
Topology
Overview
Current example is a common scenario for FortiSASE deployments.
FortiSASE establishes Fabric Connector with on-prem FortiGate. FortiClient connects via full-tunnel VPN to FortiSASE.
Once FortiClient attempts to establish connection to ZTNA server, FortiGate extracts client ZTNA certificate’s CN and performs an API call to the FortiSASE’s API endpoint to retrieve zero trust tags associated with the machine. Besides, FortiGate also retrieves endpoint information via including ZTNA certificate’s S/N, AV signatures, FortiClient version, etc.
CLI Commands
# diag firewall dynamic list
No entries for the remote endpoint since FortiGate doesn’t use IP/MAC information for ZTNA server connections.
# diag endpoint record list
Will depict endpoint’s information including IP-address (VPN), UUID, certificate SN, public address etc.
# diag test application fcnacd 7
Shows cached information about FortiClients initiated ZTNA connections to FortiGate (endpoints’ UUIDs, certificates' S/N, tags)
# diagnose wad worker policy list
Lists the ZTNA rules. Helpful to check whether a ZTNA policy gets a hit (shows the traffic volume associated with the ZTNA policy).
# diag wad debug enable category policy
# diag wad debug enable level verbose
# diag debug enable
The above commands will output the logs of a on-going ZTNA connection. Helpful to see the process of ZTNA rule matching on initial connection attempt.
Case 4 – FortiClient connected to the ‘Main FortiGate’ via VPN
Topology
Overview
Upon FortiClient’s VPN connection to the Main FortiGate, firewall's VPN daemon chains UUID information of the FortiClient to the fcnacd application that handles fabric communication with EMS. That process makes an API call to retrieve tags as well as endpoint information about connected FortiClient based on the UUID.
On VPN disconnection, FortiGate clears the address table for the endpoint (#diag firewall dynamic list) as well as endpoint’s information (#diag endpoint record list).
CLI Commands
# diag endpoint record list
EMS will send endpoint’s information including VPN interface’s IP-address
# diag firewall dynamic list
The command will show the FortiClient's VPN interface IP-address associated with the endpoint’s tags.
# diag test application fcnacd 8
The output will be the list of IP-addresses associated with machines having tag information sent by EMS.
ZTNA Endpoint Component - FortiClient
FortiClient Connection to Network Resources
Overview
FortiClient plays a role of an agent compliance of which will dictate whether access to the internal resource is allowed or prohibited (IP/MAC-based access or ZTNA server access).
With the ZTNA architecture, FortiGate first verifies the identity of the client – ZTNA certificate (S/N), and then checks its compliance aka what tags belong to the client. The action will be performed based on the configured ZTNA rules.
With IP/MAC-based, FortiGate will act upon the information received from EMS (MAC- and/or IP-address) and tags associated with them.
FortiClient’s ZTNA Certificate
ZTNA certificate is the result of initial registration to EMS. FortiClient sends the CSR request which gets signed vis EMS ZTNA CA certificate.
On Windows, the ZTNA certificate is stored in the personal user certificate store.
On MacOS, the certificate is located under the Keychain Access > login > Certificates.
The communication with EMS regarding the certificate retrieval can be traced via FortiClient’s debug FortiESNAC logs (Windows) and epctrl (Mac).
FortiClient Zero Trust Tags
On the FortiClient console, the zero trust tags can be viewed under the user’s avatar.
Zero Trust tagging rules are created on EMS. EMS sends these rules to FortiClient which performs the calculation of whether the system matches the rules. The result is the bitmap that the endpoint sends back to EMS via Telemetry protocol. EMS evaluates the bitmap and sends the final result of what tags the machine should have.
Evaluation of the tagging rules as well as communication with EMS can be tracked via the FortiClient's debug FortiESNAC logs.
FortiClient ZTNA FQDN-based TCP Forwarding proxy
When configuring FQDN-based ZTNA Forwarding Proxy connection rule, FortiClient modifies the host file of endpoint. 
The IP-addressing scheme is 10.235.0.1, 10.235.0.2, etc.
When accessing the resource via the Destination Host address, FortiClient sends the following request to the FortiGate:
https://172.31.200.244:9833/tcp?address=win.rdp.fortitest.net&port=3389&tls=0
If FortiGate can resolve the DNS name, then it sends the response to proceed with the tunnel establishment. In case FortiGate can’t resolve the DNS name the connection won’t be established.
For deeper analysis and troubleshooting of the above, one can enable debug log level for the endpoint and add the following processes to the list of log events: transctrl, fortitcs. (https://docs.fortinet.com/document/forticlient/7.0.7/xml-reference-guide/921514/log-settings)
These logs will be included into the FortiClient's diagnostics output file.
Troubleshooting
For troubleshooting examples one can refer to the "ZTNA and IP/MAC Access Control: Troubleshooting" FortiAnswers article.
