How to Block Websites and Applications Using FortiGate Firewall Policies

 There are two reasons a block on a FortiGate fails to work, and between them they account for almost every case.

The first is that someone built a beautiful filtering profile and never applied it to a policy. Profiles on this platform do nothing on their own — they are inert until attached to a firewall policy, and the configuration screen gives no indication that a step is missing.

The second is encryption. Without inspection configured, the firewall can see which host a browser is contacting but not what it is requesting. Blocking a specific page on an encrypted site does not work, and the reason has nothing to do with your rule being wrong.

Understanding both before you begin saves considerable frustration when using FortiGate firewall policies for content control.

Four Places Blocking Can Happen

The platform offers several mechanisms, and choosing the right one matters more than configuring any of them carefully.

• DNS Filter. Blocks at the name resolution stage. The client never learns the address. Lightweight, effective against casual access, and easily bypassed by anyone using a different resolver or a direct address.
• Web Filter. Blocks based on the site being requested, either by category or by a specific address you define. The main tool for web content control.
• Application Control. Identifies applications by their traffic signatures rather than by address. This is what handles software that does not use ordinary web addresses, or that moves between servers constantly.
• Firewall policy denial. A plain deny rule based on address, port, and service. Blunt, absolute, and appropriate for whole ranges or protocols rather than for websites.

Most real requirements need two of these working together.

Blocking a Specific Website

Use a Web Filter profile with a static URL filter entry.

The sequence:

• Create or edit a Web Filter profile under Security Profiles.
• Find the static URL filter section and enable it.
• Add an entry for the site, choosing the match type.
• Set the action to Block.
• Attach the profile to the relevant firewall policy.

The match types available:

• Simple matches the exact string.
• Wildcard allows patterns such as *.example.com, which catches subdomains.
• Regular expression offers full pattern matching for complex requirements.

Practical guidance: use wildcard entries rather than simple ones in most cases. Blocking example.com alone frequently misses www.example.com, and users find that within minutes.

Blocking an Entire Category

For broad requirements — gambling, adult content, streaming media — category filtering is far more maintainable than listing individual sites.

The FortiGuard service classifies enormous numbers of sites into categories, and the profile lets you set an action per category:

• Allow permits access silently.
• Monitor permits access and logs it, which is the setting to use when you want visibility before deciding policy.
• Block prevents access and displays a replacement page.
• Warning shows a notice and allows the user to proceed, which is useful for policies you want to discourage rather than prohibit.
• Authenticate requires credentials before access.

The Monitor action deserves more use than it gets. Setting categories to Monitor for a fortnight before blocking anything tells you what people actually access, which is usually different from what anyone assumed.

One operational note: category filtering depends on an active FortiGuard subscription. When it lapses, categorisation stops updating, and eventually the feature degrades.

If a site is categorised incorrectly, FortiGuard accepts submissions for re-rating. This is worth doing rather than adding a permanent exception, because the correction benefits the category logic generally.

Blocking an Application

Application Control identifies software by behavioural signature rather than by destination, which is what makes it effective against things that do not sit at a fixed address.

Typical requirements it handles well:

• Peer-to-peer file sharing.
• Remote access and screen sharing tools.
• Proxy and tunnelling applications.
• Specific social media or messaging platforms.
• Games.
• Cloud storage clients.

Create an Application Control profile, set actions per application or per category, and attach it to the policy. Actions include allowing, monitoring, blocking, and in some configurations applying traffic shaping — throttling an application rather than prohibiting it, which is occasionally a better answer politically.

The SSL Inspection Problem

This is the section that determines whether your filtering actually works, and it is where most guides stop short.

Nearly all web traffic is encrypted. A firewall watching encrypted traffic without inspection sees the destination address and the hostname the client requested during connection setup. It does not see the path, the page, the search terms, or the content.

The practical consequences:

• Blocking an entire site works without inspection, because the hostname is visible.
• Blocking a specific page or path does not work, because that detail is encrypted.
• Antivirus scanning of downloads does not work, because the file is inside the encrypted stream.
• Application identification is limited, relying on behavioural characteristics rather than content.

FortiGate offers two inspection modes:

Certificate inspection examines the certificate and the hostname requested during connection setup. It does not decrypt anything. Minimal performance cost, no client configuration required, and limited visibility.

Deep inspection decrypts the traffic, examines it, and re-encrypts it. Full visibility, substantial processor cost, and it requires the firewall's certificate authority to be installed as trusted on every client device. Without that, users receive certificate warnings on every site.

Deep inspection also carries considerations beyond the technical. It means the firewall can read traffic that users reasonably consider private — including banking and health sites. Most organisations exempt sensitive categories from deep inspection deliberately, and the platform supports exemption lists for exactly this reason. Whether employees are informed that inspection is occurring is a policy and legal question that varies by jurisdiction, and it is worth resolving before deployment rather than afterwards.

The Step People Miss

Worth repeating because it is the single most common failure: a security profile does nothing until it is applied to a firewall policy.

Open the policy governing the traffic you want to filter, enable the relevant security profiles, select the ones you created, set the SSL inspection mode, and save.

If blocking is not working and the profile looks correct, check the policy before checking anything else.

Order of Evaluation

Traffic is evaluated against policies from top to bottom, and the first matching policy wins. Everything below it is never consulted.

The implication: a broad permissive policy near the top of the list silently disables every more specific policy beneath it. If you have a rule permitting all internal traffic to the internet sitting above your filtered policy, the filtered one never applies.

Within a Web Filter profile, static URL filter entries are generally evaluated before category ratings, which lets you create specific exceptions to broad category rules.

The Hard Cases

Some things resist blocking, and being realistic about this prevents wasted effort.

• VPN applications. A user running a commercial VPN tunnels everything, and the firewall sees only an encrypted connection to the VPN provider. Application Control can identify and block many of these, but the arms race is continuous.
• Proxy websites. New ones appear constantly. Category filtering catches most, and not immediately.
• Applications using shared infrastructure. Blocking something hosted on a major cloud platform by address risks blocking a great deal else.
• Mobile data. A phone on cellular data is not passing through your firewall at all.

The honest position: filtering handles casual and accidental access well. A determined user with administrative rights on their own device will find a way, and the remedy for that is organisational rather than technical.

Exceptions for Specific Users

Requirements are rarely uniform. Marketing may need social media that everyone else should not have.

Two approaches:

• Separate policies by source. Place the exempt group in a different VLAN or address group, and write a policy for them above the general one with different profiles applied.
• Identity-based policies. Integrate with your directory service so policies reference user groups rather than addresses. More flexible, more work to set up, and considerably more maintainable long-term.

The Block Page Matters More Than You Think

When a user hits a block, what they see determines whether you get a sensible support request or a vague complaint that the internet is broken.

The default replacement page is functional and anonymous. Customising it is a small amount of work with a disproportionate return:

• State which category or rule caused the block, so the user can describe it accurately.
• Include a reference or session identifier, which lets you find the exact log entry rather than searching by approximate time.
• Name the process for requesting an exception, rather than leaving people to guess.
• Use the organisation's own wording, because a page that looks like the company's makes it obvious this is policy rather than a fault.

The failure mode without this is predictable. A user sees an unfamiliar error, assumes the site is down, tries again from their phone, discovers it works, and concludes the network is unreliable. Nobody reports anything, and the same block generates quiet frustration for months.

One related setting: certain applications handle blocks poorly, showing a timeout rather than the replacement page because they cannot render it. When users report that something "just hangs," check whether it is being blocked rather than assuming a connectivity fault.

When a Block Is Not Working

Work through in this order:

1. Is the profile applied to the policy? Check first, always.
2. Is this policy actually the one matching the traffic? Use the policy lookup tool to confirm.
3. Is a policy above it matching first? Check the order.
4. Is SSL inspection configured appropriately for what you are trying to block?
5. Is the site categorised as you expect? Use the FortiGuard lookup to check.
6. Is the client using a different DNS resolver or an encrypted DNS service that bypasses your filtering?
7. Check the logs to see what the firewall actually decided about that traffic.

That final step is the decisive one. The forward traffic log shows which policy handled a session and what action was taken, which converts guesswork into an answer.

Content filtering with FortiGate firewall policies is straightforward once the two structural issues are understood: profiles must be attached to policies, and encryption limits what the firewall can see. Almost every difficulty traces back to one of those two.