Enabling and configuring the Edge Network Firewall – Support Guides

Learn how to configure the Edge Network Firewall for your services.

To protect customer services exposed on public IP addresses, OVHcloud offers a stateless firewall that is configured and integrated into the Anti-DDoS infrastructure: the Edge Network Firewall. It limits exposure to DDoS attacks by dropping specified network flows from outside of the OVHcloud network.

You can find more information on our Anti-DDoS solution on our website.

OVHcloud Anti-DDoS infrastructure and game protection services diagram.

Requirements

An OVHcloud service exposed on a dedicated public IP address (Dedicated server, VPS, Public Cloud instance, Hosted Private Cloud, Additional IP, etc.)

OVHcloud Control Panel Access

Direct link: IP
Navigation path: Bare Metal Cloud > Network > IP

NOTE: This feature might be unavailable or limited on servers of the Eco product line.

Please visit our comparison page for more information.

NOTE: The QUIC protocol is current dropped at the OVHcloud network edge, regardless of you Edge Network Firewall setting. For HTTP traffic, please use HTTP/2, which relies on standard TCP.

Instructions

The Edge Network Firewall reduces exposure to network DDoS attacks by allowing users to copy some of the server's firewall rules to the edge of the OVHcloud network. This blocks incoming attacks as close to their source as possible, reducing the risk of saturating server resources or rack connections in the event of major attacks.

Configure the Edge Network Firewall

The Edge Network Firewall can be enabled or disabled by the user at all times, except for one exception: it is automatically enabled when a DDoS attack is detected and cannot be disabled until the attack has ended. As a result, all the rules configured in the firewall are applied for the duration of the attack. This logic allows our customers to offload the firewall rules of the server to the edge of the OVHcloud network for the duration of the attack.

Access the Edge Network Firewall configuration page

To date, this feature is only available for IPv4 addresses.

The Edge Network Firewall protects a specific IP associated with a server (or service). Therefore, if you have a server with multiple IP addresses, you must configure each IP separately.

You can use the drop-down menus underneath "My public IP addresses and associated services" to filter your services.

Click the more options ⋮ button to the right of the relevant IPv4 and select Configure Edge Network Firewall (or click on the status badge in the Edge Firewall column).

UDP fragmentation is blocked (DROP) by default. When enabling the Edge Network Firewall, if you are using a VPN, remember to configure your Maximum Transmission Unit (MTU) correctly. For example, with OpenVPN, you can check MTU test.
The Edge Network Firewall (ENF) integrated into the scrubbing centers (VAC) only handles network traffic coming from outside the OVHcloud network.

NOTE: Please note that you should configure your own local firewalls, even if the Edge Network Firewall has been configured, as its main role is to handle traffic from outside of the OVHcloud network.

If you have configured some rules, we recommend that you check them regularly or when changing how your services are working. As previously mentioned, the Edge Network Firewall will be automatically enabled in case of a DDoS attack, even when disabled in your IP settings.

Configure firewall rules

As of March 2026, the Edge Network Firewall supports rules that apply to port ranges, in addition to the usual single-port rules.

By using port ranges, you can protect applications that require multiple sequential ports with a single entry. This ensures your configuration stays within the 20-rule limit by eliminating the need for separate rules targeting each individual port.

NOTE: The OVHcloud Edge Network Firewall cannot be used to open ports on a server. To open ports on a server, you must go through the firewall of the operating system installed on the server.

For more information, please refer to the following guides: Configuring the Firewall on Windows and Configuring the firewall on Linux with iptables.

Adding rules

Click + Add a rule.

You can set up to 20 rules per IP.

For each rule (excluding TCP), you must choose:

A priority (from 0 to 19, 0 being the first rule to be applied, followed by the others)
A mode (Refuse or Authorise)
The protocol
Source IP (optional)

For each TCP rule, you must choose:

A priority (from 0 to 19, 0 being the first rule to be applied, followed by the others)
A mode (Refuse or Authorise)
The protocol
Source IP (optional)
The source port (optional)
The destination port (optional)
The TCP state (optional)
Fragments (optional)

When configuring a TCP or UDP rule with a port or port range, ensure the source and destination port fields contain either a single number between 1 and 65535 (inclusive) or a port range (two numbers separated by a hyphen, e.g., 8887-8888).

We advise authorizing TCP protocol with an established option (for packets that are part of a previously opened/started session), ICMP packets (for ping and traceroute), and, optionally, UDP DNS responses from external servers (if you use external DNS servers).

Configuration example:

Priority 0: Authorize TCP established
Priority 1: Authorize UDP source port 53.
Priority 2: Authorize ICMP
Priority 19: Refuse IPv4

NOTE: Firewall setups with only "Authorise" mode rules are ineffective. There must be an instruction as to which traffic should be dropped by the firewall. You will see a warning unless such a "Refuse" rule is created.

Once you have your rules in place, you can enable/disable your firewall from the IP screen or by using the slider at the top-right corner of the rules list.

Note that disabled rules are activated the moment an attack is detected. This logic can be used for rules that are only active when a known repeated attack is incoming.

Common mistakes and best practices

Setting both source and destination ports in the same rule

When creating firewall rules, defining both source and destination ports is usually a misconfiguration, as source ports are typically assigned randomly by the client’s operating system (ephemeral ports).

If you lock a rule to a specific source port, it will likely drop legitimate traffic as soon as the client's port changes for the next session. To ensure connectivity, you should only specify the destination port (your service port).

Best Practice: Leave the source port empty, unless you are filtering traffic from a specialized system with a static outbound configuration.

Large port ranges

Creating rules allowing traffic over very large port ranges may be a security risk, as it significantly expands the attack surface on your server. This can result in several issues:

You may inadvertently expose background services that were not meant to be public-facing, thus potentially leaking information about your system, and allowing malicious actors to probe your servers for vulnerabilities.
Audit and troubleshooting become significantly more difficult, as it is harder to check which applications are actually communicating, masking potential misconfigurations or breaches.
Large open UDP ranges are frequently targeted by amplification and reflection attacks, as there is a higher chance of finding public-facing services. Attackers can spoof a targeted IP to send small requests to services in that open range, which then respond with much larger packets. This way, they are effectively using your server to send DDoS attacks, while potentially overwhelming your own bandwidth.

Best Practice: Only use limited ranges for sequential ports required by a single application (e.g., 5000-5100).

Configuration example

To make sure that only the standard ports for SSH (22), HTTP (80), HTTPS (443), and UDP (53) are left open when authorizing the ICMP, follow the rules below:

The rules are sorted from 0 (the first rule read) to 19 (the last). The rule chain stops as soon as a rule is applied to the packet.

For example, a packet for TCP port 80 will be intercepted by rule 2, and the rules that follow will not be applied. A packet for TCP port 25 will only be captured by the last rule (19), which will block it because the firewall does not allow communication on port 25 in the previous rules.

NOTE: The above configuration is only an example and should only be used as a reference if the rules do not apply to the services hosted on your server. You must configure the rules in your firewall to match the services hosted on your server. Incorrect configuration of your firewall rules can result in legitimate traffic being blocked and server services being inaccessible.

Attack mitigation - scrubbing center activity

Our Anti-DDoS infrastructure (VAC) has two modes of operation: automatic and permanent. The mitigation process is done via the automated scrubbing center. This is where our advanced technology takes a deep look at the packets and attempts to remove DDoS traffic while allowing legitimate traffic to pass through.

All OVHcloud IPs are under automatic mitigation. If any malicious traffic is detected, the scrubbing center activates. This state is indicated by the "Forced" status for a given IP address. At this time, the Edge Network Firewall is also active. The situation comes back to normal when the attack is mitigated and no more suspicious activity is observed.

Tip: You can create attack-only firewall rules that only apply after an attack has been detected.
To do this, Edge Network Firewall rules must be created but disabled.

NOTE: If our Anti-DDoS infrastructure mitigates an attack, your Edge Network Firewall rules will eventually be applied, even if you have disabled the firewall. If you have disabled your firewall, remember to delete your rules as well.

Please note that our Anti-DDoS infrastructure cannot be disabled on a service. All OVHcloud products are delivered within the scope of protection, and this cannot be changed.

Network Security Dashboard

For a detailed insight into detected attacks and the results of scrubbing center activities, we encourage you to explore our Network Security Dashboard.

Conclusion

After reading this tutorial, you should be able to configure the Edge Network Firewall to improve the security of your OVHcloud services.

Go further

See our Protecting a Game Server with the Application Firewall guide.

For more information and tutorials, please see our other Dedicated Servers support guides or explore the guides for other OVHcloud products and services.