Maestro Fastforward

• Single Site, or Dual Site.

• One Orchestrator, or two Orchestrators on a site.

• Gateway mode, or VSX mode (the configuration is for each Virtual System).

• For TCP connections:

  For rules with the Action "Accept", the Orchestrator sends the TCP SYN packets to the Security Group.

  The Security Group generates a corresponding log.

• For UDP connections:

  The Security Group does not generate logs.

No. The rules should be created as in stateful inspection.

The ACL translation mechanism automatically adds Client-to-Server and Server-to-Client rules.

Only SYN / SYN-ACK packets (for Accept Rules).

The trade-off of the feature is to fully offload trusted connections to be handled on the Orchestrator hardware level, therefore allowing very low latency and very high throughput without having an effect on the Security Group Members.

Part 1 of 2 - Configuration on the Security Group:

1. Connect to the command line on the Security Group.

2. Log in to Gaia gClish.

3. In VSX mode, move to the context of the applicable Virtual System:

   set virtual-system <VSID>

4. Configure a prefix for the Access Control rules:

   set maestro fastforward rulebase-prefix enable prefix <Name Prefix>

   For example, if your prefix is set to “ff_rule”, for the policy rule names use: “ff_rule_1”, “ff_rule_2”, and so on.

   [Global] MyChassis-01> set maestro fastforward rulebase-prefix enable prefix ff_rule   1_01: Fastforward prefix status: enabled. Prefix is "ff_rule" Please install policy from SmartConsole for the change to take effect.   2_01: Fastforward prefix status: enabled. Prefix is "ff_rule" Please install policy from SmartConsole for the change to take effect.

5. Enable the Fastforward feature:

   set maestro fastforward state on

   Example output:

   1_01: Routing configuration validation finished successfully. Fastforward status: enabled Please install policy from SmartConsole for the change to take effect.   2_01: Routing configuration validation finished successfully. Fastforward status: enabled Please install policy from SmartConsole for the change to take effect.

Part 2 of 2 - Configuration in SmartConsole:

1. Connect with SmartConsole to the Management Server that manages this Security Group / Virtual System.

2. Configure the applicable Access Control rules with the prefix you configured earlier on the Security Group.

   Example:

   Name	Source	Destination	VPN	Services & Applications	Action	Track	Install On
   ff_rule_1	Backup_Server_1	Backup_Server_2	Any	nfsd-tcp	Accept	Log	Policy Targets

   Note - You can configure these rules with API calls. See the Check Point Management API Reference.

   Important: You only have to configure the rules for the Client to Server (C2S) traffic. For rules with the action "Accept", the Management Server automatically creates the corresponding rules for the Server to Client (S2C) traffic. These rules support only the actions "Accept" and "Drop".

   Additional notes about the Access Control rules for Fastforward:

   Notes for rules with the action "Accept"

   Rule Column	Notes
   Source	In the "Source" column, you can add one or more objects of these types only: Host Network Group Address Range In the "Source" column, you cannot use the object "Any". You must add an explicit object. The Security Group must be able to connect to the IP address in the explicit object (you added in the "Source" column) through its Data interfaces (not the Management interface). In the "Source" column, you cannot use objects with IP addresses that belong to networks that are directly connected to the Security Group through its Data interfaces.
   Destination	In the "Destination" column, you can add one or more objects of these types only: Host Network Group Address Range In the "Destination" column, you cannot use the object "Any". You must add an explicit object. The Security Group must be able to connect to the IP address in the explicit object (you added in the "Destination" column) through its Data interfaces (not the Management interface). In the "Destination" column, you cannot use objects with IP addresses that belong to networks that are directly connected to the Security Group through its Data interfaces.
   Services & Applications	You can add one or more service objects of type "TCP" with these settings: single port range of ports source port You can add one or more service objects of type "UDP" with these settings: single port range of ports source port You can add one or more service objects of type "Other Service" with an IP-based Protocol.

   Notes for rules with the action "Drop"

   Note - Orchestrator drops the traffic at an early stage, at the hardware level.

   Rule Column	Notes
   Source	In the "Source" column, you can add one or more objects of these types only: Host Network Group Address Range In the "Source" column, it is supported to use the object "Any". It is not necessary to add an explicit object. In the "Source" column, you cannot use objects with IP addresses that belong to networks that are directly connected to the Security Group through its Data interfaces.
   Destination	In the "Destination" column, you can add one or more objects of these types only: Host Network Group Address Range In the "Destination" column, it is supported to use the object "Any". It is not necessary to add an explicit object. In the "Destination" column, you cannot use objects with IP addresses that belong to networks that are directly connected to the Security Group through its Data interfaces.
   Services & Applications	You can add one or more service objects of type "TCP" with these settings: single port range of ports source port You can add one or more service objects of type "UDP" with these settings: single port range of ports source port You can add one or more service objects of type "Other Service" with an IP-based Protocol.

3. Install the Access Control Policy on the Security Gateway object / Virtual System object.

Part 1 of 2 - Configuration on the Security Group:

1. Connect to the command line on the Security Group.

2. Log in to Gaia gClish.

3. In VSX mode, move to the context of the applicable Virtual System:

   set virtual-system <VSID>

4. Disable the Fastforward feature:

   set maestro fastforward state off

   If this operation fails, it is possible to disable the feature forcefully. See Troubleshooting.

   Example output:

   1_01: clearing ACLs from all relevant Orchestrators Fastforward status: disabled   2_01: clearing ACLs from all relevant Orchestrators Fastforward status: disabled

Part 2 of 2 - Configuration in SmartConsole:

1. Connect with SmartConsole to the Management Server that manages this Security Group / Virtual System.

2. Disable the applicable Access Control rules with the prefix you configured earlier on the Security Group.

   In the No. column, right-click the rule and click Disable.

3. Install the Access Control Policy on the Security Gateway object / Virtual System object.

During a policy installation, the Security Group updates the Orchestrators with the networking information:

• Interfaces (physical interfaces, VLAN, bond interfaces)

• Neighbors table (ARP table)

• Routing table

The Orchestrator builds the topology in its hardware.

If there are two Orchestrators, each Orchestrator builds its own topology based on its present interfaces.

For example, if bond1 with 2 subordinate interfaces eth1-01 and eth2-01 is in the topology, Orchestrator #1 has eth1-01 on its topology, while Orchestrator #2 has eth2-01 in its topology.

This is because each Orchestrator accelerates locally, with no forwarding between the Orchestrator.

When a packet is matched against the Access Control rules that are configured for acceleration, it is forwarded to the Routing mechanism in the Orchestrator to perform a routing decision. Based on the routing decision, it finds the outgoing interface through which to send the packet.

To see the routing topology, run this command on the Orchestrator in the Expert mode:

Policy rules for trusted flows that are to be enforced and accelerated on the Orchestrator level are defined by unique prefix to the rules' names.

During policy installation, the Management Server translates these rules into stateless ACLs, and transfers them to the Security Group. The Security Group transfers these ACLs to the Orchestrators for enforcement.

The accelerated connections must be trusted, as they bypass firewall security features to achieve high throughput and low latency for specific services.

UDP rules are fully accelerated on the Orchestrators.

TCP rules - for Accept Rules, the SYN and SYN-ACK packets are sent to the Security Group for the first match, and mainly for logging purposes. After that, the other packets are accelerated on the Orchestrator.

The acceleration is for each rule offloaded by the ACLs offloaded, and not for each connection / session as in SecureXL. The acceleration here is stateless.

To see the offloaded rules on the Orchestrator, run this command in the Expert mode (see Monitoring):

Example output:

[Expert@MHO1:0]# tor_util fastforward show rules 1 0
Fastforward Rule Hits:
======================

+------------+--------------------+-------------+----------+-----------------------------------------------------------------------+
|Counter ID  |Hit Count           |Port         |Direction |Description                                                            |
+------------+--------------------+-------------+----------+-----------------------------------------------------------------------+
|66240512    |472065              |FF_SG1_VS0   |inbound   |Rule 1 C2S UDP, 1.1.1.0/24:ANY -> 2.2.2.0/24:3000, ACCEPT              |
|66256896    |23740853            |FF_SG1_VS0   |inbound   |Rule 1 S2C UDP, 2.2.2.0/24:3000 -> 1.1.1.0/24:ANY, ACCEPT              |
|66273280    |102381              |FF_SG1_VS0   |inbound   |Rule 2 C2S UDP, 1.1.1.0/24:ANY -> 2.2.2.0/24:4000, DROP                |
|66289664    |589884              |FF_SG1_VS0   |inbound   |Rule 3 C2S TCP, 10.10.10.0/24:ANY -> 20.20.20.0/24:22, ACCEPT          |
|66306048    |968405              |FF_SG1_VS0   |inbound   |Rule 3 S2C TCP, 20.20.20.0/24:22 -> 10.10.10.0/24:ANY, ACCEPT          |
|66322432    |0                   |FF_SG1_VS0   |inbound   |Rule 4 C2S UDP, 10.10.10.0/24:ANY -> 20.20.20.0/24:445, ACCEPT         |
|66338816    |0                   |FF_SG1_VS0   |inbound   |Rule 4 S2C UDP, 20.20.20.0/24:445 -> 10.10.10.0/24:ANY, ACCEPT         |
|66371584    |0                   |FF_SG1_VS0   |inbound   |Rule 5 C2S ip proto ANY, 9.9.9.9/32:ANY -> 10.10.10.10/32:ANY, ACCEPT  |
|66027520    |0                   |FF_SG1_VS0   |inbound   |Rule 5 S2C ip proto ANY, 10.10.10.10/32:ANY -> 9.9.9.9/32:ANY, ACCEPT  |
+------------+--------------------+-------------+----------+-----------------------------------------------------------------------+

1. The SMO receives the policy and converts the policy rules into stateless ACLs.

2. The SMO calculates a unique policy signature based on the content of the rules.

1. "Check"- The SMO verifies if new routing topology changes were introduced

2. "Apply" - The SMO applies the routing changes on the Orchestrator.

1. "Check"- The SMO checks if the Orchestrator has already installed the same policy signature.

2. "Upload and Prepare" - If the policy was not yet applied, the SMO uploads the ACLs to the Orchestrator for preparation.

3. "Apply" - The SMO applies the policy ACLs on the Orchestrator.

4. "Activate" - The SMO activates / deactivates the Fastforward operation state based on the site state (active site activates the feature, standby site deactivates the feature).

1. A packet enters an uplink port on the Orchestrator (example, eth1-05, port 5).

2. If Fastforward is activated (on the active site), the packet is first matched against its ACL policy.

3. If the packet is accepted, it is forwarded to the Orchestrator routing topology to be routed outside through a routing decision.

4. If there is no match in the policy ACLs, the packet goes through the regular distribution process towards the Security Group members.

Some packets are sent to the Security Group regardless of a match:

• TCP SYN and TCP SYN-ACK packets (for rules with the action "Accept")

• Fragmented packets (for rules with a user-defined service)

Cross-bond requirement:

Each Orchestrator builds its own virtual routing topology.

There is no forwarding in between Orchestrators. Each side handles the "shortcut" path of Fastforward.

Therefore, you must configure interfaces as cross-Orchestrator bond interfaces, meaning that each bond has subordinate interfaces present on each Orchestrator.

Monitoring of bond subordinate interfaces:

If only one of the Orchestrators loses links on its subordinate interfaces, routing becomes inconsistent because one of the Orchestrators and the Security Group have full routing topology, while the other Orchestrator lost its subordinate interfaces and has no way to accelerate locally. Because one of the subordinate interfaces went down, it now routes the packets differently, probably through an alternate route / default gateway).

In such a scenario, the two Orchestrators enter the temporary bypass state and forward traffic to the Security Group.

When link state return to "up", the Orchestrators exit the temporary bypass state.

Topology inconsistency:

Topology inconsistency may occur in deployments with multiple Orchestrators on the same site.

Because each Orchestrator accelerates the traffic locally, in a deployment with multiple Orchestrators, Fastforward requires the user to configure all interfaces as cross-Orchestrator bond interfaces.

As a result, each Orchestrator has a view of the entire topology and can complete the acceleration internally.

If the bond links fail on only one Orchestrator, it may cause traffic loss or wrong routing. In such a case, the Orchestrators on the current site enter into a special bypass mode - internal bypass.

When the topology is consistent again, the Orchestrators exit the internal bypass and go to the last desired state (active / inactive)

Example:

A deployment with two Orchestrators and two bond interfaces.

Bond1 as external, and Bond2 as internal.

Each bond has a total of four subordinate interfaces, two for each Orchestrator:

• bond1: eth1-05, eth1-06, eth2-05, eth2-06

• bond2: eth1-07, eth1-07, eth2-08, eth2-08

If bond1 fully fails, the topology remains consistent.

If in bond1, only the subordinate interfaces eth2-05 and eth2-06 fail:

• Orchestrator2 has an inconsistent topology for bond1

• Orchestrator1 and the Security Group still have a consistent topology for bond1

In this scenario, the Orchestrators detect the topology inconsistency and enter into the internal_bypass mode. In this mode, all traffic flows to the Security Group until the inconsistency is resolved.

Fastforward accelerates the traffic only on the active site .The standby site is in a deactivated state.

When a site failover occurs, the new SMO updates the Orchestrators with the new state and activates / deactivates them accordingly.

Fastforward monitors link states on downlink ports connected to each Orchestrator.

When all downlink ports fail on an Orchestrator, by default, Fastforward enters the bypass mode on that Orchestrator. This makes sure no traffic is forwarded when there are no members in the Security Group.

If there are multiple bond subordinate interfaces on an Orchestrator (for example, bond1 has eth1-01 and eth1-02), the Orchestrator chooses a primary subordinate interfaces to send traffic.

This is because bond interfaces are not configured on the Orchestrator, but only on the Security Group Members.

To overcome this:

• Ingress traffic - Incoming traffic on a bond subordinate interface is handled by Fastforward, as usual.

• Egress traffic - If traffic is routed out through a bond interface, the Orchestrator sends it through the primary subordinate interface of the bond interface. A primary subordinate interface is an interface withe lowest ID with the link in the "up" state.