In some cases, you may have to modify the default behavior of your firewall by changing the advanced access rule parameters. Some of these parameters can be used to increase the security level, whereas others provide rarely needed exceptions to the strict default security policy of the Barracuda CloudGen Firewall.
Advanced Access Rule Settings
Rule Mismatch Policy
Usually, a connection request is required to match the source, service, and destination of a rule. By default, the firewall continues to the subsequent rule in the rule set if one of the three conditions is not met. If you do not want a rule to be bypassed, you can change the policy for mismatches to the rule conditions.
The following policies are available for Source, Destination, Service, User, and MAC address condition mismatch:
- CONTINUE on Mismatch (default) – Continues processing the next access rules.
- BLOCK on Mismatch – Ignores all traffic and does not answer to any matching packet (= silent drop).
- DENY on Mismatch – Dismisses all traffic and sends TCP-RST (for TCP requests), ICMP Port Unreachable (for UDP requests), or ICMP Denied by Filter (for other IP protocols) to the source.
If you want the session to be re–evaluated when the rule set or authentication settings are changed, enable the Persistence setting (forwarding firewall only). Unlike the forwarding firewall, the host firewall always keeps sessions alive.
Example Use Case
Two machines in your LAN have access to a database server on a critical port (for example, telnet). You want to ensure that no other rule accidentally allows access for a source other than these two clients. In this case, select Block on Mismatch from the Source list in the Rule Mismatch Policy section of the Advanced Rule Parameters window.
In the TCP Policy section, you can edit the following TCP policy settings for traffic that is handled by the access rule:
Generic TCP Proxy
The firewall engine is capable of two TCP forwarding methods:
Features not available when using the Generic TCP Proxy:
|Syn Flood Protection (Forward/Reverse)|
Defines the behavior of the firewall with regard to the TCP three-way-handshake. You can select the following options:
For more information, see Best Practice - Protect Against TCP SYN Flooding Attacks with TCP Accept Policies.
|Accept Timeout (s)||Length of time that the firewall waits until the destination has to answer. After this timeout, the firewall sends a TCP RST packet to both partners (default: |
Last ACK Timeout (s)
Length of time in seconds that the firewall waits after an ACK to terminate the connection (default:
Retransmission Timeout (s)
Length of time in seconds that the firewall waits until the source has to retransmit packets. If nothing happens, the firewall registers the session as a hijacking attempt (default:
Halfside Close Timeout (s)
Length of time in seconds that the firewall waits after conscious termination of the connection to close the socket (default:
|Disable Nagle Algorithm|
Enables TCP_NODELAY. This option is only available when the Generic TCP Proxy is enabled.
Force MSS (Maximum Segment Size)
Checks the SYN and SYN–ACK TCP packets for an MSS that is larger than the configured MSS. If the MSS TCP attribute is smaller, the packet is rewritten with the configured MSS. Use this feature for VPNs to force a TCP MSS that fits the MTU of the VPN tunnel device. For IPv4, the maximum transmission size must be at least 40 bytes smaller than the MTU.
|Raw TCP mode|
Handles sole chunks of TCP traffic without analyzing the entire contiguous TCP stream to allow routing loops. However, this mode is limited in terms of intrusion prevention, application detection, overall TCP state tracking, and other aspects.
Raw TCP mode must be explicitly enabled in a forwarding access rule. Raw TCP sessions are not synchronized.
The following features are not available in Raw TCP mode:
In the Resource Protection section, you can specify the following session limits to conserve your system resources:
|Allow to exceed global session limits||Allow this access rule to override the global session limits defined in the General Firewall Configuration.|
Max Number of Sessions
Maximum number of accepted concurrent connections for this rule on a global basis (default:
|Max Number of Sessions per Source|
Maximum number of accepted concurrent connections per source address (default:
|Session Duration Limit (s)|
Maximum length of time in seconds that the session can stay active. By default, there is no duration limit for the session.
Counting / Eventing / Audit Trail
In the Counting / Eventing / Audit Trail section, define when events are logged or written to the access cache.
|Firewall History Entry||Save the connection information to the firewall history. (default: Yes).|
Log File and FW Audit Entry
Obtains log file entries (default: Yes).
Transparent Failover State Sync
Synchronizes the session on a high availability system (default: Yes).
Obtains statistics (default: Yes).
If you select No, global firewall statistics are not generated and information is not displayed in the firewall dashboard.
|Log Session State Changed||Logs changes of session states (default: No).|
|Own Log File|
Saves all log events in an extra log file (default: No).
Generates service statistics for this rule (default: No).
The severity level of the rule's event messages. Host firewall rules are not affected by this setting. You can select the following event levels to be generated if a forwarding firewall rule matches:
In the event settings, you can specify actions for these event messages. For more information, see How to Configure Basic, Severity, and Notification Settings for Events.
|Application Log Policy|
|Generate event when rule is not used for [minutes]|
Triggers an event in case an access rule has not been used for a certain amount of time. Possible reasons could be wrong network routing policies or a wrong patching of network cables. If the parameter [minutes] is set to 0, no events will be triggered. Any other value configures the time span in minutes after an event is triggered if an access rule has not been used. For more information about the event, see Security Events.
In the Miscellaneous section, you can edit the following settings:
The required user authentication method for HTTP and HTTPS connections. You can select the following authentication methods:
For more information about authentication, see Firewall Authentication and Guest Access.
|IP Counting Policy|
You can select the following policies:
Applies a time restriction to rules that are configured with a feature level that is equal to or lower than 3.2.
|Clear DF Bit|
The DF bit determines whether a packet can be fragmented or not. In networks where packet size is limited to an MTU, packet fragmentation may become vital when packets sent to this network exceed the MTU (for example, as may frequently occur with SAP applications).
Because the firewall must not override the DF bit setting, fragmentation is up to the client. When the DF bit is set and the target network's MTU specification requires fragmentation, the firewall responds with an
Before enabling this setting, consider the following points:
To clear the DF bit from the IP header and fragment packets if necessary regardless of the setting in the packet's IP header, select Yes. By default, this setting is disabled.
|Set TOS Value|
The TOS value. By default, the value is set to 0 (TOS unchanged). To set the TOS value to 0 (TOS normal), enter
|Prefer Routing over Bridging|
Controls the routing behavior of routed transparent Layer 2 bridges. To route traffic over bridges that are configured on the firewall, select Yes. Enable this setting when an external router connects the bridges and traffic should not be directed to this router. If traffic is first routed to the external router, it is rejected because it passes the gateway twice.
By default, this setting is disabled.
For more information on routed transparent Layer 2 bridges, see How to Configure Routed Layer 2 Bridging.
The color of the rule in the rule set.
In the Quarantine Policy section, you can select one of the following rule matching policies for evaluating sessions to and from a specific quarantine class:
- Match – The rule matches.
- Block – The rule blocks the request.
- Deny – The rule denies the request.
- Continue – Rule evaluation continues with the next rule in the rule set.
A session is only evaluated when it matches the specified policy for the following settings:
LAN Rule Policy
Matching policy for sessions to and from a non–quarantine net.
Quarantine Class 1 Rule Policy
Matching Policy for sessions to and from a Quarantine class 1 net.
Quarantine Class 2 Rule Policy
Matching Policy for sessions to and from a Quarantine class 2 net.
Quarantine Class 3 Rule Policy
Matching Policy for sessions to and from a Quarantine class 3 net.
Dynamic Interface Handling
Restricts rule processing to the specified dynamic network interface (if installed and configured).
|Continue on Source Interface Mismatch|
Continues with rule processing, even if no matching interface can be found. The subsequent rule is then used for rule evaluation.
|Reverse Interface (Bi-directional)|
The interface that the destination address is allowed to use. Only applicable for bi-directional rules.
|Interface Checks After Session Creation|
Disables interface checks. Only applicable for bi-directional rules.