diff --git a/pages/bare_metal_cloud/dedicated_servers/antispam_best_practices/guide.de-de.md b/pages/bare_metal_cloud/dedicated_servers/antispam_best_practices/guide.de-de.md index d8e8ca6d6e4..763ea96c198 100644 --- a/pages/bare_metal_cloud/dedicated_servers/antispam_best_practices/guide.de-de.md +++ b/pages/bare_metal_cloud/dedicated_servers/antispam_best_practices/guide.de-de.md @@ -76,7 +76,7 @@ Klicken Sie auf den Button `⁝`{.action} neben der entsprechenden IP/Dienst und Klicken Sie im angezeigten Fenster auf `IP entsperren`{.action} unten und bestätigen Sie. -![IP entsperren](images/unblockIP_new.png){.thumbnail} +![IP entsperren](images/unblockip_new.png){.thumbnail} Die IP wird nun entsperrt. Die Operation kann einige Minuten in Anspruch nehmen. diff --git a/pages/bare_metal_cloud/dedicated_servers/antispam_best_practices/guide.en-in.md b/pages/bare_metal_cloud/dedicated_servers/antispam_best_practices/guide.en-in.md deleted file mode 100644 index 38b406fc55e..00000000000 --- a/pages/bare_metal_cloud/dedicated_servers/antispam_best_practices/guide.en-in.md +++ /dev/null @@ -1,282 +0,0 @@ ---- -title: OVHcloud AntiSpam - Best Practices and Unblocking an IP -excerpt: Find out about our antispam best practices and how to unblock an IP blocked for SPAM -updated: 2026-01-06 ---- - -## Objective - -For every IP available with OVHcloud products and services, as an Internet Service Provider, we will register and reserve it with organisations such as [RIPE](https://www.ripe.net/) or [ARIN](https://www.arin.net/). This means that we appear as the IP abuse contact for litigation in the WHOIS database. - -If an IP is reported to organisations such as Spamhaus and SpamCop, which work to combat SPAM, malicious websites and phishing, then the reputation of the entire OVHcloud network is at stake. - -It is therefore important that OVHcloud takes care of the reputation, quality and security of the network, which also forms an important part of your service. - -### How does the protection system work? - -Our system is based on the Vade Secure anti-spam technology. - -Once an IP is "blocked for SPAM", an email will be sent to your account containing information like the example below: - -> -> Dear Customer, -> -> Our anti-spam protection layer has detected that your IP 122.122.122.122 is sending spam. -> -> In order to protect our network, we have blocked the port 25 of your server, at the network level. -> -> To help you investigate about this problem and fix it, here is a sample of some advanced details on your emails: -> -> Destination IP: 188.95.235.33 - Message-ID: d24aa492-5f37-457f-9595-23ddc9e0f714@xxxxxxxxxxxxx.xx.local - Spam score: 300
-> Destination IP: 188.95.235.33 - Message-ID: fc090jdhf934iu09bf084bfo92@xxxxxxxxxxxxx.com - Spam score: 300
-> Destination IP: 188.95.235.33 - Message-ID: P0hbfo93407684bfoqljrlqvpLatS3RRB9rZw7e8s@xxxxxxxxxxxx.online - Spam score: 300
-> Destination IP: 188.95.235.33 - Message-ID: 6ZUnls843bnf0934StxFasYGmhtDJRo@xxxxxxxxxxxx.online - Spam score: 300
-> Destination IP: 188.95.235.33 - Message-ID: zcb.3z54da3kdfkl45802n0c0q98rqcc57e3b8aadfac63b2c408e3f5f9a27.1d44jkgnddfef.166489320375@xxxxxx.xxxx.net - Spam score: 300
-> Destination IP: 188.95.235.33 - Message-ID: zcb.3z54da33hn98v9bcq-nrf3r67cc57e3b8aadfac63b2c408e3f5f9a27.1d44jd9340252.1655508652095@xxxxxx.xxxx.net - Spam score: 300 ->
->
- -## Instructions - -**What to do after receiving the email alert?** - -The procedure involves identifying the problem, resolving it and then unblocking your IP. - -### Identify and resolve the issue - -**Before unblocking an IP:** - -- Stop sending emails (e.g. stop all email software such as qmail, Postfix, Sendmail etc.). -- Check the email queue (e.g. qmHandle for qmail, postqueue -p for Postfix) and clear it. -- Analyse your logs using the **Message-ID** found in the block alert. -- If you are indeed sending SPAM or illegitimate emails, we strongly recommend you to resolve the issue **before** unblocking the IP. Please consult the second part of this guide for email [best practices](#bestpractices). - -Once the issue has been resolved, you can unblock your IP by performing the following steps. - -> [!alert] -> -> Do not unblock the IP under any circumstances without having suspended the sending of emails from your server, otherwise you will immediately get blocked for a second time (and a longer duration). -> - -### Unblock your IP - -#### Unblocking your IP from the OVHcloud Control Panel - -Log in to the [OVHcloud Control Panel](/links/manager), open the `Network`{.action} menu in the left-hand sidebar and click `Public IP Addresses`{.action}. - -You can use the drop-down menu underneath **My public IP addresses and associated services** to filter your services according to category, or directly type the desired IP address in the search bar. - -If you have an alert on any of your IP(s), there will be a red status icon in the **IP Alert** column. - -![Anti spam alert](images/blockedIP_new.png){.thumbnail} - -Click the `⁝`{.action} button next to the corresponding IP/service and select `Anti-spam unblocking`{.action}. - -![antispam](images/antispam_new.png){.thumbnail} - -In the window that appears, click on `Unblock the IP`{.action} at the bottom and confirm. - -![Unblock IP](images/unblockip_new.png){.thumbnail} - -The IP is being released, the operation may take several minutes. - -Once done, your IP will be unblocked. - -#### Unblocking your IP from the OVHcloud API - -Log in to the [OVHcloud API interface](/links/api) according to the [relevant guide](/pages/manage_and_operate/api/first-steps) and follow the steps below. - -First, retrieve the list of IPs for each OVHcloud service (Dedicated Server/Hosted Private Cloud/VPS/Public Cloud): - -> [!api] -> -> @api {v1} /ip GET /ip -> - -**type**: Indicate the type of IP (Dedicated, PCC, VPS, vRack, PCI, etc.) - -Here's an example of what you should see: - -```bash -"2001:41d0:67:d200::/56", -"2001:41d0:68:a00::/56", -"2001:41d0:68:f000::/56", -"2001:41d0:117:db00::/56", -"122.122.122.121/28", -"145.56.222.96/28", -"188.81.49.30/28", -``` - -Next, search for IPs in a particular state with the following call. If you already know the IP blocked, you can move on to the [next step](#unblockip): - -> [!api] -> -> @api {v1} /ip GET /ip/{ip}/spam -> - -**ip**: Specify the IP block retrieved in the previous step with the netmask. For example 122.122.122.121/28.
-**state**: Specify the state you are looking for. - -Here's an example result (in this instance, the 122.122.122.121/28 block was selected): - -```bash -"122.122.122.122" -``` - -If the IP is blocked, you can get information on the blocking with the following call. Otherwise, move on to the [next step](#unblockip). - -> [!api] -> -> @api {v1} /ip GET /ip/{ip}/spam/{ipSpamming} -> - -**ip**: Specify the IP block retrieved in the previous step with the netmask.
-**ipSpamming**: Specify the previously retrieved IP in "blockedForSpam" state, for example. - -Here's an example result (in this instance block 122.122.122.121/28 and IP 122.122.122.122 were selected): - -```bash -time: 3600, -date: "2022-08-29T17:42:50+01:00", -ipSpamming: "122.122.122.122", -state: "blockedForSpam" -``` - -So: - -```bash -- The IP is blocked for 1 hour (or 3600 seconds). -- It was blocked on 29/08/2022 at 5:42 p.m. -- Its current state is blocked. -``` - -If you wish to obtain the statistics on what has been detected, use the following api call, otherwise move on to the [next step](#unblockip). - -> [!api] -> -> @api {v1} /ip GET /ip/{ip}/spam/{ipSpamming}/stats -> - -**ip**: Specify the IP block retrieved in the previous step with the netmask.
-**ipSpamming**: Specify the previously retrieved IP in "blockedForSpam" state, for example.
-**from and to**: Use the date format used in the previous function (YYYY-MM-DDTHH:MM+01:SS). - -Here is an example result: - -```bash -{ -"messageId": "2PXQSX-3JRAUU-SF@obfuscated.com", -"destinationIp": "188.95.235.33", -"date": 1385640992, -"spamscore": 410 -} -``` - -##### **Unblock the IP** - -> [!alert] -> IMPORTANT! -> Do not unblock the IP under any circumstances without having suspended the sending of emails from your server, otherwise you will immediately get blocked for a second time (and a longer duration). -> - -To unblock your IP, use the following call: - -> [!api] -> -> @api {v1} /ip POST /ip/{ip}/spam/{ipSpamming}/unblock -> - -**ip**: Specify the IP block retrieved in the previous step with the netmask.
-**ipSpamming** : Specify the previously retrieved IP in "blockedForSpam" state. - -Here is an example result: - -```bash -"message": "This IP address is still blocked for 129 seconds" -``` - -More than 129 seconds later: - -```bash -time: 3600, -date: "2022-08-29T17:42:50+01:00", -ipSpamming: "122.122.122.122", -state: "unblocking" -``` - -The IP is being released, the operation may take several minutes. - -### In case of false positives - -In some cases, the anti-spam alert may be a false positive. If you have checked and found that the **Message-ID** comes from a legitimate e-mail, then you must ensure that your e-mails comply with the [RFC](#rfc) and the [Best Practices](#bestpractices) indicated below. - -#### RFC - -RFCs (Request For Comments) are documents intended to describe technical aspects of the Internet. They are produced and published by the IETF (Internet Engineering Task Force), a group which basically produces and defines standards. -For more information, see: [RFC](https://en.wikipedia.org/wiki/Request_for_Comments), [IETF](https://www.ietf.org/) and [Internet Draft](https://en.wikipedia.org/wiki/Internet_Draft). - -#### Best Practices - -Best practices are recommended methods which are often based on the RFC documents and are intended to advise you on the best way to proceed. In this instance, this means the basic rules to follow so that your emails are not marked as spam. - -**Sending Volume** - -If your outgoing email volume is very high, you are advised to: - -- reserve an IP block dedicated solely to email usage. -- provide an 'abuse' address on this block in order to receive complaints. -- configure [Reverses](/pages/bare_metal_cloud/dedicated_servers/mail_sending_optimization#configure-the-reverse-ip) on all IPs correctly. - -This operation will enable you to simultaneously isolate the IP and domain reputation if you send emails from various domains, to receive the complaints, and thus do what is necessary to get unblocked by various organisations. It also enables you to locate a problem more quickly on a form that uses domain X or Y, as the emails are not sent out from the same IP and don't have the same reverse. - -**Email Content** - -- Avoid using spammer keywords in your emails such as “buy” and “last chance”, and avoid capital letters, impersonal subjects, exclamation marks, and % discounts. -- Do not forget to provide an **unsubscribe link** for people who have not requested to receive your email or who believe it to be illegitimate. -- Pay particular attention to ensuring that your emails contain the sender's address (or an alias), a subject line and a correct ratio of text, images and links in the body of the message. -- The ratio of text to image and text to link should be high. Do not overload the email with hyperlinks and avoid Javascript. - -**FBL - Feedback Loop** - -This system enables you to follow up on feedback provided by some internet service providers directly, informing you that their users have flagged your message as illicit, and that it has therefore been classified as spam. This will allow you to interact directly with these ISPs regarding your reputation. Some FBLs include: - -- [Yahoo & AOL Postmaster](https://senders.yahooinc.com/contact) -- [SpamCop](https://www.spamcop.net/) -- [Outlook & live.com](https://sendersupport.olc.protection.outlook.com/pm/) - -**Authentication** - -Some authentication services allow you to protect your reputation: - -- **Sender-ID**: An email authentication technology developed by Microsoft which validates the authenticity of your domain name by verifying the IP address of the sender. This technology is based on the IETF standard: [RFC4406](https://datatracker.ietf.org/doc/rfc4406/). -- **SPF**: Sender Policy Framework is a standard for verifying the domain of the sender. It is based on [RFC4408](https://datatracker.ietf.org/doc/rfc4408/) and consists of adding an SPF or TXT field to the domain DNS, which contains the list of IPs authorised to send emails from this domain. -- **Reverse DNS**: Reverse enables your IP to be "translated” into your domain. That allows the domain associated with the IP address to be found. -- **DKIM**: This standard is described in [RFC4871](https://datatracker.ietf.org/doc/html/rfc4871). AOL and Google (Gmail) work on this basis. - -For more information on the above services, please consult our guide on [Optimising the sending of emails](/pages/bare_metal_cloud/dedicated_servers/mail_sending_optimization). - -#### Specific types of email sending - -- **To a Microsoft server (Outlook, etc.)** - -Microsoft uses a whitelist policy. This means that initially, everything starts off on a blacklist, and a specific procedure is required to validate your email server. For more information, please consult the section **To a Microsoft server (Outlook, etc.)** of our guide "[How to prevent your emails from being marked as spam](/pages/bare_metal_cloud/dedicated_servers/mail_sending_optimization)". - -- **To a Gmail server** - -If your recipients are with Gmail, adding specific records (e.g. a DMARC record) may ensure that emails reach them. Here is a Google article that can help you with this: [Add a DMARC record](https://support.google.com/a/answer/2466563/). - -Google also has a [dedicated article](https://support.google.com/mail/answer/81126/) regarding spam prevention to Gmail users. - -### Reporting a false positive - -If your emails do comply, you can inform us by sending a sample of your email (including the header). Our technical support team will then assist you with the next steps. Simply create a support ticket from your OVHcloud Control Panel and include the following information: - -- The IP of the service blocked for SPAM. -- An original copy of the email(s) flagged as SPAM (you should be able to identify that with the **message ID** included in the ANTISPAM email). If no **message ID** is provided, simply send us a copy of the emails sent before receiving the alert. Please only provide the copy of the email flagged as SPAM. -- The .EML file of the email provided, this should include the **header** and **footer** of the email. If you are not familiar with how to extract an .EML file, please consult the following guide: [Retrieving email headers](/pages/web_cloud/email_and_collaborative_solutions/troubleshooting/diagnostic_headers). - -Once the information is sent, our support team will communicate with Vade Secure for further analysis of the case. - -## Go further - -Join our [community of users](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/firewall_game_ddos/guide.en-in.md b/pages/bare_metal_cloud/dedicated_servers/firewall_game_ddos/guide.en-in.md deleted file mode 100644 index abac4b8f62c..00000000000 --- a/pages/bare_metal_cloud/dedicated_servers/firewall_game_ddos/guide.en-in.md +++ /dev/null @@ -1,259 +0,0 @@ ---- -title: "How to protect a Game server with the application firewall" -excerpt: "Learn how to configure the OVHcloud Game DDoS Protection firewall" -updated: 2026-01-06 ---- - - - -## Objective - -This guide's objective is to help you better understand our Game DDoS Protection (also known as *Game firewall*) and to provide instructions on how to configure effective protection. - -> [!primary] -> Find more information on our [Game DDoS Protection on our website](/links/security/ddos). -> - -Our dedicated Bare Metal gaming servers include an additional network attack protection specifically designed to secure gaming applications against targeted attacks, ensuring stability and accessibility for gamers. This dedicated protection solution is both robust and easy to use, allowing you to focus on developing your business without the distraction of defending against cybercrime. - -| ![global-schema](images/global_schema_focus_game_new.png) | -|:--:| -| Anti-DDoS infrastructure & game protection services diagram at OVHcloud | - -## Requirements - -- An [OVHcloud **Game** dedicated server](/links/bare-metal/game) -- Access to the [OVHcloud Control Panel](/links/manager) - -> [!warning] -> This feature might be unavailable or limited on servers of the [**Eco** product line](/links/bare-metal/eco-about). -> -> Please visit our [comparison page](/links/bare-metal/eco-compare) for more information. - -## Instructions - -### Introduction - -The Anti-DDoS Infrastructure, together with the Edge Network firewall, keeps the network safe from common threats (mostly focused on ISO OSI layers 3 and 4). Hosting gaming applications however can be a challenging experience in terms of network security. **Game DDoS Protection** is here to help - this is a Layer 7 (application) firewall focused on protecting specific gaming protocols. Its main advantages are: - -- **Very low latency**: We know that latency and its stability is crucial for online gaming. These solutions are put as close as possible to the servers and work together with a high-performance hardware. -- **2-way**: The platform analyses incoming and outgoing traffic for best understanding of every player's situation. -- **Instant**: It can distinguish real players from harmful attacks on a server from the very first network packets. -- **Always-on**: The ability to detect and stop attacks ensures a smooth experience for sensitive gaming applications without any disruptions and latency changes. - -### Enabling and configuring Game DDoS Protection - -> [!primary] -> The *Game firewall* protects the IP associated with a server. As a result, if you have a server with multiple IP addresses (i.e. [Additional IP addresses](/links/network/additional-ip)), you need to configure each of them separately. -> - -To configure game protection rules for your Bare Metal Game server, log in to the OVHcloud Control Panel and follow these steps: - -- Open `Network`{.action} in the left-hand sidebar. -- Open `Public IP Addresses`{.action}. - -You can filter IP addresses by using the `All service types`{.action} drop-down menu, or directly enter the desired IP address in the search bar. Enter the name or category of the corresponding server: - -| ![configure-game-firewall](images/ip_listing_new.png) | -|:--:| -| IP listing: Find your IP address by corresponding service | - -Navigate to the *Game firewall* configuration: - -| ![game-server](images/firewall_game_01_blur_new.png) | -|:--:| -| Click on the `⁝`{.action} button next to the IP address of your Game server. | - -| ![configure-game-firewall](images/firewall_game_02_new.png) | -|:--:| -| Click on `Configure the GAME firewall`{.action}. | - -Now you can configure game protection rules for the selected IP address. - -> [!primary] -> It is important to note that Game DDoS Protection will not take any action unless game rules are configured. -> - -To enable Game DDoS Protection, simply define game applications and their associated network port range (or single port): - -| ![add-rule-btn](images/firewall_game_03_new.png) | -|:--:| -| On the following screen, click the `Add a rule`{.action} button to add a rule to the *Game firewall*. | - - -Game DDoS Protection allows you to configure up to **100 rules per IP address** that points to the recent GAME-1 and GAME-2 Bare Metal Game servers (2024 and later), or up to **30 rules per IP address** for the older Bare Metal game ranges (usually identified as RISE-GAME or SYS-GAME). - -Please note that supported gaming protocols (game titles and versions that can be protected) may change over time. Moreover, they can be different between older Bare Metal Game server ranges and the newer ones. The most recent list of supported game profiles can be found [here](/links/security/ddos). - -| ![confirm-new-rule](images/firewall_game_04_new.png) | -|:--:| -| Configure game protections by selecting a **Protocol** from the list and defining the **port-range** on which your gaming application is receiving connections (please refer to the game's setup documentation). Then click on the `Confirm`{.action} button to save. You have now successfully configured *Game firewall* rules. | - -*Game firewall* protection rules must not overlap in terms of ports defined. - -The option **Other** may be selected for applications hosted on specific ports (for which there is no available protection) to let client traffic pass through. Please note that there is not much added security for the traffic matching the rule **Other** and it should be used with caution. - -Also, we strongly recommend to set the rule **"Default policy = DROP"** on every IP pointing to your Game server. That option will allow Game DDoS Protection to drop any traffic not matching the defined rules, i.e. all listed game applications will be protected and no other connections will be able to reach your server. - -> [!warning] -> Game DDoS Protection takes effect after the rules defined in the [Edge Network Firewall](/pages/bare_metal_cloud/dedicated_servers/firewall_network). For both to work properly, the Edge Network Firewall cannot be too strict and needs to pass traffic to the Game DDoS Protection. -> - -### Game-specific notices - -#### Ark Survival Evolved - -- **Ark Survival Evolved**: Basic protection engine. -- **Ark Survival Evolved v.311.78**: Updated protection engine, added to the recent GAME-1 and GAME-2 Bare Metal Game Servers (2024 and later). - -#### Counter Strike 2 - -- **Counter Strike 2**: New protection engine added to the recent GAME-1 and GAME-2 Bare Metal Game Servers (2024 and later). - -#### FiveM - -- **FiveM** is a Grand Theft Auto V multiplayer mod by Cfx.re which is now recognized by the game publisher Rockstar. We added FiveM support to the recent GAME-1 and GAME-2 Bare Metal Game Servers (2024 and later). - -#### Rust - -- **Rust** is supported with a dedicated protection profile on all generations of Bare Metal Game servers. Please note that we updated this protection profile (i.e. added RakNet cookies support) for the 3rd gen. of Bare Metal Game servers (2024, EPYC based). - - -#### Minecraft - -Minecraft is well supported by the following profiles: - -- **Minecraft Java**: Should be the best fit for all Minecraft Java versions. It protects the Minecraft Query protocol and is tuned for TCP traffic. It was added in 2024 but is also available for previous generations of Bare Metal Game servers. Use with caution if other UDP games are hosted on the same IP. -- **Minecraft Query**: General Minecraft Query protocol protection. -- **Minecraft Bedrock**: Minecraft Bedrock protection (with RakNet cookies support), added to the recent GAME-1 and GAME-2 Bare Metal Game Servers (2024 and later). -- **Minecraft Pocket Edition**: Minecraft PE/Bedrock protection, the same as Bedrock, kept for compatibility reasons. - -#### Valheim - -- **Valheim**: New protecion engine, added to the recent GAME-1 and GAME-2 Bare Metal Game Servers (2024 and later). - -> [!primary] -> If you host a bigger service with one of the supported games, but still observe false positives from Anti-DDoS Infrastructure systems, please reach out to our support via the [Help Centre](https://help.ovhcloud.com/csm?id=csm_get_help) with all the details to be able to tune up the application profile. -> - -### Using Additional IPs with Game dedicated servers - -Additional IPs are offering a flexible way to manage your applications across multiple servers or hosted services. They provide value for your game-hosting infrastructure by allowing to manage scalability or failover actions without an impact on public IP addresses. With Additional IPs you can also define different geographical IP locations or even leverage your own IP block (using the BYOIP service) for OVHcloud Game servers. - -While Additional IPs are enabling flexibility, there are situations that require some additional attention. - -#### Per-IP configuration specific to a Game server generation - -To provide the most flexibility of configuration, different gaming protection rules can be set on different Additional IPs pointing to the same Bare Metal Game server. -The maximum number of rules and available protection settings are defined on a per-IP address basis, but are specific to the particular Bare Metal Game server generation behind the firewall. - -Differences may be observed between the newer Game servers (3rd gen. of Game Bare Metal servers - 2024, EPYC based) and the older Game servers (previous generations, usually identified as RISE-GAME or SYS-GAME). - -##### Veryfying supported game protections - -All supported Game DDoS Protection protocols for a specific server are visible on the `GAME firewall`{.action} configuration page for any IP address pointing to that server, in the `Game protocol`{.action} drop-down menu: - -| ![control-panel-game-protocols](images/game_protocols_list_new.png) | -|:--:| -| List of supported protection protocols | - -If you prefer automation, protocol details can be retrieved using the OVHcloud APIv6: - -> [!api] -> -> @api {v1} /ip GET /ip/{ip}/game/{ipOnGame} -> - -API response example: - -```python -{ - ipOnGame: "1.2.3.4" - maxRules: 30 - state: "ok" - firewallModeEnabled: true - - supportedProtocols: [ - "arkSurvivalEvolved" - "arma" - "gtaMultiTheftAutoSanAndreas" - "gtaSanAndreasMultiplayerMod" - "hl2Source" - "minecraftPocketEdition" - "minecraftQuery" - "mumble" - "other" - "rust" - "teamspeak2" - "teamspeak3" - "trackmaniaShootmania" - ] -} -``` - - -#### Moving an Additional IP between servers - -While a static rule set configuration may be self-explanatory, Additional IP moving actions may require a few comments. - -- **Moving an IP from an old generation to a new generation of Bare Metal Game servers:** - - The process is transparent and all protection rules and IP settings will be kept. - -- **Moving an IP from a new generation to an old generation of Bare Metal Game servers:** - - If the destination server supports less protection rules than the origin one, an error will be displayed and the action will be stopped. - - Otherwise: - - Backward compatible rules are kept (protection profile name must equal). - - Rules that are not supported on the destination server will be removed. - -- **Moving an IP from a Bare Metal Game server to other servers or services:** - - All Game DDoS Protection rules applied to the IP will be deleted, as they are not supported outside Bare Metal Game servers. - - -## FAQ - -/// details | **Can I use Game DDoS Protection on other ranges than Bare Metal Game servers?** - -No, Game DDoS Protection is only available for our Bare Metal Game dedicated servers. - -/// - -/// details | **How can I ensure automation to work for an Additional IP between a new and an old generation of Bare Metal Game servers?** - -You can either limit your protection rules to 30 per IP or configure your automation scripts so they can remove and add rules before and after moving an IP to another server. We recommend to use the latest generation of Bare Metal Game servers as they come with many improvements. - -/// - -/// details | **Can I disable Game DDoS Protection?** - -This is possible, but not recommended. You can do it by removing all game protocol rules from the configuration and disabling the entry `Default policy: DROP`. - -/// - -/// details | **My game is not on the supported protocol list, what can I do?** - -You can propose your need on our [infrastructure solutions roadmap on GitHub](https://github.com/orgs/ovh/projects/16/views/14). This will help us to decide on prioritization of the next features to be developed. - -/// - -/// details | **While having configured my game with appropriate ports and default policy to drop, I still receive attacks that are impacting my Game server. What to do?** - -You will need to share relevant network traffic dumps as examples for such attacks (*.pcap* file) in order to request protection tuning of your profile. To do this, please log in to our [Help Centre](https://help.ovhcloud.com/csm?id=csm_get_help). - -/// - -## Go further - -If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project. - -Join our [community of users](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/firewall_network/guide.en-in.md b/pages/bare_metal_cloud/dedicated_servers/firewall_network/guide.en-in.md deleted file mode 100644 index cae8e09ac47..00000000000 --- a/pages/bare_metal_cloud/dedicated_servers/firewall_network/guide.en-in.md +++ /dev/null @@ -1,174 +0,0 @@ ---- -title: Enabling and configuring the Edge Network Firewall -excerpt: Find out how to configure the Edge Network Firewall for your services -updated: 2026-01-06 ---- - -## Objective - -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 allows to limit service exposure to DDoS attacks, by dropping specified network flows coming from outside of the OVHcloud network. - -**This guide will show you how to configure the Edge Network Firewall for your services.** - -> [!primary] -> -> You can find more information on our Anti-DDoS solution on [our website](/links/security/antiddos). -> - -| Anti-DDoS infrastructure & Game protection services diagram at OVHcloud | -|:--:| -| ![global-schema](images/global_schema_2025.png) | - -## Requirements - -- An OVHcloud service exposed on a dedicated public IP address ([Dedicated server](/links/bare-metal/bare-metal), [VPS](/links/bare-metal/vps), [Public Cloud instance](/links/public-cloud/public-cloud), [Hosted Private Cloud](/links/hosted-private-cloud/vmware), [Additional IP](/links/network/additional-ip), etc.) -- Access to the [OVHcloud Control Panel](/links/manager) - -> [!warning] -> This feature might be unavailable or limited on servers of the [**Eco** product line](/links/bare-metal/eco-about). -> -> Please visit our [comparison page](/links/bare-metal/eco-compare) for more information. - -> [!warning] -> The Edge Network Firewall does not support QUIC protocol. - -## 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. - -### Enabling Edge Network Firewall - -> [!primary] -> -> To date, this feature is only available for IPv4 addresses. -> - -> [!primary] -> -> 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. -> - -Log in to the [OVHcloud Control Panel](/links/manager), open the `Network`{.action} menu in the left-hand sidebar and click `Public IP Addresses`{.action}. - -You can use the drop-down menu underneath **"My public IP addresses and associated services"** to filter your services according to category, or directly type the desired IP address in the search bar. - -![filter service](images/selectservice_cut_new.png){.thumbnail} - -Next, click the `⁝`{.action} button to the right of the relevant IPv4 and first select `Configure Edge Network Firewall`{.action} (or click on the status badge in the **Edge Firewall** column). - -![Enabling the Network Firewall](images/firewall_config_new.png){.thumbnail} - -You will then be taken to the firewall configuration page. - -You can set up to **20 rules per IP**. - -> [!warning] -> -> The Edge Network Firewall 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 during 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. -> -> 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. -> - -> [!primary] -> -> - 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 in the scrubbing centres (VAC) only handles network traffic coming from outside the OVHcloud network. -> - -### Configure the Edge Network Firewall - -> [!warning] -> Please note that 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](/pages/bare_metal_cloud/dedicated_servers/activate-port-firewall-soft-win) and [Configuring the firewall on Linux with iptables](/pages/bare_metal_cloud/dedicated_servers/firewall-Linux-iptable). -> - -**To add a rule**, click on the `+ Add a rule`{.action} button, on the top left : - -| ![add-rule-btn](images/enf_add_rule_new.png) | -|:--:| -| Click on `+ Add a rule`{.action}. | - -For each rule (excluding TCP), you must choose: - -| ![add-rule-btn](images/enf_add_rule_no_tcp_new.png) | -|:--| -| • A priority (from 0 to 19, 0 being the first rule to be applied, followed by the others)
• An action (`Accept`{.action} or `Deny`{.action})
• The protocol
• Source IP (optional) | - -For each **TCP** rule, you must choose: - -| ![add-rule-btn](images/enf_add_rule_tcp_new.png) | -|:--| -| • A priority (from 0 to 19, 0 being the first rule to be applied, followed by the others)
• An action (`Accept`{.action} or `Deny`{.action})
• The protocol
• Source IP (optional)
• The source port (optional)
• The destination port (optional)
• The TCP state (optional)
• Fragments (optional)| - -> [!primary] -> We advise authorising 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: Authorise TCP established -> - Priority 1: Authorise UDP source port 53 -> - Priority 2: Authorise ICMP -> - Priority 19: Refuse IPv4 - -> [!warning] -> Firewall setups with only "Accept" mode rules are not effective at all. There must be an instruction as to which traffic should be dropped by the firewall. You will see a warning unless such a "Deny" rule is created. -> - -**Enable/disable firewall:** - -| ![activate-desactivate](images/enf_enable_disable_new.png) | -|:--:| -| `Switch on`{.action} to enable | - -After confirmation, the firewall will be enabled or disabled. - -Note that rules are disabled until the moment an attack is detected - then they are activated. This logic can be used for rules that are only active when a known repeated attack is incoming. - -### Configuration example - -To make sure that only the standard ports for SSH (22), HTTP (80), HTTPS (443) and UDP (53) are left open when authorising the ICMP, follow the rules below: - -![Configuration example](images/exemple.png){.thumbnail} - -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. - -> [!warning] -> 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. It is essential that you 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 centre activity - -Our Anti-DDoS infrastructure (VAC) operates automatically. The mitigation process is done via the automated scrubbing centre. 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. In case any malicious traffic is detected, the scrubbing centre 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. - -> [!success] -> **Tips** -> -> 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. -> - -> [!warning] -> 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 detailed insight into detected attacks and the results of scrubbing centre activities, we encourage you to explore our [Network Security Dashboard](/pages/bare_metal_cloud/dedicated_servers/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 - -- [Protecting a game server with the application firewall](/pages/bare_metal_cloud/dedicated_servers/firewall_game_ddos) - -Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/bare_metal_cloud/dedicated_servers/move-failover-ip/guide.en-in.md b/pages/bare_metal_cloud/dedicated_servers/move-failover-ip/guide.en-in.md deleted file mode 100644 index 835014b8770..00000000000 --- a/pages/bare_metal_cloud/dedicated_servers/move-failover-ip/guide.en-in.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: Moving an Additional IP -excerpt: Find out how to move an Additional IP in the Control Panel or via the OVHcloud API -updated: 2026-01-06 ---- - -> [!primary] -> This article is about moving Additional IPv4, which follows [specific regional limitations](#limitations). -> -> Configuring Additional IP addresses in a vRack (private network) circumvents those regional restrictions by not being dependent on a single region, while facilitating interconnection over a wide range of OVHcloud services. -> -> Learn how to configure Additional IP addresses in a vRack with our guides for [IPv4](/pages/bare_metal_cloud/dedicated_servers/configuring-an-ip-block-in-a-vrack) and [IPv6](/pages/bare_metal_cloud/dedicated_servers/configure-an-ipv6-in-a-vrack). -> - -## Objective - -Additional IP addresses can be moved between the services you use. This provides an advantage since you can maintain your IP reputation, your SEO and improve the continuity of service of your applications and systems. - -With this technology, you can switch IP addresses from one solution to another in less than a minute, with virtually no interruption to services for your users. It is useful for service migrations (e.g. moving projects from development to production), or when switching to a backup server during a technical issue. - -> [!primary] -> You can assign your IP address blocks to any compatible service within a region. IP address blocks in a region can be moved from one datacenter to another within that region but cannot be moved outside of that region. Consult our [Limitations](#limitations) section below. -> -> Except for the 3 regions eu-west-gra, eu-west-rbx, and eu-west-sbg, where IP address blocks can be moved between these three regions. -> -> A region is a geographical area composed of one or more datacenters. -> -> Migration only works for whole blocks, it is not possible to migrate individual IPs within a block. - -**This guide explains how to move an Additional IP in your OVHcloud Control Panel or via the OVHcloud API.** - -## Requirements - -- A [dedicated server](/links/bare-metal/bare-metal) in your OVHcloud account -- An [Additional IP address](/links/network/additional-ip) -- Access to the [OVHcloud Control Panel](/links/manager) - -> [!warning] -> This feature might be unavailable or limited on servers of the [**Eco** product line](/links/bare-metal/eco-about). -> -> Please visit our [comparison page](/links/bare-metal/eco-compare) for more information. - -> [!warning] -> If the Additional IP address or one of the block IP addresses has a virtual MAC attached, the target server must support the vMAC functionality. -> See [this guide](/pages/bare_metal_cloud/dedicated_servers/network_support_virtual_mac) for details. -> -> Otherwise, the virtual MACs must be removed from the Additional IPs before the transfer. - -## Instructions - -> [!primary] -> When an IP block containing unique virtual MAC addresses is moved between two servers, those addresses are temporarily suspended. They will appear on the new server once the move is complete. -> -> On the other hand, blocks containing duplicate virtual MAC addresses cannot be moved. You must first delete the duplicate virtual MAC address on the block to be moved. -> -> If an IP block is moved/added to the vRack, it is no longer linked to a physical server. In this case, any virtual MAC address will be lost during the transfer. -> - -### Geolocalised IP blocks - -The geolocation of an IP address is independent of its region of attachment. - -If you order an additional IP block on a server but choose a different location (geolocation) for the IP block, this IP block cannot be moved to another server located in the same country as this block. For example, an additional IP block geolocated in Poland (eu-central-war) and ordered on a server located in a French datacentre (eu-west-gra) cannot be moved to a server located in a Polish datacentre (eu-central-war). The IP block can only be moved to an eligible server located in a French datacentre. - -### Moving an IP from the OVHcloud Control Panel - -> [!warning] -> Only a single size block (/32) can be moved from a dedicated server to a VPS. -> - -Log in to the [OVHcloud Control Panel](/links/manager), open the `Network`{.action} menu in the left-hand sidebar and click `Public IP Addresses`{.action}. - -Then, you can use the drop-down menu underneath **My public IP addresses and associated services** and select `All Additional IPs`{.action} to filter your services accordingly, or directly type the desired IP address in the search bar. - -![manage IPs](/pages/assets/screens/control_panel/product-selection/bare-metal-cloud/network/manage_additional_ips_new.png){.thumbnail} - -Next, click the `⁝`{.action} button to the right of the Additional IP or block of IP addresses you want to move and select `Move Additional IP`{.action}. - -![move Additional](images/move_ip_1_new.png){.thumbnail} - -In the pop-up window, select the service to move the IP address to from the menu. - -![move Additional](images/move_ip_2_new.png){.thumbnail} - -Click `Next`{.action}, then `Confirm`{.action}. - -> [!warning] -> Please note that for some products, IP addresses (or blocks) have to be moved to an IP Parking first (a temporary storage location), before they can be moved to the desired product. -> -> To move IP blocks to a specific vRack network, please use **the vRack management interface**, which you can access by opening the `Network`{.action} menu in the left-hand sidebar, then selecting `vRack private network`{.action}. -> - -### Moving an IP via the API - -Log in to the OVHcloud [API webpage](/links/api). - -First, it is best to check if the IP address can be moved. -
To check if the IP can be moved to one of your dedicated servers, use the following call: - -> [!api] -> -> @api {v1} /dedicated/server GET /dedicated/server/{serviceName}/ipCanBeMovedTo -> - -- `serviceName`: the destination dedicated server reference -- `ip`: the Additional IP address to move - -To move the IP address, use the following call: - -> [!api] -> -> @api {v1} /dedicated/server POST /dedicated/server/{serviceName}/ipMove -> - -- `serviceName`: the destination dedicated server reference -- `ip`: the Additional IP address to move - -### Limitations - -Please note that there are certain limitations when moving an additional IP block. The table below shows the compatibility between regions. - -For more information, consult our list of [available regions](/links/network/additional-ip). - -| Zones | eu-west-par | eu-west-gra | eu-west-rbx | eu-west-sbg | eu-west-lim | eu-central-war | eu-west-eri | ca-east-bhs | ca-east-tor | ap-southeast-sgp | ap-southeast-syd | -|----------------|-------------|-------------|-------------|-------------|-------------|----------------|-------------|-------------|-------------|-------------|-------------| -| eu-west-par | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | -| eu-west-gra | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | -| eu-west-sbg | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | -| eu-west-rbx | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | -| eu-west-lim | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | -| eu-central-war | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | -| eu-west-eri | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | -| ca-east-bhs | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ | -| ca-east-tor | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | -| ap-southeast-sgp| ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | -| ap-southeast-syd| ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | - - -## Go further - -Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/bare_metal_cloud/dedicated_servers/network_bridging/guide.en-in.md b/pages/bare_metal_cloud/dedicated_servers/network_bridging/guide.en-in.md deleted file mode 100644 index 75954127eb7..00000000000 --- a/pages/bare_metal_cloud/dedicated_servers/network_bridging/guide.en-in.md +++ /dev/null @@ -1,567 +0,0 @@ ---- -title: 'Configuring Additional IPs in bridge mode on your virtual machines' -excerpt: 'Find out how to configure your virtual machines for access to the public internet' -updated: 2026-01-06 ---- - - - -> [!primary] -> This article is about Additional IPv4 configuration on a public interface. You can also configure IPv6 addresses on your virtual machines using [this guide](/pages/bare_metal_cloud/dedicated_servers/configure-an-ipv6-on-a-vm). -> -> Please note that Additional IP addresses can also be configured in a vRack (private network), which allows interconnection over a wide range of OVHcloud services, offering more flexibility. -> -> Learn how to configure Additional IP addresses in a vRack with our guides for [IPv4](/pages/bare_metal_cloud/dedicated_servers/configuring-an-ip-block-in-a-vrack) and [IPv6](/pages/bare_metal_cloud/dedicated_servers/configure-an-ipv6-in-a-vrack). -> - -## Objective - -Bridged networking can be used to configure your virtual machines. Some tweaking is necessary to make the network configuration work on our network. - -## Requirements - -- A dedicated server with a hypervisor installed (e.g. Citrix Xen Server, Proxmox, etc.) -- At least one [Additional IP address](/links/network/additional-ip) routed to the server. -- Access to the [OVHcloud Control Panel](/links/manager) or the [OVHcloud API](/pages/manage_and_operate/api/first-steps). - -> [!warning] -> This feature might be unavailable or limited on servers of the [**Eco** product line](/links/bare-metal/eco-about). -> -> Please visit our [comparison page](/links/bare-metal/eco-compare) for more information. -> -> As of May 2025, this guide can be used for servers of the [Scale](/links/bare-metal/scale) and [High Grade](/links/bare-metal/hg) ranges. -> -> Alternatively, to configure Additional IPs using in routed mode or in a vRack, please refer to [Configuring the network on Proxmox VE on the High Grade & Scale ranges](/pages/bare_metal_cloud/dedicated_servers/proxmox-network-HG-Scale) or [Configuring the network on Windows Server with Hyper-V on the High Grade & Scale ranges](/pages/bare_metal_cloud/dedicated_servers/hyperv-network-HG-Scale). -> - -## Instructions - -The basic steps are always the same, independent of the underlying system: - -- creating a virtual MAC address for an [Additional IP](/links/network/additional-ip) -- creating a VM on a host -- setting the MAC address of the VM to that new virtual MAC address -- configuring the **IP address**, **netmask**, **gateway** and **route to the gateway** inside the VM - -Code samples in the following instructions have to be replaced with your own values: - -- SERVER_IP = The main IP address of your server -- ADDITIONAL_IP = The address of your Additional IP -- GATEWAY_IP = The address of your default gateway - -### Assign a virtual MAC address - -> [!warning] -> In the case of a block of IPs, virtual MAC addresses are created on each individual IP in the block. - -Log in to the [OVHcloud Control Panel](/links/manager), open the `Network`{.action} menu in the left-hand sidebar and click `Public IP Addresses`{.action}. - -Then, you can use the drop-down menu underneath **My public IP addresses and associated services** and select **All Additional IPs** to filter your services accordingly, or directly type the desired IP address in the search bar. - -![manage IPs](/pages/assets/screens/control_panel/product-selection/bare-metal-cloud/network/manage_additional_ips_new.png){.thumbnail} - -Next, locate your Additional IP address in the table and click the `⁝`{.action} button to open the menu. Select `Add a virtual MAC`{.action}. - -![Add a virtual MAC (1)](images/addvmac_new.png){.thumbnail} - -Choose `ovh`{.action} from the "Type" drop-down menu unless you are using VMware ESXi - in that case choose `vmware`{.action}. Type a name in the “Name of virtual machine” field, and click on `Confirm`{.action}. - -![Add a virtual MAC (2)](images/addvmac2_new.png){.thumbnail} - -After a few seconds, a virtual MAC will appear in the "Virtual MAC" column of your Additional IP row. This virtual MAC will be required when configuring your VM on the host. - -### Determine the gateway address - -To configure your virtual machines for Internet access, you need to know the gateway of your host machine, i.e. your dedicated server. - -You can retrieve the gateway address via [your customer area](#viacontrolpanel) or the [OVHcloud API](#viaapi). - -> [!tabs] -> **Via the OVHcloud Control Panel** ->> ->> Log in to the [OVHcloud Control Panel](/links/manager), go to the `Bare Metal Cloud`{.action} section and select your server from `Dedicated servers`{.action}. ->> ->> The IPv4 gateway assigned to your server will appear in the `Network` section of the `General Information`{.action} tab. Once you have copied it, continue with applying the configuration. ->> ->> ![gateway](images/ipv4_information.png){.thumbnail} ->> -> **Via the OVHcloud API** ->> ->> On the [OVHcloud API page](/links/console), click on `Login`{.action} in the top right-hand corner. On the next page, enter your OVHcloud credentials. ->> ->> Execute the following API call, indicating the internal server name (example: `ns3956771.ip-169-254-10.eu`): ->> ->> > [!api] ->> > ->> > @api {v1} /dedicated/server GET /dedicated/server/{serviceName}/specifications/network ->> > ->> - -### Prepare the host - -> [!primary] -> -For all operating systems and distributions, you **must** configure your virtual machine with the virtual MAC address you have created in the OVHcloud Control Panel. -> - -> [!tabs] -> **Proxmox** ->> ->> > [!warning] ->> > ->> > The following instructions apply to a previously created VM with an OS already installed. If you have not created a VM, please review the options on the [Qemu/KVM Virtual Machine](https://pve.proxmox.com/wiki/Qemu/KVM_Virtual_Machines) page by Proxmox. ->> > ->> ->> After creating the VM and while it is still powered off, right-click the VM and click `Edit settings`. ->> ->> 1. Select the VM. ->> 2. Open the `Hardware` section. ->> 3. Select `Network Device`. ->> 4. Click the `Edit` button. ->> ->> ![navigate to Network Device](images/proxmox_01.png){.thumbnail} ->> ->> Then add the virtual MAC address created previously. ->> ->> ![open Network Device](images/proxmox_02.png){.thumbnail} ->> ->> Now you can start the VM and proceed with the [configuration steps](#configurationsteps), depending on the operating system installed. ->> -> **VMware ESXi** ->> ->> > [!warning] ->> > ->> > The following instructions apply to a previously created VM with an OS already installed. If you have not created a VM, please review the guide [Create a Virtual Machine in the VMware Host Client](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.hostclient.doc/GUID-77AB6625-F968-4983-A230-A020C0A70326.html) on the VMware page. ->> > ->> ->> After you've created the virtual machine and while it's powered off, right click the VM and click `Edit settings`. ->> ->> ![VM context menu](images/vmware_01.png){.thumbnail} ->> ->> Fold out `Network Adapter 1`, change the value in the `MAC Address` drop-down menu to `Manual` and enter the virtual MAC address created previously. ->> ->> ![Edit settings](images/vmware_02.png){.thumbnail} ->> ->> Now you can start the VM and proceed with the [configuration steps](#configurationsteps), depending on the operating system installed. ->> - -### Configure the virtual machines - -> [!warning] -> -> Please note that the following examples assume that you are logged in as a user with limited privileges, hence the use of *sudo* in front of each command. If you are logged in as *root*, you will not need to do this. -> - -> [!success] -> Select the tab corresponding to your operating system. - -> [!tabs] -> **Debian** ->> ->> By default, the virtual machine's network configuration file is located in `/etc/network/interfaces`. ->> ->> Once you are connected to the shell of your virtual machine, run the following command to identify your interface name: ->> ->> ```bash ->> ls /sys/class/net ->> ``` ->> ->> Next, make a copy of the configuration file, so that you can revert at any time: ->> ->> ```bash ->> sudo cp /etc/network/interfaces /etc/network/interfaces.bak ->> ``` ->> ->> In case of a mistake, you will be able to revert the changes, using the commands below: ->> ->> ```bash ->> sudo rm -f /etc/network/interfaces ->> sudo cp /etc/network/interfaces.bak /etc/network/interfaces ->> ``` ->> ->> Edit the file so that it reflects the configuration below, replace `INTERFACE_NAME`, `ADDITIONAL_IP` and `GATEWAY_IP` with your own values. ->> ->> ```bash ->> sudo nano /etc/network/interfaces ->> ``` ->> ->> ```console ->> auto lo ->> iface lo inet loopback ->> ->> # The primary network interface ->> auto INTERFACE_NAME ->> iface INTERFACE_NAME inet static ->> address ADDITIONAL_IP ->> netmask 255.255.255.255 ->> gateway GATEWAY_IP ->> ``` ->> ->> /// details | **Configuration example** ->> ->> ```console ->> auto lo ->> iface lo inet loopback ->> ->> # The primary network interface ->> auto ens192 ->> iface ens192 inet static ->> address 192.0.2.1 ->> netmask 255.255.255.255 ->> gateway 203.0.113.254 ->> ``` ->> /// ->> ->> Save and close the file.
->> Next, edit or create the file `/etc/resolv.conf`: ->> ->> ```bash ->> sudo nano /etc/resolv.conf ->> ``` ->> ->> Add the following line: ->> ->> ```console ->> nameserver 213.186.33.99 ->> ``` ->> ->> Save and close the file.
->> Now you will need to bring your network interface online. To do so, enter the following command (replace `ens192` with your own values): ->> ->> ```bash ->> sudo ip link set ens192 up ->> ``` ->> ->> Finally, restart your networking service using the following command: ->> ->> ```bash ->> sudo systemctl restart networking ->> ``` ->> -> **Red Hat and Red Hat-based operating systems** ->> CentOS, Rocky Linux 8/9, Alma Linux 8/9, etc. ->> ->> By default, the virtual machine's network configuration file is located in `/etc/sysconfig/network-scripts/`. ->> ->> Once logged into your virtual machine shell, run the following command to identify the name of your interface: ->> ->> ```bash ->> ip a ->> ``` ->> ->> Then make a copy of the configuration file, so that you can go back at any time: ->> ->> ```bash ->> sudo cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0.bak ->> ``` ->> ->> In the event of an error, you can go back to the beginning using the commands below: ->> ->> ```bash ->> sudo rm -f etc/sysconfig/network-scripts/ifcfg-eth0 ->> sudo cp /etc/sysconfig/network-scripts/ifcfg-eth0.bak etc/sysconfig/network-scripts/ifcfg-eth0 ->> ``` ->> ->> You can then edit this file using the `nmcli` handler, replacing `ADDITIONAL_IP` and `GATEWAY_IP` with your own values. ->> ->> - Add the IP address: ->> ->> ```bash ->> sudo nmcli connection modify interface_name IPv4.address ADDITIONAL_IP/32 ->> ``` ->> ->> - Add the Gateway: ->> ->> ```bash ->> sudo nmcli connection modify interface_name IPv4.gateway GATEWAY_IP ->> ``` ->> ->> - Add a DNS server: ->> ->> ```bash ->> sudo nmcli connection modify interface_name IPv4.dns 213.186.33.99 ->> ``` ->> ->> - Change the configuration to manual: ->> ->> ```bash ->> sudo nmcli connection modify interface_name IPv4.method manual ->> ``` ->> ->> - Make the configuration persistent: ->> ->> ```bash ->> sudo nmcli con mod interface_name connection.autoconnect true ->> ``` ->> ->> - Reboot your network with the following command: ->> ->> ```bash ->> sudo nmcli device down interface_name;nmcli device up interface_name ->> ``` ->> ->> For more information on `nmcli`, consult [this page](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/networking_guide/sec-configuring_ip_networking_with_nmcli). ->> -> **FreeBSD** ->> ->> By default, the virtual machine's network configuration file is located in `/etc/rc.conf`. ->> ->> Once you are connected to the shell of your virtual machine, run the following command to identify your interface name: ->> ->> ```bash ->> ifconfig ->> ``` ->> ->> Next, make a copy of the configuration file, so that you can revert at any time: ->> ->> ```bash ->> sudo cp /etc/rc.conf /etc/rc.conf.bak ->> ``` ->> ->> In case of a mistake, you will be able to revert the changes, using the commands below: ->> ->> ```bash ->> sudo rm -f /etc/rc.conf ->> sudo cp /etc/rc.conf.bak /etc/rc.conf ->> ``` ->> ->> Edit the file so that it reflects the configuration below, replace `ADDITIONAL_IP` and `GATEWAY_IP` with your own values. In this example, the interface name is `em0`. Replace this value if it does not apply. ->> ->> ```console ->> ifconfig_em0="inet ADDITIONAL_IP netmask 255.255.255.255 broadcast ADDITIONAL_IP" ->> static_routes="net1 net2" ->> route_net1="-net GATEWAY_IP/32 -interface em0" ->> route_net2="default GATEWAY_IP" ->> ``` ->> ->> Save and close the file.
->> Next, edit or create the file `/etc/resolv.conf` and add this line. ->> ->> ```console ->> nameserver 213.186.33.99 ->> ``` ->> ->> Save and close the file, then reboot your virtual machine. ->> -> **Ubuntu** ->> ->> First, disable cloud-init: ->> ->> ```bash ->> touch /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg ->> ``` ->> ->> > [!warning] ->> > ->> > If you want to configure your VM with cloud-init, go to [this page](https://cloud-init.io/) ->> > ->> ->> Add this line to the `99-disable-network-config.cfg` file: ->> ->> ```bash ->> network: {config: disabled} ->> ``` ->> ->> Then create the network configuration file in `/etc/netplan/` with the following command: ->> ->> ```bash ->> touch /etc/netplan/00-installer-config.yaml ->> ``` ->> ->> Then apply these permissions on `/etc/netplan`: ->> ->> ```bash ->> cd /etc/netplan ->> sudo chmod 600 *.yaml ->> ``` ->> ->> Run the following command to identify the name of your interface: ->> ->> ```bash ->> ip addr ->> ``` ->> ->> Next, make a copy of the configuration file, so that you can revert at any time. For demonstration purposes, our file is called `00-installer-config.yaml`: ->> ->> ```bash ->> sudo cp /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.bak ->> ``` ->> ->> In case of a mistake, you will be able to revert the changes, using the commands below: ->> ->> ```bash ->> sudo rm -f /etc/netplan/00-installer-config.yaml ->> sudo cp /etc/netplan/00-installer-config.yaml.bak /etc/netplan/00-installer-config.yaml ->> ``` ->> ->> Next, open the network configuration file: ->> ->> ```bash ->> sudo nano /etc/netplan/00-installer-config.yaml ->> ``` ->> ->> Edit the file so that it reflects the configuration below, replace `INTERFACE-NAME`, `ADDITIONAL_IP` and `GATEWAY_IP` with your own values. ->> ->> ```yaml ->> network: ->> ethernets: ->> INTERFACE-NAME: ->> dhcp4: true ->> addresses: ->> - ADDITIONAL_IP/32 ->> nameservers: ->> addresses: ->> - 213.186.33.99 ->> routes: ->> - to: 0.0.0.0/0 ->> via: GATEWAY_IP ->> on-link: true ->> version: 2 ->> ``` ->> ->> /// details | **Configuration example** ->> ->> ```yaml ->> network: ->> ethernets: ->> ens18: ->> dhcp4: true ->> addresses: ->> - 192.0.2.1/32 ->> nameservers: ->> addresses: ->> - 213.186.33.99 ->> routes: ->> - to: 0.0.0.0/0 ->> via: 203.0.113.254 ->> on-link: true ->> version: 2 ->> ``` ->> /// ->> ->> Save and close the file. You can test the configuration with the following command: ->> ->> ```bash ->> sudo netplan try ->> ``` ->> ->> If it is correct, apply it using the following command: ->> ->> ```bash ->> sudo netplan apply ->> ``` ->> -> **Windows Servers / Hyper-V** ->> ->> Before configuring your virtual machine, you need to create a virtual switch. ->> ->> From the command line of your dedicated server, run the following command and note the name of the network adapter that contains the server's main IP address: ->> ->> ```powershell ->> ipconfig /all ->> ``` ->> ->> In the Hyper-V Manager, create a new virtual switch and set the connection type to `External`{.action}. ->> ->> Select the adapter with the server’s IP, then tick the option `Allow management operating system to share this network adapter`{.action}. ->> ->> ![networkbridging](images/network-bridging-windows-2012-1.jpg){.thumbnail} ->> ->> > [!primary] ->> > ->> >This step is only required once for a Hyper-V server. For all VMs, a **virtual switch** is required to connect the VM’s **virtual network adapters** to the server’s **physical adapter**. ->> > ->> ->> Next, select the VM you wish to add the Additional IP to. Use the Hyper-V Manager to change the settings of the VM and shut it down. ->> ->> Expand the network adapter in the left-hand menu and click on `Advanced Features`{.action}. Change the MAC address to `Static`{.action}, and enter the virtual MAC address for the Additional IP. Once you have entered these settings, press `OK`{.action} to apply the changes. ->> ->> ![networkbridging](images/network-bridging-windows-2012-2.jpg){.thumbnail} ->> ->> Next, start the VM and log in as an administrator, then go to the `Control Panel`{.action}'s `Network and Sharing Center`{.action}. Click on `Ethernet`{.action} to open the settings and click on the `Properties`{.action} button to view the `Ethernet Properties`. ->> ->> Select `Internet Protocol Version 4 (TCP/IPv4)`{.action}, and then click on the `Properties`{.action} button. ->> ->> ![networkbridging](images/network-bridging-windows-2012-3.jpg){.thumbnail} ->> ->> In the IPv4 Properties window, select `Use the following IP address`{.action}. Enter the Additional IP into the IP address field, and enter 255.255.255.255 into the subnet mask. ->> ->> Fill in your server’s gateway IP address in the appropriate field below and enter 213.186.33.99 into the `Preferred DNS Server`{.action} field. ->> ->> Finally, click `OK`{.action}, and ignore the warning message about the gateway IP and the assigned IP not being in the same subnet. ->> ->> ![networkbridging](images/network-bridging-windows-2012-4.jpg){.thumbnail} ->> ->> After rebooting the server, the VM should be connected to the internet using the Additional IP. ->> - -To verify that the virtual machine is fully connected to the Internet, use the following command: - -**For linux** - -```bash -ping -c 4 example.com -PING example.com (93.184.215.14) 56(84) bytes of data. -64 bytes from 93.184.215.14 (93.184.215.14): icmp_seq=1 ttl=55 time=29.3 ms -64 bytes from 93.184.215.14 (93.184.215.14): icmp_seq=2 ttl=55 time=24.9 ms -64 bytes from 93.184.215.14 (93.184.215.14): icmp_seq=3 ttl=55 time=30.8 ms -64 bytes from 93.184.215.14 (93.184.215.14): icmp_seq=4 ttl=55 time=27.0 ms - ---- example.com ping statistics --- -4 packets transmitted, 4 received, 0% packet loss, time 3004ms -rtt min/avg/max/mdev = 24,925/28,028/30,840/2,254 ms -``` - -**For Windows** - -```bash -ping example.com - -Pinging example.com [93.184.215.14] with 32 bytes of data: -Reply from 93.184.215.14: bytes=32 time=74ms TTL=50 -Reply from 93.184.215.14: bytes=32 time=73ms TTL=50 -Reply from 93.184.215.14: bytes=32 time=73ms TTL=50 -Reply from 93.184.215.14: bytes=32 time=73ms TTL=50 - -Ping statistics for 93.184.215.14: - Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), -Approximate round trip times in milli-seconds: - Minimum = 73ms, Maximum = 74ms, Average = 73ms -``` - -If you receive a response, this means that the Additional IP has been correctly configured. If not, reboot your virtual machine and retry the ping command. - -### Troubleshooting - -If you are unable to establish a connection from your VM to the public network and you suspect a networking problem, please reboot the server in rescue mode and set up the bridging network interface directly on the host. - -Enter the following command in the rescue mode terminal, in which you replace MAC_ADDRESS with the vMAC address that you have generated in the Control Panel and ADDITIONAL_IP with your Additional IP address: - -```bash -ip link add name test-bridge link eth0 type macvlan -ip link set dev test-bridge address MAC_ADDRESS -ip link set test-bridge up -ip addr add ADDITIONAL_IP/32 dev test-bridge -``` - -Next, ping your Additional IP address from an external device. - -- If it responds, that probably means that there is a configuration error either on the VM or the host that prevents the Additional IP from working in normal mode. - -- If the IP address is still not working, please open a support ticket via the [help center](https://help.ovhcloud.com/csm?id=csm_cases_requests) to relay your test results to our support teams. - -## Go further - -Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/bare_metal_cloud/dedicated_servers/network_bridging/guide.it-it.md b/pages/bare_metal_cloud/dedicated_servers/network_bridging/guide.it-it.md index 379f050d4bc..c916fc973ec 100644 --- a/pages/bare_metal_cloud/dedicated_servers/network_bridging/guide.it-it.md +++ b/pages/bare_metal_cloud/dedicated_servers/network_bridging/guide.it-it.md @@ -43,7 +43,7 @@ La connessione di rete in modalità bridge può essere utilizzata per configurar > > Per maggiori informazioni, consulta la nostra [a confronto](/links/bare-metal/eco-compare). > -> Da maggio 2025, questa guida può essere utilizzata per i server di gamma [Scale](/links/bare-metal/scale/) e [High Grade](/links/bare-metal/hg). +> Da maggio 2025, questa guida può essere utilizzata per i server di gamma [Scale](/links/bare-metal/scale) e [High Grade](/links/bare-metal/hg). > > Gli Additional IP possono essere configurati anche in modalità routing o tramite la vRack. Per farlo, consulta: [Configurare la rete su Proxmox VE sulle gamme High Grade & SCALE](/pages/bare_metal_cloud/dedicated_servers/proxmox-network-HG-Scale) e [Configurare la rete su Windows Server con Hyper-V sulle gamme High Grade & SCALE](/pages/bare_metal_cloud/dedicated_servers/hyperv-network-HG-Scale). diff --git a/pages/bare_metal_cloud/virtual_private_servers/configuring-reverse-dns/guide.en-in.md b/pages/bare_metal_cloud/virtual_private_servers/configuring-reverse-dns/guide.en-in.md deleted file mode 100644 index 0ce7f2fbc08..00000000000 --- a/pages/bare_metal_cloud/virtual_private_servers/configuring-reverse-dns/guide.en-in.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: How to configure reverse DNS for your server (PTR record) -excerpt: Find out how to set up the reverse DNS resolution for your IP address in the OVHcloud Control Panel -updated: 2026-01-06 ---- - -## Objective - -Reverse DNS (*rDNS*) is the complement to "forward" DNS resolution which resolves domain names into IP addresses. With reverse DNS resolution, an IP address can resolve into the domain name (or host name) it is mapped to. This means that DNS queries of the associated IP address will return this domain name. - -Configuring the reverse DNS resolution for a server is especially useful when sending emails. A mail server's validation by spam protection systems will improve if a DNS lookup of the IP address resolves properly. - -**This guide explains how to configure the reverse DNS path for your IP address in the OVHcloud Control Panel.** - -## Requirements - -- An IP address attached to a service in your OVHcloud account -- A domain name with its `A` record mapped to your service -- Access to the [OVHcloud Control Panel](/links/manager) - -## Instructions - -Log in to the [OVHcloud Control Panel](/links/manager), open the `Network`{.action} menu in the left-hand sidebar and click `Public IP Addresses`{.action}. - -The drop-down menu underneath **My public IP addresses and associated services** allows you to filter your services according to category. You can also search for a specific IP in the search bar left of the drop-down menu. - -![Reverse DNS](/pages/assets/screens/control_panel/product-selection/bare-metal-cloud/network/filterip_new.png){.thumbnail} - -Click the `⁝`{.action} button in the row of the IP address concerned and select `Configure the reverse DNS`{.action}. - -![Reverse DNS](/pages/assets/screens/control_panel/product-selection/bare-metal-cloud/network/modifyreverse_new.png){.thumbnail} - -In the new window, enter your reverse path and click on `Confirm`{.action}. - -![Reverse DNS](/pages/assets/screens/control_panel/product-selection/bare-metal-cloud/network/enterreverse_new.png){.thumbnail} - -You can also edit the reverse path directly via the `pencil`{.action} icon in the **Reverse DNS** column of the table. - -> [!warning] -> When you enter your domain name in the reverse, it double checks immediately if the A record is referring back to the same IP. This is used in anti-spam procedures, so your A record must be valid and propagated. There are certain rules to follow while entering the reverse: -> -> - It cannot start with a `-`. -> - It cannot be longer than 63 characters. -> - It cannot contain uppercase characters. -> - It must end with a `.`. -> -> Example: "domain.tld" in the reverse record would be `domain.tld.`. -> - -> [!primary] -> -> If the modification does not work as expected, verify that the `A` record is correctly configured in the DNS zone of your domain name. Bear in mind that it might take up to 24 hours for DNS zone changes to be effective, in case you have only recently edited the `A` record. -> -> If the domain name is managed by OVHcloud as its registrar **and it uses OVHcloud DNS servers**, you can refer to [this guide](/pages/web_cloud/domains/dns_zone_edit). -> - -## Go further - -[How to edit an OVHcloud DNS zone](/pages/web_cloud/domains/dns_zone_edit) - -[How to modify the DNS servers of an OVHcloud domain name](/pages/web_cloud/domains/dns_server_edit) - -Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/public_cloud/compute/setup_instance_reverse/guide.en-in.md b/pages/public_cloud/compute/setup_instance_reverse/guide.en-in.md deleted file mode 100644 index f511ac1dda1..00000000000 --- a/pages/public_cloud/compute/setup_instance_reverse/guide.en-in.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: How to configure reverse DNS for a Public Cloud instance -excerpt: Find out how to set up the reverse DNS resolution of your OVHcloud Public Cloud instance -updated: 2026-01-06 ---- - -## Objective - -Reverse DNS (*rDNS*) is the complement to "forward" DNS resolution which resolves domain names into IP addresses. With reverse DNS resolution, an IP address can resolve into the domain name (or host name) it is mapped to. This means that DNS queries of the associated IP address will return this domain name. - -Configuring the reverse DNS resolution for an instance is especially useful when sending emails. A mail server's validation by spam protection systems will improve if a DNS lookup of the IP address resolves properly. - -**This guide explains how to configure the reverse DNS path for the IP address(es) of your Public Cloud instance.** - -## Requirements - -- A [Public Cloud instance](/links/public-cloud/public-cloud) in your OVHcloud account -- A domain name with its `A` record mapped to the instance -- Access to the [OVHcloud Control Panel](/links/manager) - -## Instructions - -Log in to the [OVHcloud Control Panel](/links/manager), go to the `Network`{.action} section and click on `Public IP Addresses`{.action}. - -The drop-down menu underneath **My public IP addresses and associated services** allows you to filter your services according to category. You can also search for a specific IP in the search bar to the left of the drop-down menu. - -![Reverse DNS](/pages/assets/screens/control_panel/product-selection/bare-metal-cloud/network/filterip_new.png){.thumbnail} - -Click on `⁝`{.action} in the row of the IP address concerned and select `Configure the reverse DNS`{.action}. - -![Reverse DNS](/pages/assets/screens/control_panel/product-selection/bare-metal-cloud/network/modifyreverse_new.png){.thumbnail} - -In the new window, enter your reverse path and click on `Confirm`{.action}. - -![Reverse DNS](/pages/assets/screens/control_panel/product-selection/bare-metal-cloud/network/enterreverse_new.png){.thumbnail} - -You can also edit the reverse path directly via the `pencil`{.action} icon in the **Reverse DNS** column of the table. - -> [!primary] -> -If the modification does not work as expected, verify that the `A` record is correctly configured in the DNS zone of your domain name. Bear in mind that it might take up to 24 hours for DNS zone changes to be effective, in case you have only recently edited the `A` record. -> -If the domain name is managed by OVHcloud as its registrar **and** it uses OVHcloud DNS servers, you can refer to [this guide](/pages/web_cloud/domains/dns_zone_edit). -> - -## Go further - -[First steps with Public Cloud instances](/pages/public_cloud/compute/public-cloud-first-steps) - -[How to edit an OVHcloud DNS zone](/pages/web_cloud/domains/dns_zone_edit) - -Join our [community of users](/links/community). \ No newline at end of file