# Firewall Policies and Security Policies

> Chapter 4 of the Courseiva FORTINET-NSE4 curriculum — https://courseiva.com/learn/fortinet-nse4/firewall-policies-and-security-policies

**Official objective:** 3.1 — Create and manage firewall policies, including security policy components, scheduling, and policy ordering.

## Introduction

Firewall policies and security policies. They are the single most important concept you will configure in a FortiGate firewall, because they control exactly which traffic gets through and which gets blocked — and in what order. For the NSE4 exam, you need to understand not just what a policy does, but how to create one, what every component inside it means, and why the sequence of policies matters more than the policies themselves.

## The Nightclub Bouncer's Rulebook Analogy

A nightclub has 3 entrances, each with a bouncer. The bouncer’s rulebook contains 15 numbered policies. Policy 1 says: 'If a guest is under 21, deny entry at the main door. Allow them only through the VIP entrance if accompanied by a staff member.' Policy 2 says: 'If a guest carries a bottle of water, check the label. If it is factory-sealed, allow entry. If it is opened, confiscate it and let them in.' Policy 3 says: 'If a guest is on the banned list, deny entry at every entrance and call security.' Policy 4 says: 'During the 10 PM to 2 AM shift, the VIP entrance is closed to all guests.' Policy 5 says: 'For any guest entering through the staff entrance, log their ID and photo before entry.'

The bouncer checks each guest against the rulebook in numerical order. He reads Policy 1 first. If it matches the guest and entrance, he follows that rule and stops — he never checks Policy 2. If Policy 1 does not match, he moves to Policy 2. If no policy matches at all, the guest is denied entry. This ordering—from most specific to most general—prevents accidents. If a general rule like 'Allow all guests over 21' came first, it would skip a more specific rule like 'But do not allow banned guests.'

This is exactly how a FortiGate firewall processes its firewall policies. Each policy has a source (the entrance), a destination (the VIP booth), a service (the type of item), a schedule (the time of night), and an action (allow or deny). The firewall reads from the top of the policy list downwards, stopping at the first match. Misordering a policy is like putting the 'allow everyone' rule above the 'ban the troublemaker' rule — the troublemaker walks right in.

## Core explanation

A firewall policy is a set of rules that tells the FortiGate what to do with network traffic. Think of it as a decision tree. When a packet (a small chunk of data) arrives at the firewall from a computer, the FortiGate checks that packet against each policy in order, from top to bottom. The very first policy that matches all the conditions — like the source IP address, destination IP address, and the type of service (for example, web traffic or email) — is the one that gets applied. Once a match is found, the firewall performs the action defined in that policy: it either allows the packet through, denies it (blocks it), or sometimes applies additional inspection like antivirus scanning or web filtering. If no policy matches the packet, the default behaviour of FortiGate is to deny it. This is called the 'implicit deny' rule, and it applies at the very end.

Let us break down the components you will see in the FortiGate interface when you create a policy.

- Source: This is where the traffic comes from. It can be a single computer (an IP address), a whole network (a subnet), a group of computers (an address group), or even a user who has logged in.
- Destination: This is where the traffic is going. Same format — an IP address, a subnet, or a group.
- Service: This is the type of traffic. Common examples are HTTP (web browsing), HTTPS (secure web), SMTP (email), DNS (domain name lookups), and SSH (secure remote login). Each service uses a specific port number.
- Action: This is what you do with the traffic. Two options: ACCEPT (let it through) or DENY (block it). There is also a 'SSL-VPN' action for VPN traffic, but for the exam basics, accept and deny are the core.
- Schedule: This defines when the policy is active. You can have an 'always' schedule, a business hours schedule (9 AM to 5 PM on weekdays), or a custom schedule. If traffic arrives outside the schedule, the policy does not apply, and the firewall moves to the next policy.
- Logging: This tells the firewall whether to record that this policy was used. You can log allowed traffic, denied traffic, or both. Logging is optional, but essential for troubleshooting.
- Security profiles: These are advanced features like antivirus, web filtering, application control, and intrusion prevention. You attach them to a policy so that traffic matching that policy gets inspected. For example, you might allow web traffic but also attach a web filter to block known malicious websites.

The most critical concept here is policy ordering. Policies are evaluated from the top of the list downwards. The moment one matches, evaluation stops. This means a very broad, permissive policy placed above a very specific, restrictive policy will 'shadow' the restrictive one — it will never even be checked. For example, suppose you have Policy 1: 'Allow all traffic from the internal network to the internet.' Policy 2: 'Deny all traffic to the website www.bad.com.' Because Policy 1 matches first for any internal user trying to reach www.bad.com, the traffic is allowed, and Policy 2 is never looked at. The result is that your block rule is useless. The correct ordering is to put the most specific policies first (deny this specific IP, allow this specific service) and the most general policies (allow all internet, deny all traffic) at the bottom.

Why does FortiGate behave this way? Because it prioritises performance. Once a match is found, the firewall does not waste CPU cycles checking the rest of the policies. It processes the packet and moves on. This also means that a poorly ordered policy list can be a security risk. A single over-permissive policy at the top of the list can accidentally allow traffic you wanted to block.

Another important feature is policy scheduling. You can create a schedule (a time range) and attach it to a policy. For example, you might have a policy that allows remote workers to access the internal network only during business hours (9 AM to 6 PM). After 6 PM, that policy becomes inactive, and the next matching policy applies — which, if you have a later policy denying all traffic or if no policy matches, gets blocked. Scheduling is useful for restricting high-risk activities to non-peak hours, like patching servers during a maintenance window.

The security policies themselves (the component names in the FortiGate GUI) are the same thing as firewall policies. Fortinet uses the term 'firewall policy' or 'security policy' interchangeably in the NSE4 exam. Do not let that confuse you. A security policy is just a firewall policy that may also include security profile attachments.

Finally, you need to understand policy groups and policy troubleshooting. The FortiGate shows policy IDs (numbers) in the list. When you add a new policy, it goes to the bottom by default. You must then move it up or down manually. You can also insert a policy between two existing ones. The FortiGate also provides a tool called 'policy lookup' that lets you simulate a traffic flow (source, destination, service) to see which policy would match. This is extremely useful for debugging.

In summary, the core formula is: for every traffic flow you want to allow or block, you create a policy, define source, destination, service, schedule, action, and optionally attach security profiles. You order those policies so that specific rules come before general ones. And you remember that the implicit deny at the bottom blocks everything else.

## Real-world context

Sarah is the IT administrator for a medium-sized company with 200 employees. The company has three departments: Sales, Engineering, and HR. Each department has its own network subnet. Sarah needs to set up the FortiGate so that:

- Everyone can access the internet.
- Only the Engineering team can access the company's internal code repository server (IP 10.0.10.50).
- Only HR can access the payroll system (IP 10.0.20.100).
- No one can visit the website 'gambling.com'.
- The guest Wi-Fi network (different subnet) can only access the internet, not any internal company servers.

Sarah starts by creating address objects. She goes to the FortiGate Interface and creates four address objects:

- 'Sales_Subnet' covering 192.168.1.0/24
- 'Engineering_Subnet' covering 192.168.2.0/24
- 'HR_Subnet' covering 192.168.3.0/24
- 'Guest_Subnet' covering 192.168.100.0/24

She also creates two server address objects: 'Code_Repo_Server' (10.0.10.50) and 'Payroll_Server' (10.0.20.100).

Then she creates the firewall policies in this exact order:

1. Policy 1: Source = Engineering_Subnet, Destination = Code_Repo_Server, Service = HTTPS, Schedule = always, Action = ACCEPT. Log = enabled. Security profile = none.
2. Policy 2: Source = HR_Subnet, Destination = Payroll_Server, Service = HTTPS, Schedule = always, Action = ACCEPT. Log = enabled. Security profile = none.
3. Policy 3: Source = Guest_Subnet, Destination = All (the internet), Service = HTTP+HTTPS, Schedule = always, Action = ACCEPT. Log = disabled. Security profile = web filter with 'gambling.com' category blocked.
4. Policy 4: Source = Sales_Subnet, Destination = All, Service = HTTP+HTTPS, Schedule = always, Action = ACCEPT. Log = disabled. Security profile = web filter with 'gambling.com' blocked.
5. Policy 5: Source = Engineering_Subnet, Destination = All, Service = HTTP+HTTPS, Schedule = always, Action = ACCEPT. Log = disabled. Security profile = web filter with 'gambling.com' blocked.
6. Policy 6: Source = HR_Subnet, Destination = All, Service = HTTP+HTTPS, Schedule = always, Action = ACCEPT. Log = disabled. Security profile = web filter with 'gambling.com' blocked.
7. Policy 7: Source = All, Destination = All, Service = All, Schedule = always, Action = DENY. Log = enabled. (This is the catch-all deny at the bottom.)

Sarah's ordering is deliberate. The two specific allow policies (Policy 1 and 2) are at the very top. This ensures that when an engineer tries to reach the code repo, the specific policy matches first, and the traffic is allowed. If she had placed a general 'allow all internet' policy above these, the engineer's traffic to the code repo would match that general rule and she could not differentiate the access rules.

Next, the guest Wi-Fi policy (Policy 3) comes before the employee internet policies. This is because the guest subnet is not part of any department subnet, so they would not match the Sales/Engineering/HR policies anyway. But by putting it first, the log will show guest traffic separately.

Finally, the employee internet policies (4,5,6) allow the departments to browse the web, but with a web filter attached that blocks gambling.com. Notice that Policies 4,5,6 are identical in structure (same destination, same service, same profile) but differ in source. This is valid — each policy matches a different source subnet.

The last policy (Policy 7) is the implicit deny made explicit. Sarah writes it herself so that she can enable logging on denials. If someone tries to access an internal server they are not authorised for (like a salesperson trying to reach the payroll server), no policy matches until Policy 7, and that traffic is denied and logged.

This real-world scenario shows exactly how an IT professional thinks: identify the traffic flows, create specific rules, order them with the most restrictive first, and end with a blanket deny. It is a practical workflow that an NSE4 exam candidate must be comfortable with.

## Exam focus

The NSE4 exam tests your understanding of firewall policies and security policies heavily. You will see multiple-choice questions, drag-and-drop ordering tasks, and scenario-based questions where you have to identify the correct policy configuration. Here is exactly what to focus on.

- Policy ordering: This is the single most tested concept. Expect a question like 'You have a policy to allow HTTP from internal to external, and a policy to deny HTTP to www.bad.com. Where should you place the deny policy?' The correct answer is: above the allow policy, because the first matching rule wins. A common trap is that they give you two policies in the wrong order and ask 'What will happen?' The answer is: the traffic will be allowed, not blocked.

- Policy components: You must memorise the exact fields and their meanings. Questions often ask 'Which field in a firewall policy defines the type of traffic?' The answer is 'Service'. Another trap: they might ask 'Which field defines when the policy is active?' The answer is 'Schedule'.

- Implicit deny: The exam loves to test this. Know that if no policy matches, traffic is denied. There is an 'implicit deny' rule at the bottom of every policy set that you cannot delete. A typical question: 'A user cannot access the internet. All firewall policies are correctly configured. What is the most likely cause?' One answer could be 'An implicit deny rule is blocking the traffic because no policy matches the user's source IP or destination.'

- Scheduling: Expect a question that gives you a schedule of 'Monday-Friday, 9:00-17:00' and asks when the policy is active. The trap answer might be 'always active' or 'active on weekends'. The correct answer is the exact hours given.

- Security profiles vs firewall policies: The exam distinguishes between a firewall policy (which just allows/denies) and a security policy (which also includes security profiles like antivirus, web filter, IPS). Be ready to answer 'What must you attach to a firewall policy to enable antivirus scanning?' Answer: a security profile (specifically an antivirus profile).

- Policy lookup: FortiGate has a tool to simulate traffic and see which policy would match. The exam may ask 'How can you test which policy a specific traffic flow will match without sending real traffic?' Answer: Use the 'Policy Lookup' or 'FortiView' tools.

- Address objects and groups: The exam tests how to simplify policy management. Instead of writing 50 policies for 50 individual IPs, you create an address group containing those IPs. A typical question: 'Which object type allows you to group multiple IP addresses for use in a single policy?' Answer: Address group.

- Directional policies: FortiGate policies are stateful, meaning they automatically allow return traffic for connections initiated through an allowed policy. So you do not need a separate policy for return traffic. The exam may try to confuse you by asking 'Do you need a separate policy for reply traffic?' The answer is no.

- Policy ID numbers: The exam might ask 'If you create a new policy without specifying its position, where does it appear?' Answer: At the bottom of the policy list (assuming default placement).

- Logging and monitoring: The exam tests basic logging options. 'Which logging option should you enable to capture denied traffic for troubleshooting?' Answer: Enable logging on the deny policy.

- NAT policies: FortiGate allows you to configure NAT (Network Address Translation) within the firewall policy itself. The exam may ask 'Which field in a firewall policy controls NAT?' Answer: The 'NAT' option under the policy's advanced settings.

Trap patterns to watch:

- The exam might describe a scenario with multiple matching policies and ask 'Which policy takes effect?' Always the one with the lowest ID (higher in the list).
- They might give you a policy with a schedule that is not active at the current time and ask 'What happens to traffic matching that policy?' Answer: The firewall skips to the next policy.
- They might present a 'deny all' policy above a specific 'allow' policy. The trap is that the deny all will block everything, making the allow below it useless.

Key definitions to memorise:

- Firewall policy (security policy): A set of conditions and an action that determines what happens to traffic.
- Implicit deny: The default rule at the bottom of the policy list that denies all traffic not matching any explicit policy.
- Policy ordering: The sequence in which policies are evaluated, from top to bottom.
- Schedule: A time range that defines when a policy is active.
- Service: A definition of a network service (e.g., HTTP, HTTPS) identified by a protocol and port number.

## Step by step

1. **Identify the traffic flow** — Before creating any policy, decide exactly what traffic you want to manage. For example: 'Sales department users (192.168.1.0/24) browsing the web (HTTP/HTTPS) to the internet.' Write down the source IP, destination IP (or 'All'), and service (e.g., HTTP, HTTPS). This step prevents you from creating a policy with overly broad conditions that accidentally allow unwanted traffic.
2. **Create address objects** — In the FortiGate GUI, go to Firewall Objects > Addresses and create an object for each source and destination you identified. For example, create an address object called 'Sales_Subnet' with the IP range 192.168.1.0/24. Using address objects makes your policies readable and reusable. If the subnet changes later, you only edit the object, not every policy.
3. **Define the service** — Select the service for your policy. The FortiGate includes pre-defined services like 'HTTP' (port 80), 'HTTPS' (port 443), 'DNS' (port 53). You can also create custom services for non-standard ports. For this example, use the pre-defined 'HTTP' and 'HTTPS' services. If you need both, you can add them as separate service entries in the policy, or create a service group.
4. **Set the schedule and action** — Choose a schedule. For most policies, 'Always' is fine. If you want time-based restrictions, create a schedule object first (e.g., 'BusinessHours' 09:00-17:00 weekdays). Then set the Action to either 'ACCEPT' (allow traffic) or 'DENY' (block it). For web browsing, you would set Action to 'ACCEPT'. Do not forget to attach any necessary security profiles here (antivirus, web filter) if needed.
5. **Place the policy in the correct order** — After saving the policy, it appears at the bottom of the policy list. Use the 'Move to' button to drag it to the desired position, typically above any more general policies. For example, if you have a general 'allow all internet' policy at the top, move your new specific allow policy above it. Verify ordering using the Policy Lookup tool to ensure the correct policy matches for your test traffic.
6. **Test and log** — After the policy is active, test it by generating traffic (e.g., from a Sales computer try to access a website). Check the FortiGate's log viewer to confirm the policy was hit. Enable logging on the policy itself by selecting 'Log Allowed Traffic' under Logging Options. If you want to see attempted denial, create an explicit deny policy with logging and place it at the bottom.

## Comparisons

### Firewall Policy (Security Policy) vs Access Control List (ACL) used on routers

**Firewall Policy (Security Policy):**
- Stateful: automatically tracks connection state and allows return traffic without a separate rule.
- Evaluated top-down with first match; no 'implicit permit' at the end — only implicit deny.
- Can include security profiles (antivirus, web filter) as part of the policy.

**Access Control List (ACL) used on routers:**
- Stateless: each packet is evaluated independently; return traffic requires an explicit permit rule.
- Can have implicit permit at the end (depending on vendor), or implicit deny; not consistent.
- Only permits or denies based on IP/port; no advanced inspection without additional modules.

### Action = ACCEPT vs Action = DENY

**Action = ACCEPT:**
- Traffic is allowed through the firewall.
- Security profiles (antivirus, web filter, IPS) can be applied to inspect the traffic.
- Logging can be enabled for allowed traffic; logs show which policy permitted the session.

**Action = DENY:**
- Traffic is blocked immediately; no inspection occurs.
- Attaching security profiles is pointless because the traffic is never processed.
- Logging shows the denial if enabled; useful for troubleshooting blocked connections.

### Policy with Schedule = Always vs Policy with Schedule = Business Hours (e.g., 9-5 weekdays)

**Policy with Schedule = Always:**
- Active 24 hours a day, 7 days a week.
- Simple to manage; no risk of accidentally blocking traffic due to incorrect time settings.
- Less secure because traffic is allowed all the time, even outside normal working hours.

**Policy with Schedule = Business Hours (e.g., 9-5 weekdays):**
- Active only during the defined time range; inactive outside those hours.
- Requires careful configuration of time zone and daylight saving time to avoid unexpected blocks.
- Improves security by restricting access to specific times, such as allowing remote admin only during office hours.

### Explicit Deny Policy vs Implicit Deny (built-in default)

**Explicit Deny Policy:**
- Created manually by the administrator and placed at the bottom of the policy list.
- Can have logging enabled so that blocked traffic is recorded in the logs.
- Can be assigned a schedule, logging options, and can be moved — but it is still just a regular policy.

**Implicit Deny (built-in default):**
- Exists automatically at the very end of every policy list; cannot be deleted or modified.
- Does not generate any log entries by default; you cannot see it in action unless you create an explicit deny above it.
- Cannot be scheduled; it is always active as a catch-all for any unmatched traffic.

## Diagram

_Flowchart showing how a FortiGate evaluates firewall policies in order, applying the first match or the implicit deny if no match is found._

```mermaid
flowchart TD
    A[Traffic arrives at FortiGate] --> B{First policy in list?}
    B -->|Matches?| C[Apply that policy's action (ACCEPT or DENY)]
    B -->|No match?| D{Next policy in list?}
    D -->|Matches?| E[Apply that policy's action]
    D -->|No match?| F[Implicit Deny - Block traffic]
    C --> G[If ACCEPT, attach security profiles?]
    G --> H[Log if enabled]
    E --> I[If ACCEPT, attach security profiles?]
    I --> J[Log if enabled]
    F --> K[Log if explicit deny policy exists]
```

## Common misconceptions

- **Misconception:** A firewall policy with 'Deny' action will stop all traffic to that destination even if a policy above it says 'Allow'. **Reality:** A deny policy only applies if it matches first. If an 'Allow' policy appears above it in the list and matches the same traffic, the 'Allow' policy takes effect and the deny policy is never evaluated. (Beginners assume 'Deny' is absolute, like a lock on a door. But a firewall works hierarchically — the highest matching rule wins, not the most restrictive.)
- **Misconception:** If I create a policy allowing HTTPS to a server, I must create a separate policy for the return traffic (the server sending data back). **Reality:** FortiGate is stateful; it automatically tracks the connection and allows return packets for any traffic that was permitted by an outbound policy. (This misconception comes from experience with stateless ACLs (access control lists) on older routers, where you had to explicitly allow return traffic. Beginners carry that assumption over to firewalls.)
- **Misconception:** Scheduling is optional and has no real impact; I can set it to 'Always' and it works the same as no schedule. **Reality:** A policy with no schedule set actually behaves as if the schedule is 'Always'. But if you enable a schedule and set a time range, the policy is only active during those hours. The difference matters for security policies that should only run during business hours. (Because the default 'Always' setting is invisible, beginners think the field does nothing. They often accidentally set a schedule and then wonder why traffic stops working outside that window.)
- **Misconception:** Policy ordering does not matter because the firewall evaluates all policies and picks the best match. **Reality:** The firewall stops at the first match. Ordering is critical. Misordering can cause a broad 'Allow' policy to shadow a specific 'Deny' policy below it. (This confusion comes from a mental model where the firewall compares all policies like a search engine filtering results. In reality, it is a sequential 'if-else if' chain.)
- **Misconception:** I can set the action to 'Deny' and also attach security profiles like antivirus to the same policy. **Reality:** Security profiles only apply to traffic that is 'Accepted' (allowed). If the action is 'Deny', the traffic is blocked before any inspection happens. Attaching profiles to a deny policy is pointless and the GUI may not even let you do it. (Beginners think security profiles are independent of the action. They imagine inspecting a packet before deciding to reject it, but the firewall rejects the packet immediately without further processing.)
- **Misconception:** A firewall policy that allows traffic from 'All' sources to 'All' destinations is safe if I put a strict schedule on it. **Reality:** A policy with source 'All' and destination 'All' is extremely permissive. A schedule restricts when the policy is active, but during those hours it allows any traffic, which can be dangerous. Specific source/destination definitions should always be preferred. (Beginners overestimate the power of scheduling. They think 'if it's only active at 2 AM, it's safe', ignoring that malicious traffic at 2 AM is still malicious.)

## Key takeaways

- Firewall policies are evaluated from top to bottom, and the first matching policy wins, so always place the most specific rules at the top of the list.
- Every FortiGate firewall has an implicit deny rule at the bottom that blocks any traffic not matching an explicit policy, and you cannot remove it.
- A firewall policy consists of at least a source, destination, service, schedule, and action — and optionally includes security profiles for inspection.
- Scheduling restricts when a policy is active; if traffic arrives outside the schedule, the firewall automatically skips to the next policy in the list.
- Because FortiGate is stateful, you only write a policy for the initial outbound connection; the return traffic is automatically allowed.
- Security profiles (such as antivirus, web filtering, or IPS) can only be applied to a policy with an action set to 'Accept', not to a 'Deny' policy.
- You can use address groups to group multiple IP addresses or subnets, simplifying policy management and reducing the number of policies you need.
- Policy ordering is so important that FortiGate provides a 'Policy Lookup' tool to simulate traffic and verify which policy will match before you deploy changes.
- A common exam question tests that if two policies match the same traffic, the one with the lowest policy ID (appearing higher in the list) wins.
- To log denied traffic, you must create an explicit deny policy with logging enabled, because the implicit deny policy does not generate logs by default.

## FAQ

**Do I need to create a policy for return traffic when I allow outbound connections?**

No. FortiGate is a stateful firewall — it tracks the connection, so once it allows the outbound packet, the return traffic is automatically permitted. You only need one policy for the initial outbound flow.

**What happens if two firewall policies match the same traffic?**

The policy that appears higher in the list (with the lower policy ID) wins. The firewall stops evaluating as soon as it finds the first match. This is why ordering is critical.

**How do I block access to a specific website for all users?**

Create a web filter profile that blocks the website's URL category (e.g., 'Gambling'), then attach that profile to your existing 'allow internet' firewall policies. You do not need a separate deny policy for the website — the web filter will block it within the allow policy.

**I added a schedule to my firewall policy, but at the scheduled time the traffic is still passing. Why?**

Check the schedule configuration. Ensure the start time and end time are set correctly and that the time zone on the FortiGate matches your local time. Also verify that there is not another policy above with an 'Always' schedule that matches the same traffic and allows it.

**What is the 'implicit deny' rule and can I modify it?**

The implicit deny is a built-in rule at the very bottom of every policy list that denies any traffic not matching an explicit policy. You cannot delete or modify it. However, you can create an explicit deny policy above it with logging enabled to see which traffic is being blocked.

**Can I attach an antivirus profile to a firewall policy that has 'Deny' as the action?**

Technically you can, but it is pointless. A 'Deny' action blocks the traffic before any security inspection occurs. The antivirus profile will never process the traffic. Only 'Accept' policies benefit from security profiles.

**What is the difference between a 'firewall policy' and a 'security policy' in FortiGate?**

In the FortiGate interface and the NSE4 exam, the terms are used interchangeably. A security policy is just a firewall policy that may also have security profiles (antivirus, web filter, IPS) attached. They are the same object type.

## Check your understanding

1. **A FortiGate has two policies. Policy 1: Allow traffic from any source to any destination. Policy 2: Deny traffic from source 10.0.0.5 to destination 8.8.8.8. A packet arrives from 10.0.0.5 to 8.8.8.8. Which policy matches and what happens?**

   Answer: Policy 1 matches first because it is above Policy 2 (assuming Policy 1 is higher in the list). The traffic is allowed, and Policy 2 is never evaluated.

2. **What three mandatory fields must be configured in a firewall policy to define the traffic it applies to?**

   Answer: Source, destination, and service are the three mandatory fields that define what traffic the policy matches.

3. **What is the default behaviour of FortiGate when no firewall policy matches a packet?**

   Answer: The packet is denied by the implicit deny rule — a built-in default rule at the bottom of the policy list that blocks all unmatched traffic.

4. **You want to block a specific website (www.example.com) for all users, but still allow all other web browsing. Should you create a separate 'Deny' policy for that website, or use a web filter?**

   Answer: You should use a web filter profile attached to your existing 'Allow' web browsing policies. Never create a Deny policy for individual websites, as it would need to be ordered above the Allow policy, and that is inefficient.

5. **A user reports that they can access the internet during the week but cannot on Saturday. What is most likely the cause?**

   Answer: The firewall policy that allows the user's traffic has a schedule set to 'Weekdays only' (Monday to Friday). On Saturday, that policy is inactive, so the next matching policy (if any) applies, or the traffic is denied by the implicit deny rule.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/fortinet-nse4/firewall-policies-and-security-policies