Maestro Fastforward


The Maestro Fastforward feature offloads chosen policy rules for trusted connections to the Quantum Maestro Orchestrator for hardware acceleration of accept / drop rules.


  • Low latency: Sub microsecond latency. The feature provides low latency for specific trusted sensitive flows (examples: voice, trading, internal trusted server-to-server communications and more).

  • Throughput: Port line rate throughput (based on the connected interfaces bandwidth). Achieves as much as 200Gbps for one connection. You can enable the feature for high volume trusted connections such as server to server, backups and more.

  • Troubleshooting / Bypassing: Forwards selected tuples as part of a troubleshooting process.

How It Works


The Administrator marks desired rules to be offloaded to the Orchestrator by giving the applicable rule names a specific prefix (the prefix is configurable). During policy installation, the applicable rules are translated into Access Control Lists (ACLs) and offloaded to the Orchestrator to be enforced on the hardware level.


To accelerate a trusted connection on the Orchestrator at the Layer 3 level (routing), the Orchestrator has to know the networking information of the Security Gateway in order to send the packet through the correct outgoing interface to the correct next hop. The Orchestrator must have the same view of the topology as the Security Gateway. Therefore, the feature replicates the Security Gateway's / Virtual System's routing topology to accelerate traffic at the Orchestrator level. In addition, this logic occurs at the hardware level and is very robust.


  • The offloaded rules are translated into stateless ACLs. Therefore, the offloaded rules are enforced without full stateful inspection capabilities.
  • For TCP connections, for Accept Rules, the SYN packets are sent to the Security Group. Therefore, they enforce the opening of the connection (only source -> destination of the rule opens the TCP connection).
  • The accelerated traffic is intended for trusted flows because it is a tradeoff between stateful-ness (in the Security Group) and stateless ACLs in the Orchestrator for performance gain.
  • See Known Limitations.



Topology Explanation

Single Site, One Orchestrator

With one Orchestrator on a Single Site, there are no restrictions on physical connectivity.

Interfaces can be regular or bond interfaces.

Single Site, Two Orchestrators

With two Orchestrators on a Single Site, only "cross-Orchestrator" bond interfaces are allowed.

Meaning, each bond interface has a subordinate interface on each Orchestrator.

For more information, see Special Considerations.

Dual Site

In Dual Site configuration, only "cross-Orchestrator" bond interfaces are allowed on each site.

Meaning, each bond interface has a subordinate interface on each Orchestrator on each site.

For more information, see Special Considerations.

In Dual Site configuration, only the active site enforces the ACLs. If there is a site failover, the new active site is activated.


In VSX mode, the feature works on each Virtual System, on which you enabled it.


The Fastforward feature is disabled by default.

You configure the Fastforward feature for each Security Group.

In VSX mode, you configure the feature on each Virtual System.


The Security Group logs TCP connections as usual. See the logs in SmartConsole or SmartView.

The "tor_util fastforward" command on the Orchestrator shows additional information.

Considerations for Administrators


Regular Flow

Additional Flow

Policy Installation

The Management Server transfers the policy to the Security Group.

The Management Server translates into stateless ACLs the rules that contain the configured prefix in their Name column.

The Security Group transfers these ACLs to all Orchestrators.

If there are no changes in the policy, the Security Group skips this step.

Modifying topology (physical interfaces / routes / bond interfaces)

The administrator adds, modifies, or removes an interface or a route.

  • In Gateway mode, the administrator makes these changes in Gaia gClish / of the Security Group.

  • In VSX mode, the administrator makes these changes in Gaia PortalSmartConsole (except for bond interfaces).

When done:

  • In Gateway mode, you must fetch the interface topology and install the policy.

  • In VSX mode, you must install the policy.

This makes sure that enforcement is aware of the modifications (Firewall topology, Anti-Spoofing, and more).

During each policy installation, the Security Group transfers the networking topology to all Orchestrators (interfaces, neighbors, static routes).

If there are no changes in the topology, the Security Group skips this step.

Routing Mechanism

Policy Mechanism

Special Considerations

Known Limitations