This tutorial will explain how to setup and configure a DDoS protected FiveM server on a Windows Server. This guide assumes that you are already running (and have access to) the FiveM server you wish to protect.

This is guide is primarily user sourced. As always we thank our users for their contributions to the knowledgebase.

Step 1: Backend Setup

Setup FiveM on your server, this server will be from here on referred to as the "backend server". This guide covers a Windows Server setup, however both Windows and Linux are supported (Windows with GRE requires some extra steps).

Please ensure that the game server is running and is able to be connected to via the backend server.

Step 2: Purchase DDoS Protection Service

Pick a suitable package from the DDoS protection page. We suggest choosing one geographically close to your server location (or your primary user base). We offer numerous locations in the United States and Europe.

During the purchase process you will be asked to:

  1. Name your service (important if you plan to have many)
  2. Select the filtering location/network (choose a location close to your backend server)
  3. Select the amount of Clean Bandwidth required to run your service (not attack traffic)

Step 3: Encapsulation Setup (Optional)

This step is only required if you are intending to use a GRE or IP-in-IP. If you are intending to use a Reverse Proxy (RP) style connection (the easiest) then you can skip this step.

A Reverse Proxy only proxies connections to your backend and can be useful for when you do not have command line skills or knowledge to set up a network interface (or when using a panel that does not give access to console).

Note: When running your backend in this mode (Reverse Proxy), make sure that your players do not connect directly to your filtered IP address and instead connect via the server browser listing. If connected directly, their IP address (identifier) will appear to be one of your assigned backend IP addresses (and will trigger false bans if you rely on player IPs). Using encapsulation below solves this potential problem, but may be harder to set-up for you.

An encapsulated backend requires support on the Backend Server, currently Windows and Linux Operating Systems are fully supported, with partial support for FreeBSD. Most Enterprise or even SOHO Routers also support GRE or IP-in-IP tunneling, if supported you may be able to configure the router to terminate the encapsulated network.

Encapsulated networks can be created from your services "Tunnels" page, the link for which can be found in its Action menu. To create a Tunnel you need to specify the backend servers IP address, as well as depending on the encapsulation type chosen security keys (GRE). If unsure as to the appropriate encapsulation type we recommend using GRE. Alternatively to the form in your dashboard you may also use the form below to create a tunnel, just input details for your backend server and select your service.

Internal Address Type Security Key [?] MTU Action
New Tunnel
Backend Address Filtering Endpoint State
Please log in first Disabled

We provide scripts / software to install the encapsulated tunnel onto your backend server in the Dashboard. On your services Tunnels page you should see the list of tunnels which have been created. In the action menu for the tunnel there is a page titled "Setup Tunnel", here you can download the provided Linux setup script, or the Windows tunneling software with your configuration built-in.

For more information on GRE/IP-in-IP Tunnels (including installation instructions for Windows) click here.

Step 4: Add Ports

Add the ports required to run your service. In this case, the default port for FiveM servers is 30120 but may vary depending on your setup. If unsure, you can determine what port the service is bound to by using netstat

When creating your port, make sure you select the FiveM profile from the Protocol dropdown. This profile ensures that only valid FiveM traffic reaches the backend server and works for both UDP and TCP. You can optionally configure additional protection for TCP by creating a HTTPS port. You can read more information about that in the last steps below.

This profile is only available on Anycast services. If you are using a Budget service the closest approximation is the TCP&UDP port which is the same but without any FiveM specific optimization.

There is a form in the dashboard for creating ports. This can be found in your services action menu as the "Ports" page. To add a port click the "Add Port" button towards the bottom of the page. Then fill the created form with the values you can see below in the example / integrated form. Alternatively, you can also use the form below to create the port for your service, just configure the appropriate backend by either:

  1. Selecting the Encapsulated Type, and then the appropriate Tunnel (as created in Step 2); or
  2. Entering a Backend IP address for a Reverse Proxy style port.

Ports Protocol Domain Backend Actions
>
:
 

Note: You can use your service to be open to connections on port 30120 and yet have your backend server run on a non-standard port. Just make sure that your backend server is configured appropriately.

Step 5: Backend Configuration

Reverse Proxies & Encapsulation

In order to direct your players to connect to the filtered and protected IP address provided by X4B, you must first set some important values in your server.cfg file. Replace all instances of <replace_with_filtered_IP> with the IP address assigned to your X4B service:

set sv_forceIndirectListing true
set sv_listingIpOverride "<replace_with_filtered_ip>:30120"
set sv_endpoints "<replace_with_filtered_ip>:30120"

# This is only required for Reverse Proxy setups
set net_tcpconnlimit 10000

Now you can start the server and your players will be connecting through your filtered IP.

Encapsulation Only

The FiveM server (by default) listens for UDP and TCP traffic on all interfaces of the machine that you're running it on. Because of this, we only want it to listen on your local tunnel IP.

Replace all instances of <replace_with_tunnel_IP> with the local tunnel IP address, (which can be found by checking your network interfaces):

endpoint_add_tcp "<replace_with_tunnel_IP>:30120"
endpoint_add_udp "<replace_with_tunnel_IP>:30120"

These two configuration values will need to replace the default ones (with the IP of 0.0.0.0) that are usually located at the top of your server.cfg file. If you skip this step, you will run into issues!

Step 6: HTTPS Configuration (Recommended)

In order to get the most out of your protection, you should consider setting up an additional HTTPS port alongside your already-existing FiveM port. This step will cover that fairly advanced configuration.

Note: If using a HTTPS port in place of the TCP port in the TCP&UDP "FiveM" port complete configuration using the steps below is necessary. The individual steps themselves are not optional.

Start by adding a new port, just like what you did in Step 4. Only this time, select HTTPS as the protocol. Set the internal and external port(s) as the exact same as what you configured on your FiveM-protocol port.

After creating the new HTTPS port, you will be prompted to provide your SSL/TLS certificate and key.

If you want you can retrieve the certificate (and the private key) by heading to where FXServer.exe is located and finding the server-tls.crt and server-tls.key files but you should be fine using a self-signed certificate is also fine (FiveM at this time does not validate SSL certificates). After locating these two files, either upload them or copy-paste them across to the text fields under the SSL page. The certificate itself is the file ending with .crt, while the private key is the one ending with .key.

When SSL is setup, there's a couple things you'll need to tweak before trying to connect:

  1. First of all, you'll need to navigate to the Filtering tab for your HTTPS port and change API Mode (under Mitigation Settings) to API Mode (not Website / Generic Mode).

  2. You will then need to change Protection & Activation to Medium Low: High Load Activation (req/s) and check the automatic activation rate box underneath it.

  3. Go to the Error Pages page for your HTTPS port and enable 497: A HTTP request sent to a HTTPS port - set the Redirection options to the following: https://$host:30120$uri and 308 - Permanent Redirect (POST). Everything else can be left as-is.

Now that you're done with the base requirements to get everything to play nicely with each other, you should test to see if you can connect.

Caching & Rate Limiting

After successful testing, you can now move-on to optimizing your HTTP zones with caching and rate limiting. Go to the Zones page of your HTTPS port and add a Zone for /*.json. Then, go to Advanced Config by clicking on the Actions button for that zone, and set the following values: - Cache Policy: Force - Cache Time: 2 minutes (Any less than that will be invalid, and any greater will likely cause problems with FiveM)

This will cache all *.json endpoints (like players.json) on the edge of the network, accelerating request performance and protecting your backend against HTTP floods.

For rate limiting, go back to the Filtering page of your HTTPS port and use the following values: - Rate Limit: Strict (3r/s) - Burstable Limit: 8 req/s - Max Concurrent: 150

This will rate limit all requests to all HTTP endpoints to the above values. You can configure zone-specific rate limiting under the Zones page, but this isn't required here.

Unrelated to mitigation you may also wish to configure caching for your assets and resources (e.g /files/) via HTTP Zones. This is of course optional.

Layer 7 Mitigation Rules

You can also setup additional mitigation rules that are always active, because X4B is cool like that.

To get started with this, go to the Filtering page of your HTTPS port and select the Mitigation Rules tab.

You can define these however you want, but the rules below protect your resource endpoints and adds some extra checks for valid FiveM client (and proxy) traffic:

# This rule ensures that the only accessible endpoints on your filtered IP (and HTTPS port) are:
# - /client
# - /info.json
# - /dynamic.json
# - /players.json
RequestUri.Regex("^(/client|(/info|/dynamic|/players)\.json)") == false 

# This rule blocks common browsers from accessing any endpoints:
HttpHeader.Exists("via") == true || HttpHeader.Exists("upgrade_insecure_requests") == true

# And this one adds a user-agent check, which will catch most traffic during HTTP floods (unless specialized):
UserAgent.Full() != "CitizenFX/1"

Be aware that if you access any resource endpoints (i.e for prometheus metrics), you will have to do it through your backend IP address if you choose to use these rules. If you have additional endpoints for users (e.g chat) you will have to extend these rules as appropriate as these rules are an example of an explicit whitelist (reject anything unexpected).

You should also generally avoid making any requests to your Filtered IP for purposes such as Discord bots. Use your backend IP for that.

Feel free to add your own rules. As with any changes make sure to test them and do it on a port made for testing to not interrupt any legitimate traffic on a production server.

Step 7: Finish & Test

Once all steps are completed and the progress bar for deployment of the configuration reaches 100% you should be able to connect to your service on your Filtered IP.

This Filtered IP is the address that you should use in any DNS names, or supply to any connecting users. All traffic which arrives at configured ports on a Filtered IP will be filtered for attack, and then forwarded to your configured backend server.

Note: If you (or your network provider) run a firewall either ensure the Backend Communication address (unless otherwise specified, your filtered IP) is whitelisted or that the firewall is disabled.

Have Fun!