Configuring a FortiGate firewall goes beyond initial setup. To truly harness its power, you need to implement advanced policy configurations that strike the perfect balance between robust security and optimal network performance. For IT professionals and network administrators, a well-structured policy set is the foundation of a secure and efficient network. This guide explores best practices for policy ordering, leveraging implicit rules, and fine-tuning application control to achieve this balance.
We will cover the essential strategies for effectively structuring your security policies. You will learn how the order of your rules can impact everything from security posture to network speed, how to manage the rules you cannot see, and how to gain granular control over the applications running on your network.
The Art of Security Policy Ordering
The sequence of your firewall policies is not just an administrative detail; it is a critical component of your security strategy. FortiGate firewalls process traffic by matching it against policies in a top-down order. The first policy that matches the traffic is the one that gets applied, and no further policies are evaluated. This simple logic has profound implications for both security and performance.
Prioritise Specificity and Security
The core principle of policy ordering is to place your most specific and critical rules at the top of the list. Policies with narrowly defined sources, destinations, and services should come before broad, general rules. This ensures that specific traffic is handled exactly as intended, without being accidentally caught by a more permissive rule further down the list.
For example, a rule that denies access from a known malicious IP address to a critical server should be placed near the top. If a general «allow web traffic» rule were placed above it, the malicious traffic could be permitted before the specific deny rule is ever checked.
Best Practices for Ordering:
- Deny First: Place explicit deny policies for known threats, geographic locations, or unwanted applications at the top. This drops malicious or undesirable traffic immediately, reducing the processing load on the firewall.
- Specific to General: Arrange policies from most specific to most general. A rule for a single user accessing a particular application should precede a rule allowing an entire department to access the internet.
- High-Impact Rules: Position policies that handle the majority of your network traffic (like general web access) lower in the list, but above the final implicit deny rule. This ensures that legitimate, common traffic is processed efficiently after specific, security-critical exceptions have been handled.
- VPN and Tunnels: Rules for VPNs (IPsec and SSL-VPN) are often highly specific and should be placed high in the policy table to ensure remote user traffic is handled correctly.
Performance Considerations
A poorly ordered policy table can degrade firewall performance. When a connection is established, the FortiGate has to evaluate each policy in sequence until it finds a match. If your most frequently hit policies are at the bottom of a long list, the firewall wastes CPU cycles processing rules that will not match.
By placing high-traffic, specific rules higher up (after the initial critical deny rules), you reduce the average number of policies the firewall needs to check for each session. This optimizes resource usage and minimizes latency, leading to a faster user experience.
Understanding Implicit and Explicit Rules
Every FortiGate policy table concludes with a rule you cannot see: the implicit deny rule. This rule is a fundamental security feature that ensures any traffic not explicitly permitted by a policy is blocked.
The Implicit Deny Rule
Also known as the «default deny,» this invisible rule is positioned at the bottom of your policy list. Its logic is simple: deny all from any to any. This principle of «default deny» is a cornerstone of network security. It forces administrators to build a «positive security model,» where they must proactively define what is allowed, rather than trying to block everything bad.
You cannot edit or remove this rule. Its presence means you must have an explicit «allow» policy for any traffic you wish to permit, whether it’s from LAN to WAN, DMZ to LAN, or any other zone combination.
Creating an Explicit Deny Rule
While the implicit deny rule provides a safety net, there are often situations where you need to create an explicit deny rule. This is useful for logging and visibility. The implicit deny rule does not log dropped traffic by default. To view the traffic being blocked by your default policy, you must create a manual, explicit deny rule and place it just above it.
Creating a «Clean-up» Rule:
- Source: all
- Destination: all
- Service: ALL
- Action: Deny
- Enable Logging: Turn on «Log Violation Traffic»
By placing this rule at the end of your policy list (just before the invisible implicit deny), you gain valuable insight into traffic that would otherwise be silently dropped. This can help identify misconfigured applications, unauthorised access attempts, or other network anomalies.
Mastering Application Control
Modern networks are increasingly dominated by applications, many of which utilize standard ports, such as 80 and 443, to bypass traditional port-based firewalls. This is where Application Control becomes essential. It provides deep packet inspection to identify and manage applications regardless of the port they use.
Integrating Application Control into Policies
Application Control is not a standalone feature; it is a security profile that you apply to your firewall policies. By enabling it, you gain granular control over the specific applications allowed to run over a permitted connection.
For instance, you can have a general policy that allows outbound web traffic on port 443. Without Application Control, this would permit any SSL-encrypted application. By applying an Application Control profile, you can refine this rule to allow business-critical web applications, such as Microsoft 365, while blocking non-productive or high-risk applications, like peer-to-peer file sharing or certain social media platforms.
Best Practices for Application Control
- Start with Monitoring: Before blocking applications, implement Application Control in monitor-only mode. Please create a profile that detects all applications and apply it to your main outbound policy. Review the logs to understand what applications are actually being used on your network. This data-driven approach prevents you from accidentally blocking a critical business application.
- Create Custom Signatures: If your organisation uses a custom or less-common application, you can create custom application signatures. This allows the FortiGate to identify and control traffic specific to your business needs.
- Use Categories for Efficiency: FortiGuard Labs maintains a vast database of applications, categorised by risk, function, and technology. Instead of managing thousands of individual application signatures, you can create policies based on categories. For example, you can easily block all applications in the «Proxy» or «P2P» categories.
- Apply Quotas and Shaping: Application Control can be combined with Traffic Shaping to manage bandwidth. You can allow certain non-essential but tolerated applications (like video streaming) while applying a bandwidth quota to prevent them from impacting the performance of critical business systems.
Conclusion: A Proactive Approach to Policy Management
Advanced FortiGate firewall policy configuration is an ongoing process, not a one-time task. A well-structured policy set that prioritises security, optimises for performance, and provides deep visibility into application traffic is a powerful asset for any network administrator.
By following these best practices, you can move from a reactive to a proactive security posture. Regularly review and refine your policy ordering to ensure it aligns with your evolving business needs. Use explicit deny rules to gain visibility into blocked traffic, and leverage Application Control to enforce security at the application layer. These steps will help you build a more secure, efficient, and resilient network infrastructure.

Deja una respuesta