Fortinet Document Library

Version:


Table of Contents

New Features

7.0.0
Download PDF
Copy Link

ZTNA TCP forwarding access proxy without encryption example 7.0.1

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.

To configure the access proxy VIP:
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:
config firewall address
    edit "winserver"
        set subnet 10.88.0.1 255.255.255.255
    next
end
To configure access proxy server mappings:
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):
config firewall proxy-policy
    edit 0
        set name "ZTNA-TCP"
        set proxy access-proxy
        set access-proxy "ZTNA-tcp-server"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set logtraffic all
    next
end
To configure a firewall policy for full ZTNA:
config firewall policy
    edit 0
        set name "ZTNA-TCP"
        set srcintf "port3"
        set dstintf "any"
        set srcaddr "all"
        set dstaddr "ZTNA-tcp-server"
        set action accept
        set schedule "always"
        set service "ALL"
        set inspection-mode proxy
        set logtraffic all
    next
end

Test the connection to the access proxy

Before connecting, create a ZTNA rule in FortiClient.

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. Set Encryption to Disable. 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:

ZTNA TCP forwarding access proxy without encryption example 7.0.1

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.

To configure the access proxy VIP:
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:
config firewall address
    edit "winserver"
        set subnet 10.88.0.1 255.255.255.255
    next
end
To configure access proxy server mappings:
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):
config firewall proxy-policy
    edit 0
        set name "ZTNA-TCP"
        set proxy access-proxy
        set access-proxy "ZTNA-tcp-server"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set logtraffic all
    next
end
To configure a firewall policy for full ZTNA:
config firewall policy
    edit 0
        set name "ZTNA-TCP"
        set srcintf "port3"
        set dstintf "any"
        set srcaddr "all"
        set dstaddr "ZTNA-tcp-server"
        set action accept
        set schedule "always"
        set service "ALL"
        set inspection-mode proxy
        set logtraffic all
    next
end

Test the connection to the access proxy

Before connecting, create a ZTNA rule in FortiClient.

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. Set Encryption to Disable. 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: