Description
This article describes how to collect and read debug logs output from 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
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.
- 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 ZTNA Server VIP.
- FortiGate then requests a Client Certificate, which will be verified by EMS ZTNA Root CA of available EMS Connectors.
- Client provides Certificate. If it is not cached on FortiGate, its serial number is shown, and then verified by EMS ZTNA Root CA.
- Client provides Certificate. If it is found in the cache, the action taken is from the cached result.
- TLS handshake is completed with WAD and the ticket is offered to the client
- The client makes the request once the TLS handshake has been completed and authenticated using its ZTNA certificate.
- 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.
- Policy Matching continues after the source address and interface are checked.
- Device check:
- ZTNA Certificate Serial Number.
- ZTNA Tags.
- Authentication:
- Authentication Rules.
- The authentication process starts once the Authentication rule matches.
- SAML redirection and captive portal from FortiClient or External Browser is 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.
- After the authentication, the process is completed.
- FortiGate establishes the connection to the Real Server:
- Then upgrades connection, switches protocols if needed, and data starts passing between client and server protected via ZTNA Access Proxy:
