# Application Filters
Source: https://docs.packets-decreaser.net/ddos-protection/layer-4/application-filters



DDoS filters are active by default on all protected IPs. Each filter only permits traffic that matches the expected protocol signature for that application, blocking everything else on the covered port range. No configuration is required to benefit from these filters.

## Active application filters

<AccordionGroup>
  <Accordion title="WireGuard (UDP)" icon="shield">
    **Protocol:** UDP

    **Default ports:** 51820–51920

    Only traffic conforming to the WireGuard protocol specification is permitted on these ports. Non-WireGuard UDP traffic targeting ports in this range is dropped.
  </Accordion>

  <Accordion title="OpenVPN (UDP)" icon="lock">
    **Protocol:** UDP

    **Default ports:** 1194–1294

    Only OpenVPN UDP traffic is permitted on these ports. There is no TCP OpenVPN filter — if you run OpenVPN over TCP, your traffic is covered by the standard TCP protection layer rather than this application-specific filter.

    <Warning>
      The OpenVPN filter covers UDP only. TCP-based OpenVPN deployments are not covered by this dedicated filter.
    </Warning>
  </Accordion>

  <Accordion title="SSH (TCP)" icon="terminal">
    **Protocol:** TCP

    **Default port:** 22

    Only SSH protocol traffic is permitted on port 22.

    <Tip>
      If you have moved SSH to a non-standard port for security reasons, the default SSH filter will not cover that port.
    </Tip>
  </Accordion>

  <Accordion title="TeamSpeak 3 (UDP)" icon="microphone">
    **Protocol:** UDP

    **Default ports:** 9000–9999

    Only TeamSpeak 3 voice traffic is permitted on these ports. TeamSpeak filesharing and server query ports are not covered by this voice filter, those ports fall under the default TCP protection.
  </Accordion>
</AccordionGroup>

## Summary table

| Application | Protocol | Default ports | Notes                                                      |
| ----------- | -------- | ------------- | ---------------------------------------------------------- |
| WireGuard   | UDP      | 51820–51920   | WireGuard specific traffic only                            |
| OpenVPN     | UDP      | 1194–1294     | UDP only \| no TCP OpenVPN filter                          |
| SSH         | TCP      | 22            | SSH specific traffic only                                  |
| TeamSpeak 3 | UDP      | 9000–9999     | Voice traffic only \| filesharing/query via TCP protection |


# Minecraft Java / Bedrock
Source: https://docs.packets-decreaser.net/ddos-protection/layer-4/game-filters/Filter options/minecraft-java-and-bedrock



## Protocol Settings

<CardGroup>
  <Card title="Protocol Filter" icon="shield-check">
    Enables protocol validation of incoming Minecraft network packets.

    It inspects handshakes, verifies packet length, and drops malformed or manipulated payload directly at the edge layer before reaching your  backend.
  </Card>

  <Card title="Drop all UDP & Bedrock Support" icon="filter">
    Blocks all incoming UDP traffic. Requires DNS over TCP.

    Allow Bedrock (UDP 19100–19200): Exemption for Minecraft Bedrock Edition, Geyser cross-play, or RakNet while Drop all UDP is enabled.
  </Card>
</CardGroup>

<Note>
  Drop all UDP needs DNS over TCP!
</Note>

***

## Layer 7 Validation & Bot Protection

<CardGroup>
  <Card title="Layer 7 Validation" icon="network-wired">
    Inspects connections at the application layer to distinguish malicious bots from real players.
  </Card>

  <Card title="Limbo Backend" icon="server">
    Routes first time joining players into an internal limbo server to perform passive and active antibot checks.
  </Card>
</CardGroup>

### Active Checks

Select which specific checks should be performed on the limbo server:

| Check                    | Description                                            |
| :----------------------- | :----------------------------------------------------- |
| **Fall check**           | Validates player falling behavior upon spawning.       |
| **Explosion knockback**  | Tests client response to explosion knockback forces.   |
| **Keep-alive latency**   | Validates client ping and response times.              |
| **Movement**             | Analyzes basic movement data for plausibility.         |
| **Movement jitter**      | Detects unnatural micro movements typical of botnets.  |
| **Map CAPTCHA**          | Displays an ingame map requiring a CAPTCHA code entry. |
| **Website verification** | Requires players to verify via a web browser.          |

### Legacy Clients (\< 1.9)

Defines how older Minecraft client versions are handled, as they do not support all checks. Available actions:

* **Kick:** Immediately disconnects legacy clients.
* **Map CAPTCHA:** Forces legacy clients to solve a Map CAPTCHA.
* **Website 2FA:** Redirects players to a website for verification.
* **CAPTCHA + 2FA:** Combines both verification methods.

***


# FiveM
Source: https://docs.packets-decreaser.net/ddos-protection/layer-4/game-filters/Filter options/untitled-page



## Layer 7 Settings

<CardGroup>
  <Card title="L7 Validation" icon="bolt">
    Enables deep packet inspection specifically designed for FiveM traffic. It actively validates initial handshake attempts and filters out automated L7 attack vectors before they can reach your server backend.
  </Card>

  <Card title="Client Mode" icon="gamepad">
    Configures how traffic is handled based on your server's underlying architecture.

    Select between **Legacy** or **Enhanced** depending on the specific FiveM artifacts and configuration your server uses.
  </Card>
</CardGroup>

***

## Traffic & Filtering Rules

<CardGroup>
  <Card title="HTTP/S Gate" icon="lock">
    Enforces strict web traffic filtering. Drops all TCP connection attempts to the fivem range  that do not match a valid HTTP request (`GET`/`POST`/`HEAD`) or an authentic TLS handshake.
  </Card>

  <Card title="UDP-only-to-game-port" icon="filter">
    Restricts incoming UDP packets. Automatically blocks all incoming UDP traffic addressed to this host, except for packets explicitly directed at your defined game ports (`30000–32000`).
  </Card>
</CardGroup>

<Note>
  Drop all UDP needs DNS over TCP!
</Note>

***


# How Packets Decreaser Mitigates DDoS Attacks
Source: https://docs.packets-decreaser.net/ddos-protection/layer-4/how-we-mitigate

A full walkthrough of the multi-stage DDoS mitigation pipeline: pre-filtering, generic scrubbing, ZAPR, and expected time to mitigate.

When an attack targets your infrastructure, Packets Decreaser routes traffic through a layered mitigation pipeline that combines TCP/UDP authentication, hardware-accelerated packet scrubbing, and machine-learning-based zero-day detection. Each stage hands off only clean traffic to the next, ensuring your services stay reachable under even large-scale or complex attacks.

## Mitigation pipeline

<Steps>
  <Step title="Pre-filter">
    The Pre-filter is the first line of defense and is optimised for application-specific attack patterns. It enforces strict TCP and UDP authentication before any traffic reaches your infrastructure.

    **TCP authentication** — new TCP clients must complete the initial handshake twice: once with the DDoS Filters, which then transparently re-forward the established session. This eliminates spoofed SYN floods before they reach your server.

    **UDP scrubbing** — for supported games and applications, all UDP traffic flows permanently through the filters. Sessions established only a few seconds after the attack threshold is crossed may still be dropped during the brief detection window.

    <Note>
      The Pre-filter is not a generic solution. It is designed for application-specific attacks where strict protocol enforcement is practical.
    </Note>
  </Step>

  <Step title="Generic filter">
    Traffic that passes the Pre-filter is handed off to the generic mitigation layer, powered by a cluster of Intel Xeon and AMD EPYC systems equipped with Mellanox network cards. This layer handles a broad range of volumetric and protocol-level attacks.

    <AccordionGroup>
      <Accordion title="Protocol attack protection">
        * Invalid packets
        * Anomalous TCP flag combinations (no flag, SYN-FIN, SYN fragmented, LAND attack)
        * SYN-ACK amplification attack protection
        * Malicious IP options
        * Packet size validation (prevents Ping of Death)
        * TCP, UDP, SSL, and ICMP flood protection
        * Per-connection traffic control
      </Accordion>

      <Accordion title="Challenge-based authentication">
        * TCP SYN cookies and SYN authentication
        * ACK authentication
        * Spoof detection
        * DNS authentication
      </Accordion>
    </AccordionGroup>
  </Step>

  <Step title="ZAPR — Zero-day Automated Protection">
    ZAPR is the final and most adaptive stage of the pipeline. It uses machine learning to detect and block novel attack patterns that have no known signature.

    <AccordionGroup>
      <Accordion title="ZAPR capabilities">
        * Machine learning-powered attack pattern recognition
        * TCP progression tracking to identify abnormal session behaviour
        * Capability to prevent zero-day attacks with no pre-configuration
        * No manual intervention required — the system responds automatically
        * Fast, automated response typically within seconds of pattern detection
      </Accordion>
    </AccordionGroup>

    <Tip>
      Because ZAPR requires no pre-configuration, it protects against attack types that have never been seen before — without you needing to open a support ticket or write custom rules.
    </Tip>
  </Step>
</Steps>

## Additional mitigation techniques

For clients with specific requirements or under complex attacks, Packets Decreaser offers customisations beyond the standard pipeline.

<AccordionGroup>
  <Accordion title="IP blacklists">
    Deny access to known malicious IP addresses. These lists can be applied immediately without affecting legitimate traffic.
  </Accordion>
</AccordionGroup>

<Info>
  The above customisations are available on request. Contact support to discuss your specific requirements and confirm what is available for your plan.
</Info>

## Time to mitigate

Attacks are typically mitigated within **2–10 seconds** of detection. The table below shows expected mitigation windows by attack type.

| Attack type                   | Typical time to mitigate    |
| ----------------------------- | --------------------------- |
| Standard attacks              | 2–5 seconds                 |
| Large-scale attacks           | Up to 10 seconds            |
| Carpet bombing (subnet-level) | Typically within 10 seconds |

Two factors influence how quickly an attack is mitigated:

1. **Attack size** — larger attacks are often mitigated more quickly because the sudden spike in traffic makes the anomaly easier to detect.
2. **Attack complexity** — more sophisticated or multi-vector attacks may require additional time as ZAPR refines its pattern recognition.


# Known Technical Impact
Source: https://docs.packets-decreaser.net/ddos-protection/layer-4/known-technical-impact



## TCP authentication under permanent protection

Permanent protection forces TCP authentication on every new connection. This means the very first packet in a new TCP session is reset, and the client must initiate a second handshake to complete the connection.

<Info>
  This behaviour is by design and is not a sign of misconfiguration. Standard TCP clients retry automatically and the impact is typically sub-second.
</Info>

<Warning>
  Cloudflare and other CDN providers typically do not retry after receiving a TCP reset. \
  \
  If you route traffic through a CDN, mitigation will break that path. This is a known incompatibility.
</Warning>

## Rate limiting during active attacks

The following traffic types are subject to rate limiting, but **only while an attack of the same type is actively ongoing**. Rate limits are not applied to clean traffic outside of attack windows.

| Traffic type | Condition for rate limiting             |
| ------------ | --------------------------------------- |
| TCP          | Only during an active TCP attack        |
| UDP          | Only during an active UDP attack        |
| ICMP         | Rate limited or blocked under attack    |
| DNS          | Limited to common resolvers (see below) |

<Note>
  By default, all UDP ports not covered by a specific application or game filter are limited to a specific destination limit. If your UDP service uses a non-standard port, please contact Support to request a dedicated filter or further assistance.
</Note>

## DNS resolver restrictions

During a DNS attack, DNS traffic is restricted to requests sourced from the following well-known public resolvers:

* `1.1.1.1` and `1.0.0.1` — Cloudflare DNS
* `8.8.8.8` and `8.8.4.4` — Google Public DNS
* `9.9.9.9` — Quad9

DNS queries from resolvers outside this list may be dropped while mitigation is active. \
If your application relies on a private or non-standard resolver, be aware that DNS resolution may fail for users behind those resolvers during an attack.


# Remote DDoS Protection via GRE Tunnel
Source: https://docs.packets-decreaser.net/gre-tunnel

Use a GRE tunnel over IPv4 to route any server's traffic through Packets Decreaser scrubbing, wherever the server is hosted.

Remote DDoS protection via GRE (Generic Routing Encapsulation) lets you place any server, regardless of its physical location or hosting provider, behind our scrubbing infrastructure. Packets Decreaser sets up a GRE tunnel using an IPv6 address and routes your protected IPs to that endpoint entirely in software.

<Note>
  Hardware GRE tunnels support a maximum throughput of **40 Gbits or** 59 Mpps. If your traffic volume exceeds this, contact support to discuss alternatives.
</Note>

## How it works

GRE is a tunneling protocol that wraps your network packets inside a new IP packet, creating a virtual point-to-point link between your server and our scrubbing network. All inbound traffic to your protected IPs passes through the scrubber before being forwarded over the tunnel to your server.

```text theme={null}
Internet -> DDOS Protection -> GRE tunnel (IPv6) -> Your server 
Outgoing Connections can be tunneld back to us or sended via static route to your Upstream
```

<Info>
  The tunnel endpoint on the Packets Decreaser side is an IPv4 address. Your server needs outbound IPv4 connectivity to establish the tunnel.
</Info>

## Limits

| Parameter         | Value               |
| ----------------- | ------------------- |
| Maximum bandwidth | 40 Gbits or 59 Mpps |
| Tunnel type       | GRE over IPv4       |
| Setup method      | Hardware            |
| Server location   | Any                 |


# BGP vServer
Source: https://docs.packets-decreaser.net/kvm-vserver/bgp-vps



## Overview

Our BGP vServer plans allow you to announce your own IPv4 and IPv6 prefixes via BGP (Border Gateway Protocol) directly from your virtual instance. This provides full control over your network identity and enables advanced traffic engineering.

## IP Space and Requirements

To utilize the BGP service, you must provide your own IP space.

## BGP Session Details

To establish the BGP session between your instance and our edge routers, we provide the following dedicated peering IPs:

| Direction    | IPv4 Address  | IPv6 Address                   |
| ------------ | ------------- | ------------------------------ |
| **Router 1** | `77.90.4.247` | `2a0e:97c0:4c1:beef:affe::247` |
| **Router 2** | `77.90.4.246` | `2a0e:97c0:4c1:beef:affe::246` |

## Provisioning Process

As the BGP vServer requires manual verification and integration into our core routing infrastructure, the deployment is not instant.

<Note>
  Please expect a setup time of **1 to 3 business days**.
</Note>

The provisioning process follows these steps:

<Steps>
  <Step title="Order Submission">
    Complete your order through the client area. During checkout, you must provide the IP prefixes you intend to announce and your ASN (Autonomous System Number).
  </Step>

  <Step title="Manual Verification">
    Our engineering team manually validates your IP space and provided information. As a mandatory security measure, we verify the authorization to announce the specified prefixes by contacting the registered owner of the ASN via official channels.
  </Step>

  <Step title="Export Policy Requirement">
    Please ensure that an appropriate export policy is set up within your ASN configuration. Failing to create this policy will prevent the successful announcement of your network.
  </Step>

  <Step title="BGP Node Configuration">
    Once verified, we configure our border routers to permit your specific IP prefixes. We then whitelist your VM's dedicated management IP on our BGP nodes to establish the BGP session.
  </Step>

  <Step title="Session Activation">
    You will receive a notification once the session is live. You can then configure your BGP daemon (e.g., Bird, FRR) within your instance to begin the announcement.
  </Step>
</Steps>


# KVM vServer
Source: https://docs.packets-decreaser.net/kvm-vserver/overview

kl

## Default network restrictions

To protect the platform from spam and abuse, we blocks several outbound SMTP source ports on all KVM vServer plans by default.

<Warning>
  Attempting to send email through these ports will fail until you request access. If your application depends on email delivery, make sure to request the ports you need before going live.
</Warning>

The following source ports are blocked by default on all KVM vServer instances:

| Port | Protocol | Service           |
| ---- | -------- | ----------------- |
| 25   | TCP      | SMTP              |
| 465  | TCP      | SMTP (SSL)        |
| 587  | TCP      | SMTP (submission) |
| 2525 | TCP      | SMTP (alternate)  |

## Requesting port access

You can request any of the blocked SMTP ports to be unlocked on your account.

<Steps>
  <Step title="Open a support ticket">
    Log in to the Packets Decreaser client area and open a new support ticket. Specify which port or ports you need unblocked and provide a brief description of your intended use case (for example, sending transactional email through a third-party SMTP relay).
  </Step>

  <Step title="Wait for review">
    The support team will review your request. Port unlock requests are typically processed within one business day.
  </Step>

  <Step title="Confirm access">
    Once approved, test your connection to confirm the port is reachable from your vServer.
  </Step>
</Steps>

<Note>
  Port unlock requests are evaluated on a case-by-case basis. Providing clear context about your use case speeds up the review process.
</Note>


# Remote DDoS Protection via GRE Tunnel
Source: https://docs.packets-decreaser.net/remote-ddos-protection/gre-tunnel

Use a GRE tunnel over IPv6 to route any server's traffic through Packets Decreaser scrubbing, wherever the server is hosted. Supports up to 10 Gbits.

Remote DDoS protection via GRE (Generic Routing Encapsulation) lets you place any server, regardless of its physical location or hosting provider, behind our scrubbing infrastructure. Packets Decreaser sets up a GRE tunnel using an IPv6 address and routes your protected IPs to that endpoint entirely in software.

<Note>
  Software GRE tunnels support a maximum throughput of **10 Gbits or 500kpps**. If your traffic volume exceeds this, contact support to discuss alternatives.
</Note>

## How it works

GRE is a tunneling protocol that wraps your network packets inside a new IP packet, creating a virtual point-to-point link between your server and our scrubbing network. All inbound traffic to your protected IPs passes through the scrubber before being forwarded over the tunnel to your server.

```text theme={null}
Internet -> DDOS Protection -> GRE tunnel (IPv6) -> Your server 
Your server -> GRE tunnel (IPv6) -> DDOS Protection -> Internet
```

<Info>
  The tunnel endpoint on the Packets Decreaser side is an IPv6 address. Your server needs outbound IPv6 connectivity to establish the tunnel.
</Info>

## Limits

| Parameter         | Value                           |
| ----------------- | ------------------------------- |
| Maximum bandwidth | 10 Gbits or 500kpps             |
| Tunnel type       | GRE over IPv6                   |
| Setup method      | Software (no hardware required) |
| Server location   | Any                             |

## Get started

<Steps>
  <Step title="Rent our Software GRE Tunnel (Link)">
    Log in to your customer portal and open a support ticket requesting GRE tunnel setup. Include the IP addresses you want to protect and the public IPv6 address of your server.
  </Step>

  <Step title="Setup the Tunnel via our Interface on both sides">
    Set up the GRE tunnel via our Interface and on your server using the provided endpoint address. The exact commands are provided in the interface. \
    Support can assist if needed.
  </Step>

  <Step title="Trying the Connection">
    You should be able to login via the IP to SSH. 
  </Step>
</Steps>


# Game filters
Source: https://docs.packets-decreaser.net/untitled-page



DDoS filters are active by default on all protected IPs. Each filter only permits traffic that matches the expected protocol signature for that application or game, blocking everything else on the covered port range. No configuration is required to benefit from these filters.

## Active application filters

<AccordionGroup>
  <Accordion title="Minecraft Java Edition" icon="cube">
    **Protocol:** TCP

    **Default ports:** 25565–26000

    Filters specialized for Minecraft Java Edition protocol handshakes, query traffic, and player session packets.
  </Accordion>

  <Accordion title="Minecraft Bedrock Edition" icon="cube">
    **Protocol:** UDP

    **Default ports:** 19100–19200

    Filters specialized for Minecraft Bedrock Edition protocol handshakes and RakNet traffic.
  </Accordion>

  <Accordion title="VALVE Source Engine" icon="gamepad">
    **Protocol:** UDP

    **Default ports:** 27000–28000

    Protects game traffic and A2S query packets for Source engine titles (e.g., CS:GO/CS2, TF2, Garry's Mod, Left 4 Dead).
  </Accordion>

  <Accordion title="Rust" icon="helicopter">
    **Protocol:** UDP

    **Default ports:** 28015–28100

    Protects Rust network payloads and player connection states.

    <Tip>
      For Rust servers, ensure your query ports are configured within the VALVE Source Engine Query range (27000–28000).
    </Tip>
  </Accordion>

  <Accordion title="FiveM" icon="car">
    **Protocol:** TCP & UDP

    **Default ports:** 30000–32000

    Permits authenticated FiveM client traffic and server payload data across both TCP and UDP.
  </Accordion>

  <Accordion title="Palworld" icon="ghost">
    **Protocol:** UDP

    **Default ports:** 8200–8300

    Filters specific UDP game state traffic and session handshakes for Palworld multiplayer servers.
  </Accordion>

  <Accordion title="Factorio" icon="gear">
    **Protocol:** UDP

    **Default ports:** 34100–34200

    Filters UDP game state synchronization packets for Factorio multiplayer sessions.
  </Accordion>

  <Accordion title="SCP: Secret Laboratory" icon="flask">
    **Protocol:** UDP

    **Default ports:** 7100–7200

    Protects direct player traffic and game state synchronization for SCP:SL servers.
  </Accordion>

  <Accordion title="BeamMP" icon="truck-fast">
    **Protocol:** UDP

    **Default port:** 40140

    Filters multiplayer physics synchronization and server connection data for BeamMP.
  </Accordion>

  <Accordion title="Hytale / QUIC" icon="bolt">
    **Protocol:** UDP

    **Default ports:** 5520–5620

    Dedicated filter for QUIC-based game connections and Hytale server traffic.
  </Accordion>
</AccordionGroup>

## Summary table

| Application / Game         | Protocol  | Default ports | Notes                                  |
| -------------------------- | --------- | ------------- | -------------------------------------- |
| **Minecraft Java**         | TCP       | 25565–26000   | Java Edition traffic                   |
| **Minecraft Bedrock**      | UDP       | 19100–19200   | Bedrock Edition traffic                |
| **VALVE Source Engine**    | UDP       | 27000–28000   | Covers Source engine games & queries   |
| **Rust**                   | UDP       | 28015–28100   | Query ports must be within 27000–28000 |
| **FiveM**                  | TCP / UDP | 30000–32000   | TCP and UDP ranges                     |
| **Palworld**               | UDP       | 8200–8300     | Game traffic protection                |
| **Factorio**               | UDP       | 34100–34200   | Game state synchronization             |
| **SCP: Secret Laboratory** | UDP       | 7100–7200     | Dedicated server protection            |
| **BeamMP**                 | UDP       | 40140         | Multiplayer physics sync               |
| **Hytale / QUIC**          | UDP       | 5520–5620     | QUIC protocol support                  |