OVH Firewall HowTo

The article not finished yet..

On services we have an interesting feature (which actually not documented. Yet, I hope). It is a Firewall. It was launched in 2014 on brand new managerV6 (OVH control panel), which is now only one can be used — previous versions are not available.

Firewall turns on automatically on every DDoS attack and it is not possible to shut it down until attack will be stopped. That is why so important to keep firewall rules actual! By default, you won’t have rules, so any connections can be established.

Important feature: those rules will not affect connections inside OVH network. I’m sure that is not a bug because Firewall is a part of their VAC (Anti-DDoS solution) — Firewall Network on a scheme.

Firewall is really useful against DDoS attacks. For example, on a regular web server, you will probably only need 80 and 443 ports to be accessible from the internet. As well as rules for outgoing connections (for DNS, mail, system updates, etc..).

Another unobvious feature: you can only have 20 rules. Each rule has its own priority. Higher priority on this table has actually a lower priority in Firewall. That is the really common mistake.

Best practice to refuse ALL IPv4 connections and allow only which you need — usually only 80 and 443. And here is example:

Reject ALL IPv4 traffic on rule 19 (lower priority) and allow 80 and 443 ports for HTTP and HTTPS respectively. To allow outgoing connections, you want to authorize connections with ESTABLISHED state (rule with priority #13).

For DNS I’m using OVH’s internal nameserver (, which is available because it is internal OVH network.

With those rules you can be safe from common DDoS activity, except smart HTTP/L7 flood. HTTP flood needs to be filtered on application layer or on a reverse-proxy (usually, I’m using Nginx + ipset to handle with “bad” hosts — catching IPs from logs and putting them to the ipset with blocking rule). The rest of DDoS activity usually will be filtered automatically by OVH VAC system.

More examples and explanations will be here later.

Dmitry K.

Read more posts by this author.