It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda Campus Barracuda Campus
Barracuda SecureEdge
Overview Documentation Training Certification Materials

Barracuda Campus is getting an upgrade!

We are excited to announce that Barracuda Campus will migrate to a new platform around mid-January 2026. Please see the announcement on the Campus Dashboard to find out more.

Web Filter Policies

  • Last updated on

The Barracuda SecureEdge Manager allows administrators with appropriate permissions to configure Web Filter policies to protect against potential threats and enforce corporate policies. Barracuda Networks provides a large database, organized in categories, for web filtering. You can either use the provided categories to create rules, or you can specify the domains yourself. Malicious URLs are blocked in the default configuration. For example, web filtering is set to allow all and to block only defined exceptions, whereas the corresponding ACL is set to block all and to allow only defined exceptions.

wfp-table.png
Scope-Based Web Filter Policies

For the scopes available (Site/Edge Service, Agents, All Sources, and DNS Location), you cannot change the scope of an existing Web filter policy.

You can now create scope-based web filter policies via the SecureEdge Manager. When you create a web filter policy, it will be scoped to the sources it comes from. You can now define the scope (such as Site/Edge Service, Agents, All Sources, or DNS Location) of your Web Filter policies. This provides a way to group Web Filter policies based on the service that will apply them. There are currently four scopes under the Security > Web Filter > Policies.

  • Site/Edge Service – The Web Filter rule applies to Site devices / Edge Services. For the Site/Edge Service scope, a Web Filter rule either blocks or allows a domain, URL category, or custom category from any source (such as IP/Network, Site, or User/Group). In addition, for the Web Filter rule, you can now either alert or warn users against suspicious traffic. For the Site/Edge Service scope, the following actions are available for the Web Filter policy:

    • Allow – The user can access the website.

    • Block – The user is blocked from viewing the website.

    • Alert – The user is allowed to access websites in this category, but the action is silently logged. 

    • Warn – The user is redirected to a warning page and must click Continue to access the requested website. For example, a web filter rule exists with SSL Inspection enabled and with a Warn action for different types of selected URL categories (such as social media and lottery). If a user visits a website that matches the filter rule, it allows access to the specific URL categories and/or websites. However, a warning page is shown. When a user clicks Continue in the browser, it will implicitly cause a security inspection.

Note that when you choose Site as source criteria in a Web Filter rule, All Sites are enabled by default, and the Web Filter rules will be enforced by All Sites. However, you can add a specific Site after disabling All Sites. In addition, DNS agents with Sites as the Point of Entry (PoE) use the Sites Web Filter policy.

  • All Sources – For the All Sources scope, a Web Filter rule either blocks or allows a domain, URL category, or custom category from all sources. The following actions are available for the Web Filter policy:

    • Allow – The user can access the website.

    • Block – The user is blocked from viewing the website.

  • DNS Location – With the DNS Location scope, Web Filter policies can be applied to specific locations. Note the following information with respect to the scope DNS Location:

    • For a rule with the DNS Location scope, you can select one or more locations as a source you configured via Infrastructure > Locations. For more information, see How to Add a Location in SecureEdge. You must select at least one location for your source.

    • You cannot change the scope of an existing Web Filter policy.

    • For rules with the scope DNS Location, the following parameters are not applicable:

      • Actions – Alert and Warn

      • Sources – IP/Network, Site, and User/Group

      • The Silent option

  • Agents – This scope enables the evaluation of web filtering rules for the SecureEdge Access Agent. Note the following information regarding the scope Agents:

    • You cannot change the scope of an existing Web Filter policy.

    • You need to select at least one user or one group in the Source Criteria section of the Add New Rule page.

    • You can verify that changes to the Agents scope setting in the Audit Log have been made.

    • Agents-scoped rules have precedence over DNS Location-scoped rules in the Web Filter rule.

    • The following actions are available for the Web Filter policy:

      • Allow – The user can access the website. This is the default action.

      • Block – The user is blocked from viewing the website.

      • Alert – The user is allowed to access websites in this category, but the action is silently logged. 

      • Warn – The user is redirected to a warning page and must click Continue to access the requested website.

For Web Filter policies, the user is provided with a Silent option to block the rule silently if Action is set to Block. Note that you can only use the Silent option for blocking a Web Filter rule. In addition, in the Audit log you can verify that the Silent Blocking value has been made and that notifications have been sent. The Silent option is not available if Action is set to Allow, Alert, or Warn.

The Warn action does not work with any non-SSL-inspectable domains.

For Web Filter policies, wildcards are added implicitly. For example, adding campus.barracuda.com will automatically match www.campus.barracuda.com (or any other subdomain) even without adding a wildcard.

Additional Information

Firefox Browser Settings for SecureEdge Access

On the Firefox browser, the Encrypted Client Hello (ECH) is enabled by default. ECH relies on DNS over HTTPS (DoH) to fetch the necessary public key. For Firefox to work as expected for SecureEdge Access, you must disable DoH from a network by blocking their canary domain.
For example, you create a Web Filter policy to block a specific website (e.g., http://yahoo.com) for all users. When a user tries to access the website using Firefox, the website loads without getting blocked and the notification does not pop up on the SecureEdge Agent. However, the same page is blocked when the user uses a different browser. The reason is that you must disable DoH on Firefox.

Reporting

SecureEdge Reporting allows you to collect data for reports for your connected Sites when Web Filtering is enabled. The Reporting data is streamed according to your selected region.

For more information on logs and reporting, see:

In addition, you can create reports and notifications using an Azure Log Analytics workspace. Your Barracuda SecureEdge service must be connected to the Azure Log Analytics workspace via the Azure Log Analytics Daemon.

For more Information, see:

  Further Information