Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
HeikoAnkenbrand
Champion Champion
Champion

Enable Maestro Fastforward

How fastforward works:

Policy

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.

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 and Processing is transferred to the MHO via the API for the second packet.

Routing

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.

Restrictions in version R81.20:

- Fastforward acceleration is not supported for directly connected subnets.
  
The networks must be connected via router in R81.20.
- Management interface is not supported.
- When accelerating traffic through a bond interface, egress traffic goes out only thrugh one subordinate interface (for each MHO).
- For UDP connections the Security Group does not generate logs (For TCP connections the Security Group generates a
   corresponding log)

Supported deployment types:

- Singel site, dual site
- One or two MHO's on a site
- Gateway or VSX  (the configuration is for each Virtual System) mode

Enable Fastforward:

1) Connect to the Maestro Security Group via gclish.
2) Configure a prefix for the Access Control rules
     > set maestro fastforward rulebase-prefix enable prefix fast_rule
     > set maestro fastforward state on
3) Connect with SmartConsole to the Management Server and create a Access Control rules with the prefix you configured earlier.
    If your prefix is set to “fast_rule”, for the policy rule names use: “fast_rule_1”, “fast_rule_2”, and so on.
HeikoAnkenbrand_0-1693475402476.png

More read here:
R81.20 Admin Guide -> Fastforward 

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
4 Replies
bernhard_m
Collaborator

Are there any plans to remove the "directly connected subnets" limitation in future versions?

The backup subnet, which is the most obvious usecase,  is usually directly connected to the datacenter firewall.

 

0 Kudos
emmap
Employee
Employee

I don't believe there is any plans to change this at this time, but feel free to submit an RFE.

The reason that we require the next hop is that the MACs of each device that is involved in fast forward must be passed to the MHO from the SGMs on policy install so that the MHO can forward the packets, as MHOs don't manage layer 2 on uplinks in general operation. Allowing locally connected devices to be involved in FF could end up with having to send 10s or 100s of thousands of MACs to the MHO, which we'd rather avoid.  

0 Kudos
(2)
bernhard_m
Collaborator

I was assuming that this could be the reason. Thanks for confirming this.

0 Kudos
Daniel_Cohen
Employee
Employee

Also the limitation is due to the configuration pushed to the MHO from the GW is static - meaning it's only pushed via Policy Installation, so if we have a new MAC or a changed MAC, the MHO will not be aware, till we push policy again.

(1)