Troubleshooting Tip: How to read FortiGate WAD debugs from ZTNA TCP-Forwarding connection with SAML Authentication

[CarlosColombini]

Description

This article describes how to collect and read debug logs output from the proxy service (WAD) when a connection attempt is made using ZTNA Access Proxy TCP-Forwarding with SAML Authentication.

Scope

FortiGate running FortiOS versions 7.0+, 7.2+, 7.4+.

Solution

The following topology will be used while tracing the debug log entries.

To enable the debug level for the proxy service, the following commands may be used.

diagnose wad debug enable all

diagnose debug application samld -1

diagnose debug enable

Note.
WAD debug filters may be applied to avoid impact on FortiGate System Resources, depending on how much traffic is being proxied by this FortiGate. 

WAD debug filters can be used in many variations to narrow down the generated logs on the device. 

For example:

diagnose debug console timestamp enable 

diagnose wad debug enable category all 

diagnose wad debug enable level verbose 

diagnose wad debug display pid enable 

diagnose wad filter src 192.168.1.1 

diagnose wad filter dst 8.8.8.8

To check WAD debug status:

diagnose wad debug show 

Category: ssl

Level: verbose

Save debug on crash: disabled

Display: pid enabled

To check WAD debug filters: 

diagnose wad filter list
drop unknown sessions: disabled
source ip: 192.168.1.1-192.168.1.1
dest ip: 8.8.8.8-8.8.8.8

Debugging can be enabled with: 

diagnose debug enable 

To stop debugging: 

diagnose debug disable 

diagnose debug reset 

diagnose wad debug filter clear

In this example, FortiClient received a ZTNA Destination to RDP to server 172.16.1.10:3389 via Proxy Gateway 192.168.10.43:8887.

1. The endpoint performed an RDP connection to 172.16.1.10:3389. This connection is received from a client on the external IP and external port of the ZTNA Server VIP.

2. FortiGate then requests a Client Certificate, which will be verified by the EMS ZTNA Root CA of available EMS Connectors.

3. Client provides Certificate. If it is not cached on FortiGate, its serial number is shown, and then verified by EMS ZTNA Root CA.

4. Client provides Certificate. If it is found in the cache, the action taken is from the cached result.

5. TLS handshake is completed with WAD, and the ticket is offered to the client.
                          

6.  The client makes the request once the TLS handshake has been completed and authenticated using its ZTNA certificate.

7. The payload of requests from clients is decapsulated, and then the following checks are done in order:

• API Gateway:

Virtual Host and then Pattern.

• Real Server:

FQDN (DNS query) and IP Address.

• Route lookup to check for destination reachability (if not, likely a '504 Gateway Timeout' is presented).
• Policy match starts, and the source address and interface are checked.

8. Policy Matching continues after the source address and interface are checked.

• Device check:
  • ZTNA Certificate Serial Number.
  • ZTNA Tags.
• Authentication:
  • Authentication Rules.

9. The authentication process starts once the Authentication rule matches.

• SAML redirection and captive portal from FortiClient or an External Browser are presented:

For external browsers as user agents, saml-redirect must be enabled via CLI under saml api-gateway.

• After successful authentication with IdP and WAD, the original request is again sent with the SAML cookie.

10.  After the authentication, the process is completed.

• FortiGate establishes the connection to the Real Server:

• Then upgrades the connection, switches protocols if needed, and data starts passing between client and server protected via ZTNA Access Proxy: