Technical Tip: ZTNA not working with SSL VPN on macOS devices

[jwadada]

Description	This article describes an issue that can occur where FortiClient-managed macOS devices are unable to access internal resources when ZTNA tags are used in VPN firewall policies.
Scope	FortiGate, FortiClient EMS, FortiClient.
Solution	After a VPN client connects to SSL VPN, it must resolve the fully-qualified domain name (FQDN) of the EMS server to re-establish a connection (e.g., ems.example.com). To do this, macOS clients will generally utilize only DNS servers specified by the SSL VPN settings. If the DNS server is on premises or the tunnel is configured for full-tunnel routing, the DNS request must traverse through the FortiGate and its firewall policies. If ZTNA IP tags are applied to the SSL VPN Firewall Policies handling DNS traffic, this leads to a circular issue where the macOS client is unable to reconnect to the EMS server after connecting to the VPN. The client is attempting to resolve the FQDN of the EMS server so that it can reconnect and update the ZTNA tag information with the new VPN IP address. To do this, it sends traffic over the VPN towards the DNS servers specified by the SSL VPN. The ZTNA information on EMS and the FortiGate is not yet updated to reflect the client's new SSL VPN IP addressing information, so any policies that utilize ZTNA tags will not allow the client's traffic. The DNS traffic is dropped, so the client is never able to connect to EMS to update the ZTNA information. Workaround: To workaround this issue, the recommendation is to create a separate firewall policy for the DNS traffic without any ZTNA tags applied. This ensures VPN clients are able to successfully resolve the EMS FQDN even before the ZTNA tag information is updated. config firewall policy     edit <index>         set name "SSL VPN_DNS Traffic"         set srcintf "ssl.root"         set dstintf "lan"         set action accept         set srcaddr "SSLVPN_TUNNEL_POOL"         set dstaddr "h-10.255.0.11/32"         set schedule "always"         set service "DNS"         set groups "SSL VPN Users"     next end If client telemetry traffic to EMS (TCP port 8013) passes through the firewall, it must also be processed by firewall policies that do not require a ZTNA tag. Similar issues can affect similar firewall configurations. For example, if full tunnel is in use, Windows Clients may experience the same EMS FQDN lookup failure. If IPsec VPN is used for remote access and ZTNA tags are used on associated firewall policies, macOS clients may have the same issue as with SSL VPN. Related document: ZTNA IP MAC based access control example