HTTP2 connection coalescing and concurrent multiplexing for ZTNA
HTTP2 connection coalescing and concurrent multiplexing allows multiple HTTP2 requests to share the same TLS connection when the destination IP is the same, and the host names are compatible in the certificate. In ZTNA scenarios, the FortiProxy application gateway may accept multiple HTTP2 requests to the same ZTNA server destined to different virtual hosts on the same real server. These HTTP2 requests can share the same TLS connection between the FortiProxy and the real server so that the handshake does not need to be performed multiple times for multiple connections.
In order for the FortiProxy to match the SNI (Server Name Indication), this SNI value must appear under the SAN extension on the server certificate. Configuring the SNI value under the CN alone will not work. |
To configure the ZTNA access proxy:
config firewall access-proxy edit <name> set http-supported-max-version {http1 | http2} set svr-pool-multiplex {enable | disable} set svr-pool-ttl <integer> set svr-pool-server-max-request <integer> next end
http-supported-max-version {http1 | http2} |
Set the maximum supported HTTP version:
|
svr-pool-multiplex {enable | disable} |
Enable/disable server pool multiplexing. When enabled, share the connected server in HTTP, HTTPS, and web portal API gateway. |
svr-pool-ttl <integer> |
Set the time-to-live in the server pool for idle connections to servers (in seconds, 0 - 2147483647, default = 15). |
svr-pool-server-max-request <integer> |
Set the maximum number of requests that servers in server pool handle before disconnecting (0 - 2147483647, default = 0). |
Example
In this example, multiple clients submit requests in HTTP2. The requests hit the VIP address, and then FortiProxy opens a session between itself (172.16.200.6) and the server (172.16.200.99). The coalescing occurs in this session as the multiple streams share the same TLS session to connect to the same destination server.
To configure connection coalescing and concurrent multiplexing with ZTNA:
-
Configure the VIP:
config firewall vip edit "vip-ztna" set type access-proxy set extip 10.1.100.223 set extintf "port2" set server-type https set extport 443 set ssl-certificate "Fortinet_SSL" next end
-
Configure the ZTNA server and path mapping:
config firewall access-proxy edit "ztna" set vip "vip-ztna" set client-cert disable set svr-pool-multiplex enable set http-supported-max-version http2 config api-gateway edit 1 set url-map "/a" set virtual-host "a.ftnt.com" config realservers edit 1 set ip 172.16.200.99 next end next edit 2 set url-map "/b" set virtual-host "b.ftnt.com" config realservers edit 1 set ip 172.16.200.99 next end next end next end
-
Configure the ZTNA policy:
config firewall proxy-policy edit 3 set proxy access-proxy set access-proxy "ztna" set srcintf "port2" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set logtraffic all set utm-status enable set ssl-ssh-profile "deep-inspection-clone" set av-profile "av" next end
-
Get the clients to access a.ftnt.com and b.ftnt.com. The clients share access with the same real server and certificate (CN=*.ftnt.com). The FortiProxy shares the first TLS connection with second TLS connection.
-
Verify the sniffer packet capture on the FortiProxy server side. There is one client hello.
-
Disable server pool multiplexing:
config firewall access-proxy edit "ztna" set vip "vip-ztna" set svr-pool-multiplex disable next end
-
Verify the sniffer packet capture. This time, the FortiProxy does not coalesce the TLS connection, so there are two client hellos.