|
Due to incorrect handling of HTTP2/HTTP3 requests, a FortiGate might send packets to the incorrect VIP real server.
Connections that are destined for host1.example.test might be sent to the real server host2.example.test instead but with the FQDN of host1.example.test in the ClientHello. The destination server will therefore reject the request.
The issue occurs with an example configuration as follows:
config firewall VIP
edit "example"
set type server-load-balance
set extip x.x.x.x
set extintf "any"
set server-type https
set ldb-method http-host
set extport 443
config realservers
edit 1
set ip 10.0.0.1
set port 443
set http-host "host1.example.test"
next
edit 2
set ip 10.0.0.2
set port 443
set http-host "host2.example.test"
next
end
set http-multiplex enable
set ssl-mode full
set ssl-certificate "my_certificate"
next
The problem is seen if a client opens 2 webpages with the same browser for different real server destinations behind the same VIP object.
The 1st connection to host1.example.test will load fine, while the 2nd connection to host2.example.test fails.
For the client, the 2nd connection simply times out and the page does not load.
Reloading the failing page might succeed in sending the request to the correct realserver with a correct SNI.
The issue can be seen when collecting a network capture on the FortiGate:
diagnose sniffer packet any 'host CLIENT_IP or host REALSERVER_IP' 6 0 a <----- Where CLIENT_IP is the IP of the client and REALSERVER_IP the IP address of the destination server.
To stop the sniffer in the end, press 'Ctrl+C'.
Workaround:
The workaround is to use HTTP1 'set http-supported-max-version http1' in the VIP config.
config firewall vip
edit "example"
set http-supported-max-version http1
next
end
Solution:
The solution is to upgrade the FortiGate to v7.4.8, v7.6.3 or above, where this issue is resolved in code. On v7.2.x the workaround needs to be applied to avoid the issue.
|
