--- title: "Fine-tune Anti-DDoS protection with profiling" description: "Apply a network traffic profile and sensitivity level to your IP addresses to fine-tune VAC DDoS protection" url: https://docs.ovhcloud.com/en/guides/bare-metal-cloud/dedicated-servers/anti-ddos-vac-profiling lang: en lastUpdated: 2026-11-02 --- > For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/en/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/en/llms-full.txt. # Fine-tune Anti-DDoS protection with profiling **Warning:** The profiling feature is in **Beta**. The feature set, profile names and limits may still change slightly before general availability. ## Objective VAC DDoS protection shields every OVHcloud service by default, with no configuration and no extra cost. VAC is a core part of the OVHcloud [Anti-DDoS infrastructure](https://www.ovhcloud.com/en-gb/security/anti-ddos/): a combination of technologies, continuously developed by OVHcloud, that filters incoming traffic so that only legitimate packets reach your server. Detection works from the shape of your traffic — packet rates, connection turnover, sudden changes in volume, or known traffic signatures. Generic detection works well for most protected applications, but it can still misread some more specific yet legitimate workloads: a busy WireGuard tunnel looks like a UDP flood, and live-event audience spikes look like a volumetric attack. The profiling feature lets you describe such services more precisely instead of working around the protection. Pick a profile from the catalogue, choose a sensitivity level, and attach your services. One change to a policy re-tunes every address attached to it. If your workload changes, switch profiles or adjust sensitivity. **In this guide, you will learn how to:** - recognise when your workload needs a profile. - activate profiling on your account and create a policy. - apply a policy to your IP addresses and understand its status. - adjust, disable or delete a policy, and judge its effect. ## Requirements - At least one OVHcloud service with a public IPv4 address. - Access to the "OVHcloud Console". ## Instructions **Contents:** - [Why protection may need fine-tuning](#why) - [How profiling works](#concepts) - [Step 1 — Activating profiling](#activate) - [Step 2 — Creating a policy](#create) - [Step 3 — Adding your IP addresses](#targets) - [Reading the statuses](#statuses) - [Managing your policies](#manage) - [Monitoring the effect of a policy](#monitoring) - [Limitations](#limitations) - [Troubleshooting](#troubleshooting) ### Why protection may need fine-tuning There are two main situations where you may want to tune the default settings: | | What happens | What you observe | | ------------------ | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | **False positive** | Legitimate traffic is read as an attack and gets mitigated. | Dropped sessions, broken tunnels, users cut off during a traffic peak, with no attack actually taking place. | | **False negative** | Attack traffic is not aggressive enough to trip generic thresholds. | Degraded service during an attack that was never fully mitigated. | False positives are the more common case, and a few workloads account for most of them: VPN tunnels, whose UDP packet rates run high; Blockchain/Solana nodes, which use wide port ranges with constant peer turnover; live streaming and voice, which face sudden legitimate audience surges; and web services during a launch or a sale. Create a policy if any of these situations applies: - Legitimate traffic is being mitigated and you have been working around it — forcing TCP mode on a VPN, lowering the MTU, or opening a support ticket after each incident. - You are preparing for a known traffic spike, such as a live event or a product launch. - You are running an application whose traffic is structurally unusual, and you prefer to declare it in advance rather than wait for the first false positive. - An attack was mitigated, but not thoroughly enough, and you want detection to react sooner. If none of these applies, no change is needed: your services stay protected by default. ### How profiling works You create **policies**. A policy pairs a network traffic profile with a sensitivity level, and applies to the public IPv4 addresses or blocks you add to it. #### Network traffic profiles OVHcloud develops and maintains the specific network traffic profiles: when creating a policy, select the one that best matches your workload. | Network traffic profile | Use it for | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | VPN - WireGuard | WireGuard VPN servers. | | VPN - OpenVPN | OpenVPN servers running over UDP, with TCP as a fallback. | | Game Server - Generic | Game servers using both TCP and UDP. More permissive than the UDP-only and TCP-only game profiles, it keeps all game features working during an attack, such as TCP downloads from a server whose game traffic otherwise runs on UDP. | | Game Server - Generic UDP | UDP-based game services. It also suits TeamSpeak traffic. | | Game Server - Generic TCP | TCP-based game protocols. | | VoIP - TeamSpeak | TeamSpeak servers. It also protects most UDP-based game services. | | WebServer - Generic | Web servers receiving HTTP and HTTPS traffic on TCP ports 80 and 443 only. | | Generic - Proxied TCP | Back-end servers whose front end is hosted outside OVHcloud, for example by an external CDN provider. Hosts that legitimately open many connections to the back end are much less likely to be flagged as attackers. | | Blockchain - Solana | Solana nodes, whose legitimate traffic can be very high in volume. | | DNS - Server | DNS servers. It uses the specific traffic patterns of DNS to block as much attack traffic as possible, with minimal impact on legitimate queries. | | Default | A generic profile offering several sensitivity levels. Use it when no other profile matches your workload. | **Warning:** On Bare Metal Game servers, we recommend not combining profiling, especially the Game Server profiles (Generic, Generic UDP and Generic TCP), with IP addresses protected by a **Minecraft Java** [Game DDoS Protection](https://docs.ovhcloud.com/en/guides/bare-metal-cloud/dedicated-servers/firewall-game-ddos.md) rule. Doing so may affect the quality of the overall protection. #### Getting the best results from a profile To get the best results from some profiles: - **VPN - WireGuard:** run WireGuard on its default port, UDP 51820. This avoids losing legitimate traffic during an attack. - **VPN - OpenVPN:** run OpenVPN on its default ports, UDP 1194 and TCP 443. If you do not need the TCP fallback, block that traffic with the [Edge Network Firewall](https://docs.ovhcloud.com/en/guides/bare-metal-cloud/dedicated-servers/firewall-network.md). - **WebServer - Generic:** do not use it if the server also receives UDP traffic. QUIC (HTTP/3) is not supported yet: QUIC traffic is discarded during an attack. - **Generic - Proxied TCP:** choose this profile, rather than WebServer - Generic, when an external CDN or reverse proxy hosted outside OVHcloud sits in front of a web server running at OVHcloud. The origin then receives many connections from a small set of CDN edge addresses, and this profile expects that pattern instead of flagging those addresses as attackers. - **Blockchain - Solana:** during an attack, mitigation avoids affecting legitimate Solana traffic. The trade-off is that highly targeted attacks may let more malicious traffic through to the server. #### Sensitivity Sensitivity sets where the policy sits on the trade-off between mitigating too much and mitigating too little. The levels available depend on the profile. | Sensitivity | Effect | Choose it when | | ----------- | -------------------------------------------------------------- | ------------------------------------------------------------ | | `Low` | Fewer false positives: the most tolerant of legitimate bursts. | Availability during peaks matters more than filtering depth. | | `Medium` | Balanced detection. The recommended starting point. | You are applying a profile for the first time. | | `High` | Fewer false negatives: the most aggressive filtering. | Attacks have been getting through. | #### One policy per IP address An IP address is covered by only one policy. If a block is attached to one policy and an address inside it to another, the most specific entry wins. For example, if `203.0.113.0/24` is attached to a WebServer - Generic policy and `203.0.113.10` to a VPN - WireGuard policy, then `203.0.113.10` uses the VPN - WireGuard policy and the rest of the block uses the WebServer - Generic policy. A policy's settings are kept for an Additional IP address as it moves between your services. They are reset only when the address changes owner or its service is terminated. ### Step 1 — Activating profiling Activation is needed only once per account. 1. Log in to the "OVHcloud Console". 2. During the Beta, click "Discover the console >BETA\_" in the top-right corner. 3. In the side menu, go to "Security" > "Anti-DDoS", then open the "Profiling" tab. 4. Click "Activate profiling". Follow the instructions displayed, if any, to complete the activation. No amount is charged. Once activation is complete, the `Profiling ` tab lists your defined policies. Activating profiling does not change the protection settings of any IP address until you add it to a policy. ### Step 2 — Creating a policy 1. In the "Profiling" tab, click "Create a policy". 2. In the `Name` field, enter a name that identifies the workload, for example `vpn-concentrators`. 3. In the `Network traffic profile` list, select the profile that matches your workload. Its description is displayed below the list. 4. Set the `Sensitivity`. Start with `Medium` unless you already know which way the protection needs to move. 5. Click "Create policy". You add IP addresses once the policy exists. Until then, the policy has the status **Not configured**: it does not apply to any address yet. ### Step 3 — Adding your IP addresses 1. In the policy list, click the policy name, or click the "..." button at the end of its row, then "Edit". 2. In the `Targets` section of the `Edit policy` panel, click the `Add an IP…` field. The list shows the IP blocks and individual IP addresses available on your account. Type the beginning of an address to filter the list. 3. Select an address, or a whole block. If your servers sit in a contiguous block, add the block rather than each address. 4. After selecting an IP block, you can modify the selection in the input field: instead of the whole block, type one of its subnets or a single IP address from that block. 5. Repeat for each address or block, then click "Save changes". A confirmation message is displayed. From then on, VAC DDoS protection for that address follows the policy's profile and sensitivity instead of the generic settings. The change happens in the background: the address is marked **Pending** until it is applied, then the badge disappears. If an address you add already carries legacy Anti-DDoS settings that were not set by a policy, such as custom settings applied by OVHcloud support teams, a `Legacy Anti-DDoS settings detected` window opens when you save. To apply the policy anyway, tick the `I understand ` box, then click `Overwrite and save `. This way you gain control over the IP's protection settings and can change them using the latest profiling options. **Warning:** Overwriting legacy settings is irreversible: they cannot be restored afterwards. If you later disable the policy, the address returns to the default VAC DDoS protection, not to its previous settings. ### Reading the statuses The policy list shows, for each policy, its network traffic profile, sensitivity, number of IP addresses, last attack detected and status. You can filter it by profile, sensitivity and status. | Where | Status | Meaning | | ----------------- | ------------------------------------ | ---------------------------------------------------------------------------------------------- | | Policy list | **Active** | Enabled, with at least one IP address. The protection is tuned. | | Policy list | **Not configured** | Enabled, but with no IP address yet. Add a target. | | Policy list | **Disabled** | Turned off. The default VAC DDoS protection applies to its addresses, which stay attached. | | Policy list | Warning icon next to `Number of IPs` | Some addresses of the policy are still being applied or removed (**Pending** or **Deleting**). | | `Targets` section | No badge | The address is protected by the policy. | | `Targets` section | **Pending** | The address is being synchronised with the profiling system. This can take a few minutes. | | `Targets` section | **Deleting** | The address is being removed from the policy. | ### Managing your policies Each policy has an actions button (`... `) at the end of its row in the policy list, with the following options: | Action | How | Effect | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Change the profile or the sensitivity | "Edit", then change `Network traffic profile` or `Sensitivity` and click "Save changes". | Applies to every address of the policy at once. Move the sensitivity one level at a time and observe before moving again. | | Disable the policy | "Disable", then confirm. | The addresses fall back to the default VAC DDoS protection. They stay attached, and the policy can be enabled again at any time. Use this to rule the profile in or out while troubleshooting, rather than deleting the policy. | | Enable the policy | "Enable" on a disabled policy. | The profile is applied again to the attached addresses. | | Move an address | "Edit", remove the address from the `Targets` section of one policy and save, then add it to another. | An address belongs to only one policy. | | Delete the policy | "Delete", then confirm. | Removes the policy and all its targets. Its addresses return to the default protection. This cannot be undone. | ### Monitoring the effect of a policy A policy changes which traffic gets mitigated, so judge it by comparing mitigation activity before and after applying it. In the OVHcloud Console (during the Beta, open it with the `Discover the console >BETA_ ` button in the top-right corner), go to `Security ` > `Anti-DDoS `. The `Dashboard ` tab lists the attacks detected on your addresses, and, during detection events, the `Traffic ` tab shows the legitimate traffic of the address you select, along with the traffic filtered during mitigated attacks. A policy that does its job filters less traffic during legitimate peaks, and no less during genuine attacks. For more information on the attacks detected on your services, see [Monitor DDoS attacks with the Anti-DDoS dashboard](https://docs.ovhcloud.com/en/guides/bare-metal-cloud/dedicated-servers/network-security-dashboard.md) . If a profile does not behave as expected, tell us with the `Do you like it? ` link at the top of the Profiling page. During the Beta, that feedback is how the catalogue improves. ### Limitations | Limitation | Details | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Policies | 20 per account. | | Administrative region (early Beta) | A policy can only protect IP addresses in the same administrative region as your VAC DDoS protection service — **Europe** or **Canada & APAC**. Adding a prefix that belongs to the other region is not supported yet. | | Target types | IPv4 addresses and IPv4 blocks only. IPv6 support will be added later. | | Public Cloud | Floating IP addresses, including those used by Managed Kubernetes Service, can be added one by one. A policy cannot target a whole Public Cloud project resource yet. | ### Troubleshooting | Issue | Possible cause | Solution | | ------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Legitimate traffic is still dropped | The sensitivity is too high, or the profile does not match the workload. | Lower the sensitivity one level and observe. If the problem persists at `Low`, the profile is probably the wrong match: try another one and report it with the feedback link. | | An attack was not fully mitigated | The sensitivity is too low. | Raise the sensitivity one level, and compare filtered traffic before and after. | | An address stays **Pending** or **Deleting** | The change has not finished applying. | Wait a few minutes and refresh. If the status does not change, [contact support](https://www.ovhcloud.com/en-gb/support-levels/) with the policy name and the address. | | Adding an IP returns an error such as `Prefix 192.0.2.0/24 is in region EU. Your VAC service is in region CA and can only protect CA prefixes for now.` | During early Beta, your service can only protect prefixes in its own administrative region (Europe or Canada & APAC). | Add an IP address that belongs to the same region as your service. This limitation will be removed during the Beta stage. | | Traffic is dropped although the address is in a suitable policy | Another protection layer, such as the Edge Network Firewall or an application-level firewall, may be filtering it. A policy does not override them. | Check your [Edge Network Firewall](https://docs.ovhcloud.com/en/guides/bare-metal-cloud/dedicated-servers/firewall-network.md) rules or specific application-level filtering. | If a profile is applied and the problem persists, a traffic capture (pcap) of the affected flows will help support analyse it. ## Go further [Monitor DDoS attacks with the Anti-DDoS dashboard](https://docs.ovhcloud.com/en/guides/bare-metal-cloud/dedicated-servers/network-security-dashboard.md) [Enabling and configuring the Edge Network Firewall](https://docs.ovhcloud.com/en/guides/bare-metal-cloud/dedicated-servers/firewall-network.md) Join our [community of users](https://community.ovhcloud.com/).