Chapter 1: What’s New
This chapter lists features and enhancements introduced in the FortiADC 7.4.0 release.
Global Load Balance
DNSSEC signing method upgraded to 1024/2048/4096 bit keys and added new algorithms
Previously, the DNSSEC signing method was defaulted to 512 bit key and RSASHA1 algorithm. In FortiADC7.4.0, the available key sizes and algorithms have been expanded to include 1024/2048/4096 bit keys and a total of six algorithms.
Note: Configurations carried over from previous versions can continue to use the 512-bit key, however, we recommend updating the DNSSEC signing method to the new 1024/2048/4096 bit keys as the 512-bit key is less secure and is no longer supported in the latest BIND 9 version.
For details, see Configuring DNS zones.
Minimal-Responses option in GLB general settings
You can now enhance the performance of the FortiADC DNS service by enabling the Minimal-Responses option in the Global Load Balance General Settings to hide the Authority Section and Additional Section of DNS queries.
For details, see Configuring general settings.
Sync List enhancement for synchronizing GLB objects
Previously, some GLB configurations could not be synchronized through the Sync List functionality due to dependencies. Now, the Sync List functionality has been expanded to support all GLB configurations except for General Settings.
For details, see Pushing/pulling configurations.
Server Load Balance
FortiADC Ingress Controller 2.0
The following enhancements have been made to the FortiADC Ingress Controller version 2.0:
-
Support for Ingress to expose service with ClusterIP type. FortiADC 7.4.0 and FortiADC Ingress Controller 2.0.0 support Flannel with VXLAN backend as the Kubernetes network model CNI plugin. Through the VXLAN tunnel, FortiADC can forward HTTP/HTTPS requests to the Kubernetes service with ClusterIP type.
-
Support for virtual server FortiGSLB configurations defined in the annotation of Kubernetes Ingress.
-
Added toleration in the FortiADC Ingress Controller Helm deployment template to allows users to specify how long a pod can remain bound to a node before being evicted. For example, you can specify the amount of time to wait for the FortiADC Ingress Controller to spin up if the Kubernetes node being located becomes unreachable or goes into NotReady state. The default toleration time for in FortiADC Ingress Controller is 30 seconds.
For details, see the FortiADC Ingress Controller Kubernetes Deployment Guide.
RedHat OpenShift Container Platform 4 (OCP 4) support for FortiADC Ingress Controller
The FortiADC Ingress Controller capability has now been extended to support managing FortiADC objects from RedHat OpenShift Container Platform 4 (OCP 4). FortiADC Ingress Controller can now watch the Kubernetes API for specially formatted OCP 4 Route resources and automatically implement corresponding actions on FortiADC for Add/Update/Delete events.
For details, see the FortiADC Ingress Controller OpenShift Deployment Guide.
Support for HTTP/3 using QUIC (Quick UDP Internet Connections)
HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP, unlike previous versions which relied on TCP to handle streams in the HTTP layer. The HTTP/3 protocol has a lower latency as a result of using QUIC, allowing it to have a quicker handshake for establishing a secure session compared to HTTP/2 which achieves this using TCP and TLS.
FortiADC does not support server side HTTP/3, instead support is provided for client HTTP/3 to the ADC and then converted to HTTP/1 (conversion to HTTP/2 is not supported).
Note: In version 7.4.0, FortiADC is introducing HTTP/3 support as an experimental feature with limited HTTP/3 functionality, so it is not recommended to be used in production environments.
For details, see Configuring HTTP3 profiles.
Option to send TCP RST to real server upon session timeout for L4/L2 TCP virtual servers
For L4 and L2 TCP virtual server profiles, you can now enable the Timeout Send RST option to send the TCP RST to the client and real server when the TCP session expires. This is supported for both IPv4 and IPv6 in L4 and L2 virtual servers. Additionally, for L4 virtual servers only, Timeout Send RST is supported for DNAT/Full NAT/NAT46 for IPv4 and DNAT/Full NAT/NAT64 for IPv6.
For details, see Configuring Application profiles.
Persistent Cookie enhancement
New cookie attributes have been added for the Persistent Cookie persistence type to enable users to set the domain value on the persistence cookie to allow it to be used cross-site as a wildcard.
For details, see Configuring persistence rules.
Session cookie functionality for Persistent Cookie and Insert Cookie persistence types
The 0 seconds timeout option has been added to the Persistent Cookie and Insert Cookie persistence types to allow these cookies to expire at the end of the session, thereby function as a session cookie. Typically, when the timeout value is set to 1 or more seconds, a timestamp is applied to the cookie to track the timeout. When the timeout is set to 0, the cookie will not have a timestamp and instead will expire along with the session.
For details, see Configuring persistence rules.
IP pool persistence support for L4 VS source IP persistence
When configuring Source Address persistence for Layer 4 virtual servers, you can now enable NAT Source Pool persistence to allow the IP selected from the IP pool to persist.
For details, see Configuring persistence rules.
Source IP address and source port persistence support for L4 TCP/UDP/FTP VS and L2 TCP/UDP/IP VS
You can now apply persistence based on both the source IP address and source port (Source Address-Port Hash) for Layer 4 TCP/UDP/FTP virtual servers and Layer 2 TCP/UDP/IP virtual servers.
For details, see Configuring Application profiles.
New HTTP Lua scripting functions
Two new HTTP scripts have been added:
-
HTTP:get_unique_session_id() function returns a unique ID per session history.
-
HTTP:get_unique_transaction_id() function returns a unique ID per transaction history.
Security
Two new Web Application Firewall sub-modules: API Discovery for API Protection and Fingerprint Based Detection for Bot Mitigation
API Discovery
FortiADC introduces the API Discovery feature that enables you to build a database of API endpoints for which you can base security rules and actions. Through API Discovery, FortiADC can automatically discover external API endpoints from HTTP/HTTPS requests or responses that passed API validity check, parse the API information including the Host, Paths, parameters and their schemas from query requests or entity bodies, as well as classify parameters that match PII (Personal Identifiable Information) signatures. API discovery also supports manually imported OAS files compliant with OpenAPI 3.0 and Swagger 2.0 standard to parse and discover as internal API endpoints that can also be matched by incoming API requests or responses. The discovered external and internal API endpoints can then be directly applied in API security rules based on the Host, Path, and request rate. Once the API requests and responses pass the API validity check that matches the rule, the specified security action will be triggered to protect against the malicious APIs.
For details, see Configuring API Discovery.
Fingerprint Based Detection
Fingerprint Based Detection is an enhancement to the Bot Mitigation features that include Threshold Based Detection and Biometrics Based Detection introduced in version 7.2.0. Fingerprint Based Detection detects the client's fingerprint using multiple characteristics to ascertain whether an access request originates from a human or a bot. This is accomplished by first collecting behavioral fingerprints (such as WebDriver, WindowsProperties and MimeTypesConsistent) with JavaScript enabled on the client browser, then comparing the fingerprint against known automation tools and frameworks to determine whether the requests are generated by automation tools such as Headless Chrome, Selenium or Electron.
For details, see Configuring a Fingerprint Based Detection policy.
Firewall session timeout configuration through CLI
Through CLI, you can now configure the timeout period for the connection tracking sessions in the config firewall global. To clear the firewall sessions in the connection tracking table, you can use the diagnose firewall-session clear command.
AV engine update
The FortiADC Anti-Virus engine has been updated to version 6.00285.
CVE information added to IPS Signatures
The CVE Number can now be used to search through the list of IPS Signatures when adding IPS Signatures or IPS Filters to your IPS Profile. Each IPS Signature now include the CVE Reference field in the detailed view.
For details, see Configuring IPS.
System
Terraform FortiADC provider
FortiADC now includes a Terraform FortiADC-VM provider. For more details, see FortiADC Terraform provider.
FortiFlex support for FortiADC-VM
FortiADC-VM has been added to the FortiFlex offering. This allows you to easily manage VM usage entitlements for FortiADC-VMs by combining the base license and services into a single license. You can use the FortiFlex portal to create VM configurations, generate license tokens, and monitor resource consumption in the form of points.
FortiADC now supports FortiFlex licensing on public and private loud platforms.
-
Public Cloud: AWS, Microsoft Azure, Google Cloud Platform (GCP), Oracle Cloud Infrastructure (OCI), Alibaba Cloud
-
Private Cloud: VMware ESXi, KVM, Microsoft Hyper-V
Unicast HA support for Hyper-V VRRP
FortiADC now supports unicast heart-beat for HA-VRRP for the Hyper-V platform.
Active-Active-VRRP Unicast HA support in Alibaba Cloud
FortiADC now supports HA in the Alibaba Cloud platform for Active-Active-VRRP Unicast HA mode.
New System Events automation trigger
The Admin user login failed and blocked IP event has been added to the System Events automation trigger. This allows you to trigger an automation rule when an admin user fails to log into FortiADC.
For details, see Configuring Automation Triggers.
Client-side certificate validation for Webhook automation action
When configuring the Webhook automation action, you now have the option to validate the certificate for HTTPS connections to the webhook endpoint using a TLS Certificate or a CA certificate.
For details, see Configuring Automation Actions.