Troubleshooting Tip: Unable to Access ZTNA Destinations using TCP Forwarding
Description
This article describes how to troubleshoot issues with inaccessible ZTNA destinations.
Scope
FortiGate.
Solution
The command below can be used to verify whether the EMS is authenticated
NLL_CORPORATE # execute fctems verify 1
EMS already verified.
To identify the issue :
Run WAD debug to see the output below:
diagnose wad debug enable category all
diagnose wad debug enable level verbose
diagnose wad filter src 157.x.x.x <----- Source IP of endpoint public IP on EMS portal.
diagnose wad filter dport 1423 <----- Destination port.
diagnose debug enable
[I] [p:2279][s:110520844] wad_vs_ssl_port_caps_c2p_on_client_hello:10750 15961:ZTNA-tcp-server.: wsp(0x7f8d15345048) handshake recv ClientHello record 3.1 cli
ent 3.3 supported 3.3
[V] [p:3471][s:75723206] wad_vs_proxy_match_vhost :4414 15961:ZTNA-tcp-server.: matching vhost by: 10.9.12.104
[V] [p:3471][s:75723206] wad_vs_matcher_map_find :764 Empty matcher!
[V] [p:3471][s:75723206] wad_vs_proxy_match_vhost :4417 15961:ZTNA-tcp-server.: no host matched.
[I] [p:3471][s:75723206] wad_elliptic_curve :3351 found elliptic curve 25
...
[I][p:3471][s:75723206] wad_tcp_port_on_event :1906 start processing tcp event=0x1 events=0x1 fd=12
5 n_out_block=0 state=2 close/shut=0/0 n_out_block=0
[I][p:3471][s:75723206] wad_tcp_port_on_read :1782 sock 125 read (193,3887)
[3471] read [(193,7) (15 03 03 00 02 02 2a )(......*)]
[V][p:3471][s:75723206] wad_ssl_sock_port_in_ops_read_buff:16587 sp=0x7ff83e42f798/10 len=7
[V][p:3471][s:75723206] wad_ssl_sock_port_in_ops_sync :16597 sp=0x7ff83e42f798/10 sync state=1 start
[V][p:3471][s:75723206] wad_ssl_sock_port_exec_up_forward :16270 sp=0x7ff83e42f798/10
[I][p:3471][s:75723206] wad_ssl_sock_port_exec_up_forward_txn:16251 sp=0x7ff83e42f798/10 forwarded len=7/200
[V][p:3471][s:75723206] wad_ssl_port_caps_on_dec_start :15075 sp=0x7ff83e42f798/10 dec start 0x7ff84142d428 t
ype 21 ver 0303 len 2 (02 2a )
[V][p:3471][s:75723206] wad_ssl_port_caps_on_dec_done :15100 sp=0x7ff83e42f798/10 dec done 0x7ff84142d428 ty
pe 21 ver 0303 status 0 len 2 (02 2a )
[I][p:3471][s:75723206] wad_vs_ssl_port_caps_on_alert_recv:12104 fts recv alert level=2 desc=bad certificate
[I][p:3471][s:75723206] wad_ssl_app_port_fts_in_close :17477 sp=0x7ff83e42f798/10 recv close request from ft
s close-type=0 closed=0
A bad certificate error is visible in the WAD debug logs, indicating that the endpoint does not trust the FortiGate certificate. The SSL handshake is failing to complete, which might prevent DNAT from occurring for ZTNA.
Capturing the traffic will reveal the same faulty certificate in the packet details:
Solution 1:
Navigate to EMS and edit the current ZTNA Destination profile. Under the 'Advanced' tab, check whether the 'Enforce Valid Server Certificate' option is enabled (note: this setting is disabled by default).
Disable the option and proceed with a new test. As an additional step, disconnecting and reconnecting the endpoint to EMS is recommended before retesting.
Note:
Make sure not to mix TCP forwarding and HTTPS access proxy destinations in the same ZTNA server configuration.
It is possible to enable this option, but valid certificates must be ensured on the FortiGates before activation; otherwise, ZTNA connections will fail with FortiClients supporting this feature. The server certificate presented by each FortiGate must be signed by a public CA or by a CA shared through the System Settings profile.
Solution 2:
If the 'Enforce Valid Server Certificate' option cannot be disabled, the CA certificate can be imported to the endpoints.
Navigate to EMS and edit the System Settings profile. Under the 'Other' section, enable 'Install CA Certificate on Client' and select the CA certificate that signed the server certificate used in the ZTNA server. In the example below, the 'Fortinet_SSL' certificate is used in the ZTNA server. The CA certificate 'Fortinet_CA_SSL' should be pushed to the clients.
Related article:
