Use FQDN with ZTNA TCP forwarding access proxy 7.0.4

When defining ZTNA connection rules on FortiClient for TCP forwarding, it is sometimes desirable to configure the destination host address as an FQDN address instead of an IP address. Since the real servers are often servers in the corporate network, this layer of obfuscation prevents internal IPs from easily leaking to the public, and also makes the destination more easily recognizable by the end users.

One obstacle to overcome is getting remote hosts to resolve an internal FQDN that is typically only resolvable by an internal DNS in the corporate network. This can be solved with the following:

1. When an FQDN address is added as a destination host in a ZTNA connection rule, FortiClient creates a virtual IP for this FQDN address and adds this to the computer’s host file (Windows). The same is true when a ZTNA connection rule entry is pushed from EMS.

2. The virtual IP mapped to the FQDN address is not the real address of the server. It allows applications to resolve the FQDN address to this virtual IP. FortiClient listens to any traffic destined for it and forwards the traffic using the TCP forwarding URL with FQDN to the ZTNA access proxy.

3. The FortiGate access proxy will resolve the FQDN using the internal DNS on the corporate network, matching the traffic to the ZTNA real server configuration with the same domain and address.

4. If a valid ZTNA real server entry is found, traffic is forwarded to the real server.

Example

In this example, two servers in the internal network are added to the FortiGate access proxy for TCP forwarding. The remote client configures two ZTNA connection rules, with the destination host field pointing to the FQDN addresses of the internal servers. These FQDN addresses are configured in the FortiGate’s DNS database so they can be resolved by the FortiGate. It is recommended to use an internal DNS server for production environments.

This example assumes that the FortiGate EMS Fabric connector is already successfully connected.

This features requires a minimum FortiClient and FortiClient EMS version of 7.0.3.

To configure the TCP forwarding access proxy:

1. Go to Policy & Objects > ZTNA and select the ZTNA Servers tab.

2. Click Create New.

3. Set Name to ZTNA_S1.

4. Configure the network settings:

   1. Set External interface to any.

   2. Set External IP to 172.18.62.32.

   3. Set External port to 443.

5. Select the Default certificate. Clients will be presented with this certificate when they connect to the access proxy VIP.

6. Add server mapping:

   1. In the Service/server mapping table, click Create New.

   2. For Service, select TCP Forwarding.

   3. Add a server:

      1. In the Servers table, click Create New.

      2. Create a new FQDN address for the HTTPS server at s27.qa.fortinet.com, then click OK.

      3. Apply the new address object as the address for the new server.

      4. Click OK.

   4. Add another server using the same steps for s29.qa.fortinet.com.

7. Click OK. Now that the ZTNA server is complete, the domain settings must be configured in the CLI to map domains to the real servers.

To map domains to the real servers:

config firewall access-proxy
    edit "ZTNA_S1"
        set vip "ZTNA_S1"
        set client-cert enable
        config api-gateway
            edit 2
                set url-map "/tcp"
                set service tcp-forwarding
                config realservers  
                    edit 4
                        set address "s27.qa.fortinet.com"
                        set domain "qa.fortinet.com"
                    next
                    edit 5
                        set address "s29.qa.fortinet.com"
                        set domain "qa.fortinet.com"
                    next
                end
            next
        end
    next
end

To configure the ZTNA rule:

1. Go to Policy & Objects > ZTNA and select the ZTNA Rules tab.

2. Click Create New.

3. Set Name to ZTNA_TCP.

4. Set Incoming Interface to port2.

5. Set Source to all.

6. Select the ZTNA server ZTNA_S1.

7. Configure the remaining options as needed.

8. Click OK.

To configure the DNS entries for each server:

1. Enable the DNS database visibility:

   1. Go to System > Feature Visibility.

   2. Enable DNS Database.

   3. Click Apply.

2. Go to Network > DNS Servers. Under DNS Database, click Create New.

3. Set DNS Zone to ZTNA.

4. Set Domain Name to qa.fortinet.com.

5. Add the DNS entries:

   1. Under DNS Entries, click Create New.

   2. Set Hostname to s27.

   3. Set IP Address to the HTTPS server address.

   4. Click OK.

   5. Add another DNS entry using the same steps for the s29.qa.fortinet.com HTTP server.

6. Click OK.

Testing the connection to the access proxy

Before connecting, users must have a ZTNA connection rule in FortiClient.

ZTNA TCP forwarding rules can be provisioned from the EMS server. See Provisioning ZTNA TCP forwarding rules via EMS for more details.

To create the ZTNA rules in FortiClient and connect:

1. From the ZTNA Connection Rules tab, click Add Rule.

2. Create a rule for the HTTPS server:

   1. Set Rule Name to server27.

   2. Set Destination Host to s27.qa.fortinet.com:443.

   3. Set Proxy Gateway to 172.18.62.32:443.

   4. Disable Encryption.

   5. Click Create.

3. Create a rule for the HTTP server:

   1. Set Rule Name to server29.

   2. Set Destination Host to s29.qa.fortinet.com:80.

   3. Set Proxy Gateway to 172.18.62.32:443.

   4. Disable Encryption.

   5. Click Create.

4. Upon creating the ZTNA rules, two new entries are added to the Windows PC’s host file in folder C:\Windows\System32\drivers\etc. View the file, and observe the new entries for the virtual IP and FQDN pairing for each ZTNA connection rule.

   # ----- FORTICLIENT ZTNA VIP START -----
   10.235.0.1 s27.qa.fortinet.com
   10.235.0.2 s29.qa.fortinet.com
   # ----- FORTICLIENT ZTNA VIP END -----

5. The Windows PC now resolves the FQDNs to the virtual IPs, and FortiClient will listen to the traffic to these IPs and forward them to the TCP access proxy.

6. Have the remote user connect to the HTTPS and HTTP servers on a browser. After device verification, the user is able to successfully connect to the remote servers.