Skip to main content
Svojdani
Staff
Svojdani
Staff
April 7, 2026

Technical Tip: Configuring Secure DDNS for FortiSASE Connected Clients

  • April 7, 2026
  • 0 replies
  • 199 views
Description This article describes the issue where FortiSASE-connected clients experience secure DDNS updates being refused by the DNS server, which prevents clients from registering their DNS names. It explains the root cause of the problem and provides a detailed, step-by-step solution to resolve the issue.
Scope FortiSASE, FortiGate.
Solution

In Secure DDNS operations, the process is as follows: 

  1. Initial SOA request: 
    • The client device requests the Start of Authority (SOA) record for its own Fully Qualified Domain Name (FQDN).
    • The DNS server responds that there is no specific SOA for the client's FQDN, but confirms it is responsible for the domain.
    • The server provides its own FQDN, and the corresponding A record with its IP address.

  2. Unauthenticated update attempt: 
    • The client attempts a dynamic DNS update using a standard, unauthenticated UDP request on port 53.
    • The server rejects this update, indicating that a secure update is required.

  3. Kerberos authentication: 
    • The client contacts the domain controller (which is also the DNS server) to request a Ticket Granting Service (TGS) ticket for the DNS service on the server's FQDN.
    • The domain controller successfully grants the TGS ticket.

  4. GSS-TSIG TKEY request: 
    • The client uses the TGS ticket to generate a GSS-TSIG TKEY request over TCP on port 53.
    • The server responds successfully, providing the TSIG data.

  5. Authenticated update attempt: 
    • The client attempts the dynamic DNS update again over UDP on port 53, this time including the TSIG data as an additional record.
    • The server rejects this authenticated update, causing the process to fail.

 

FortiSASE applies SNAT to UDP DNS requests coming from FortiClient (using the FortiSASE tunnel IP), but it cannot apply SNAT to TCP DNS requests. As a result, the DNS server notices a mismatch in the source IP between Step 4 (TCP DNS) and Step 5 (UDP DNS – authenticated update) and refuses the update.

 

To resolve the issue, follow these steps:

  1. Configure a NAT policy on the SPA hub FortiGate for all DNS traffic (both TCP and UDP) coming from the FortiSASE tunnel interface and going toward the internal DNS server(s).

  2. Apply the NAT policy to the outgoing interface address, so the DNS server(s) will see a single, consistent source IP for the entire transaction.

  3. Run the command to capture the DNS traffic on the SPA hub.

    diagnose sniffer packet any "host <DNS_server_IP>" 6 0 a ​
  4. Trigger an internal domain query (nslookup xx.acm.acmdomain.com) and a Dynamic Update (ipconfig /registerdns) from the client to generate both types of traffic.

  5. Verify that the DNS server(s) see a single, consistent source IP for the entire transaction.

Related document:

DNS redirection rules 
    Terms & ConditionsAccessibility statement