ZTNA TCP forwarding access proxy without encryption example

TCP forwarding access proxy supports communication between the client and the access proxy without SSL/TLS encryption. The connection still begins with a TLS handshake. The client uses the HTTP 101 response to switch protocols and remove the HTTPS stack. Further end to end communication between the client and server are encapsulated in the specified TCP port, but not encrypted by the access proxy. This improves performance by reducing the overhead of encrypting an already secured underlying protocol, such as RDP, SSH, or FTPS. Users should still enable the encryption option for end to end protocols that are insecure.

In this example, the encryption option to access the web server on HTTP/8080 is disabled to show that traffic for an insecure connection protocol can be viewed in plain text in a protocol analyzer (such as Wireshark). In a real life application, the encryption option should be used for an insecure protocol.

You cannot use ZTNA connection rules and TCP forwarding on a Windows 7 endpoint.

To configure the ZTNA server for TCP access proxy in the GUI:

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

2. Click Create New.

3. Set Name to ZTNA-tcp-server.

4. Configure the network settings:

   1. Set External interface to port3.

   2. Set External IP to 10.0.3.11.

   3. Set External port to 8443.

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. Set Service to TCP Forwarding.

   3. Add a server:

      1. In the Servers table, click Create New.

      2. Create a new address for the winserver at 10.88.0.1 and use it as the address.

      3. Click OK.

   4. Click OK.

7. Click OK.

To configure the ZTNA rule to allow traffic to the TCP access proxy in the GUI:

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 port3.

5. Set Source to all.

6. Select the ZTNA server ZTNA-tcp-server.

7. Configure the remaining options as needed.

8. Click OK.

To configure the access proxy VIP in the CLI:

config firewall vip
    edit "ZTNA-tcp-server"
        set type access-proxy
        set extip 10.0.3.11
        set extintf "port3"
        set server-type https
        set extport 443
        set ssl-certificate "Fortinet_SSL"
    next
end

To configure the server addresses in the CLI:

config firewall address
    edit "winserver"
        set subnet 10.88.0.1 255.255.255.255
    next
end

To configure access proxy server mappings in the CLI:

config firewall access-proxy
    edit "ZTNA-tcp-server"
        set vip "ZTNA-tcp-server"
        set client-cert enable
        config api-gateway
            edit 1
                set service tcp-forwarding
                config realservers
                    edit 2
                        set address "winserver"
                    next
                end
            next
        end
    next
end

The mapped port (mappedport) is not specified so that it will map any ports that are defined in FortiClient’s ZTNA connection rule.

To configure a ZTNA rule (proxy policy in the CLI):

config firewall proxy-policy
    edit 0
        set name "ZTNA-TCP"
        set proxy access-proxy
        set access-proxy "ZTNA-tcp-server"
        set srcintf "port3"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set logtraffic all
    next
end

Test 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 details.

To create a ZTNA rule in FortiClient:

1. Go to the ZTNA Connection Rules tab and click Add Rule.

2. Set Rule Name to Webserver HTTP.

3. Set Destination Host to 10.88.0.1:8080. This is the real IP address and port of the server.

4. Set Proxy Gateway to 10.0.3.11:443. This is the access proxy address and port that are configured on the FortiGate.

5. Disable Encryption. This option determines whether or not the Client to FortiGate access proxy connection is encrypted in HTTPS.

6. Click Create.

   

After creating the ZTNA connection rule, open a browser and access the web page at http://10.88.0.1:8080.

Logs and debugs

1. The forward traffic log will show a log similar to this:

   27: date=2021-07-13 time=13:05:00 eventtime=1626206700290129558 tz="-0700" logid="0000000024" type="traffic" subtype="forward" level="notice" vd="root" srcip=10.0.3.2 srcport=61409 srcintf="port3" srcintfrole="wan" dstcountry="Reserved" srccountry="Reserved" dstip=10.88.0.1 dstport=8080 dstintf="root" dstintfrole="undefined" sessionid=46959 service="tcp/8080" proto=6 action="accept" policyid=3 policytype="proxy-policy" poluuid="fe0e1ae8-bdf9-51eb-b86f-c5e2adb934b3" policyname="ZTNA-TCP" duration=114 wanin=38471 rcvdbyte=38471 wanout=775 lanin=2450 sentbyte=2450 lanout=40643 appcat="unscanned"

2. Use the following WAD debugs to can capture the details about the connection as seen by the FortiGate WAD daemon. Notice that the HTTP request has tls=0, indicating that the proxy connection between the client and access proxy is not encrypted.

   # diagnose wad debug enable category all

   # diagnose wad debug enable level verbose

   # diagnose debug enable

   [I][p:224][s:46086][r:16777237] wad_dump_http_request             :2542  hreq=0x7f20bdaf5950 Received request from client: 10.0.3.2:62067
   
   GET /tcp?address=10.88.0.1&port=8080&tls=0 HTTP/1.1
   Host: 10.0.3.11:443
   User-Agent: Forticlient
   Accept: */*
   Cookie:
   Authorization: Basic
   …
   

   After reviewing the details, disable or reset the debugs:

   # diagnose debug reset

3. On the client PC, perform a packet capture to review the traffic flow between the client (10.0.3.2) and the access proxy (10.0.3.11) in detail. While the traffic is encapsulated in port 443, the underlying HTTP/8080 requests and traffic are decoded as clear text.

   Packet capture of traffic between 10.0.3.2:60824<->10.0.3.11:443:

   

   Traffic stream: