Define Action options for the Jump action in Access rules

The Jump action directs traffic to a Sub-Policy.

The Jump action in IPv4 Access rules, and Firewall IPv6 Access rules adds a conditional section of rules to the policy. If a connection matches the Jump rule’s matching criteria, it is matched against the rules in the Sub-Policy.

For more details about the product and how to configure features, click Help or press F1.

Steps

Right-click the Action cell, then select Jump.
Set the options, then click OK.

Select Rule Action Options dialog box (Jump)

Use this dialog box to override and specify the options for the Jump action.

Option	Definition
Jump tab
Sub-Policy	Select a Sub-Policy. Connections that match the Jump rule are matched against the selected Sub-Policy. If the Sub-Policy rules do not match, processing continues with the next rule in the main policy. Click Select to select an element.

Option	Definition
Inspection tab, Inspection options
Deep Inspection	Selects traffic that matches this rule for checking against the Inspection Policy referenced by this policy. Traffic is inspected as the Protocol that is attached to the Service element in this rule. Inherited from Continue Rule(s) — Deep inspection settings defined in Continue rules higher up in the policy are used. On — Deep inspection is enabled. Off — Deep inspection is disabled.
File Filtering	Selects traffic that matches this rule for checking against the File Filtering Policy referenced by this policy. Inherited from Continue Rule(s) — File Filtering settings defined in Continue rules higher up in the policy are used. On — File filtering is enabled. Off — File filtering is disabled.
Anti-Spam	The Anti-Spam feature is no longer supported in NGFW version 6.2.0 and later.
Decryption	Defines whether traffic that matches the rule is decrypted for TLS inspection or by the SSM HTTP Proxy (NGFW Engines in the Firewall/VPN role only). Inherited from Continue Rule(s) — Decryption settings defined in Continue rules higher up in the policy are used. Allowed — Traffic that matches the rule is decrypted. Disallowed — Traffic that matches the rule is not decrypted.

Option	Definition
Inspection tab, Connection Options
Connection Tracking Mode	Select one of these options: Inherited from Continue Rule(s) — The connection tracking setting defined in the Continue rules higher up in the policy is used. Note: If connection tracking is disabled in Continue rules higher up in the policy, the engine behaves as described in the Off (Not recommended) explanation. Off (Not recommended) — Connection tracking is disabled. The engine operates as a simple packet filter and allows packets based on their source, destination, and port. You must add separate Access rules that explicitly allow the reply packets. NAT cannot be applied to traffic allowed without connection tracking. Note: Turn off logging in the rule if you disable connection tracking. When connection tracking is off, a log entry is generated for each packet. This option can put considerable strain on the engine, network, and the Log Server. Defined in Engine Properties — The engine allows or discards packets according to the connection tracking mode selected in the engine properties. Reply packets are allowed as part of the allowed connection without an explicit Access rule. On Firewalls, protocols that use a dynamic port assignment must be allowed using a Service with the appropriate Protocol Agent for that protocol (in Access rules and NAT rules). Normal — When connection tracking is enabled, reply packets are allowed as part of the allowed connection without an explicit Access rule. The engine drops ICMP error messages related to connections that are not currently active in connection tracking (unless explicitly allowed by a rule in the policy). A valid, complete TCP handshake is required for TCP traffic. The engine checks the traffic direction and the port parameters of UDP traffic. If the Service cell in the rule contains a Service that uses a Protocol Agent, the engine also validates TCP and UDP traffic on the application layer. If a protocol violation occurs, the packet that violates the protocol is dropped. This mode is the default connection tracking mode for Firewalls. Strict — When connection tracking is enabled, reply packets are allowed as part of the allowed connection without an explicit Access rule. The engine allows only TCP traffic that strictly adheres to the TCP standard as defined in RFC 793. The engine also checks the sequence numbers of the packets in pre-connection establishment states and for RST and FIN packets, and drops packets that are out of sequence. If the Service cell in the rule contains a Service that uses a Protocol Agent, the engine also validates the traffic on the application layer. If a protocol violation occurs, the packet that violates the protocol is dropped. Loose — When connection tracking is enabled, reply packets are allowed as part of the allowed connection without an explicit Access rule. The engine allows some connection patterns and address translation operations that are not allowed in the Normal mode. This mode can be used, for example, if routing is asymmetric and cannot be corrected or if the use of dynamic routing protocols causes the engine to receive non-standard traffic patterns. This mode is the default connection tracking mode for IPS and Layer 2 Firewalls. This mode is recommended when engines are configured by default to only log connections instead of terminating them.
Idle Timeout	The timeout (in seconds) after which inactive connections are closed. This timeout concerns only idle connections. Connections are not cut because of timeouts while the hosts are still communicating. If you enter a timeout, this value overrides the setting defined in the engine properties. CAUTION: Do not set long timeouts for many connections. Each connection that is kept active consumes resources on the engine. Setting excessive timeouts for many connections can lead to serious performance problems. Generally, the idle timeout is not more than a few minutes.
Synchronize Connections	Defines whether connection information is synchronized between engine cluster nodes. Disabling connection synchronization reduces the traffic volume on the active heartbeat interface, but it also prevents transparent failover of connections to other nodes. Inherited from Continue Rule(s) — Connection synchronization settings defined in Continue rules higher up in the policy are used. Defined in Engine Properties — Connection synchronization settings defined in the engine properties. Off — Connection synchronization is disabled. This option overrides the setting defined in the engine properties.
Enforce TCP MSS (IPv4 Only)	Defines whether TCP MSS is enforced. Headers are not included in the maximum segment size (MSS) value; MSS concerns only the payload of the packet. Usually, network equipment sends packets at the Ethernet-standard maximum transmission unit (MTU) size of 1500 (including both payload and headers). Inherited from Continue Rule(s) — TCP MSS settings defined in Continue rules higher up in the policy are used. On — In the Minimum and Maximum fields, enter the minimum and maximum values for the MSS in bytes. If a TCP packet does not include an MSS value, the engine does not add the MSS value to the packet, but enforces the minimum MSS.
Minimum	If a TCP packet has an MSS value smaller than the minimum you set here, the packet is dropped. The smaller the data content is, the less efficient the communications become due to the fixed-size headers. Limiting the minimum size can help alleviate certain types of network attacks. Typically, the value you enter is not larger than the default minimum TCP Maximum Segment Size (536).
Maximum	If a TCP packet has an MSS value larger than the maximum, the engine overwrites the packet’s MSS with the maximum value you set here. Setting the maximum MSS size might be necessary to prevent fragmentation. Typically, the value you enter is lower than the standard Ethernet MTU (1500), taking the packet headers that are added to the MSS into account.

Option	Definition
Inspection tab, DoS Protection Options
Concurrent Connection Limit per Source IP and Concurrent Connection Limit per Destination IP	The maximum number of open connections from or to each IP address at any one time. You can select between Discard (silent drop) and Refuse (with ICMP error message) as the Action that is applied to new connections if the limit is reached. These limits are enforced by rules that have their Action set to Allow, Continue, or Use VPN (all VPN actions, Apply, Enforce, or Forward, are included). Be careful to apply the concurrent connection limits correctly for the types of communication that this rule handles to avoid cutting off connections unnecessarily.
Action	The Action that is applied to new connections if the limit is reached. Discard — The connection is dropped silently. Refuse — The connection is closed, and an ICMP error message is returned.
Rate-Based DoS Protection	Defines whether rate-based DoS protection is applied to traffic that matches the rule. Inherited from Continue Rule(s) — Rate-based DoS protection settings defined in Continue rules higher up in the policy are used. On — Rate-based DoS protection is enabled. Configure the settings in the engine properties. Off — Rate-based DoS protection is disabled. This option overrides the setting defined in the engine properties. You cannot use a rule to enable rate-based DoS protection if the feature is disabled in the engine properties.
Scan Detection	Defines whether scan detection is applied to traffic that matches the rule. Inherited from Continue Rule(s) — Scan detection settings defined in Continue rules higher up in the policy are used. On — Scan detection is enabled. Configure the settings in the engine properties. Off — Scan detection is disabled. This option overrides the setting defined in the engine properties. You cannot use a rule to enable scan detection if the feature is disabled in the engine properties.