Technical Tip: ZTNA access fails on the first attempt when using a wildcard FQDN

[epinheiro]

Description	This article describes the issue that ZTNA access fails on the first attempt when using a wildcard FQDN.
Scope	FortiGate, FortiClient EMS, FortiClient.
Solution	When a user initiates a connection to an endpoint via FortiClient ZTNA (e.g., host1.ztna.clients), access fails with error code 022 – ZTNA Application Not Found on the first attempt when using a wildcard FQDN as ZTNA destination. However, subsequent attempts succeed. Behavior: Wildcard DNS entries (for example, *.ztna.clients) are not resolved dynamically by the FortiGate before initial access. Error code 022 and log entries confirm that FortiGate is unable to locate the real server during the first ZTNA access. Manually resolving the host via 'execute ping' on the FortiGate or Windows CMD, or after a failed first attempt, causes the entry to be cached, and ZTNA access works correctly afterward. WAD Debug: "[I]2025-07-02 11:25:37.779493 [p:309][s:33665658][r:100663315] wad_http_req_exec_on_vs_dns_ready :12374 req(0x7f81858048) vs DNS ready: dns_resolved(1), domain_matched(0), addr_matched(0) [I]2025-07-02 11:25:37.779517 [p:309][s:33665658][r:100663315] wad_vs_log_no_server :130 677:VDI-AccessProxy: Traffic denied because failed to find a server: reason: Cannot find the real server in the API gateway., hostname: <public_IP> [I]2025-07-02 11:25:37.779549 [p:309][s:33665658][r:100663315] __wad_log_etl :443 size:463 buf:0x555d0355b7 [V]2025-07-02 11:25:37.779580 [p:309][s:33665658][r:100663315] wad_http_req_deny_vs :8319 req(0x7f81858048) Cannot find the real server in the API gateway. [I]2025-07-02 11:25:37.779599 [p:309][s:33665658][r:100663315] __wad_http_build_replmsg_resp :810 Generating replacement message. Cannot find the real server in the API gateway. repmsg_id 88" This issue has been reported to the development team (Engineering ID: #1184250) and has been resolved in the upcoming FortiOS versions 7.6.5 and 8.0.