Whitelist IP

    Hi,

    We manage our own load balancer where we passthrough HTTP and HTTPs web requests to our dedicated server with Netcup. But we keep on facing an issue where our IPs from our load balancer get ratelimited on Netcup's side temporarily, for like 10 minutes or so, and works again. In this time, our load balancer stops working and we can't forward requests to our servers.

    We already have our SCP firewall open for all requests, and already whitelisted the IP's in our local firewall.

    We've already opened a support ticket but I thought I might ask here if someone has had the same issue and how they fixed it.

    This sounds like the netcup server protection against DDoS attacks and a support ticket might be the best option to get your load balancers "white-listed" if that is possible within the protection solution used by netcup. DDoS Protection – Secure Infrastructure & Uptime | netcup

    There might be other forum users or server operators that have more feedback and already experienced this behavior and give better guidance.

    Having the firewall on the servers and also the netcup side / SCP firewall reflect those incoming load balancer requests is also a good idea, but does not affect the DDoD protection that might look like ratelimiting as well.

    WH1000 SE OST22 OST23 OST24 | WH1000 SE ADV25 | WH 🥚🧶🥛🐖 | 🦆 VPS 200 🇺🇦🕊️ ➡️ VPS nano G11s

    Zitat von abdxl

    I sent a support ticket but it's been more than 48h with no response :/

    Support tickets might take several days to resolve at the moment because the support is probably overloaded and the phone hotline is currently unavailable as well. Sadly this might be the only quick solution to your problem and since the hotline option is not available you have to wait this one out.

    The other AI generated answers or suggestions 2-4 are also a good read and provide new ideas specifically if netcup is not able to exempt your server from this DDoS protection rate limiter configuration which is suggestion 1 and already in progress:
    ----

    This rate-limiting issue is caused by netcup's automated DDoS protection mitigation triggering a false positive. Because your load balancer passes through all HTTP/HTTPS traffic, netcup’s network edge only sees a massive spike of requests coming from a single IP address (your load balancer), which looks exactly like a Layer 7 DDoS attack.

    Since your local firewalls and Server Control Panel (SCP) rules are already completely open, the block is happening at the provider/carrier routing level, completely bypassing your individual OS settings.

    Apply the following architectural changes and administrative actions to fix this issue:

    1. Contact Netcup Support for Provider-Level Whitelisting

    Because the blocking happens on netcup's edge infrastructure, only netcup Support can fully resolve this by adjusting their automated DDoS thresholds for your specific target IP.

    • Open a critical infrastructure ticket with netcup
    • Explicitly state that you are running a dedicated load balancer architecture where upstream traffic is proxied through specific, fixed IPs.
    • Provide them with the exact IPv4 and IPv6 addresses of your load balancers, along with the target dedicated server IDs.
    • Request that these source IPs be whitelisted or excluded from automated L7/DDoS rate-limiting mitigation filters.

    2. Switch from L4 Passthrough to L7 Reverse Proxy

    If your load balancer is currently operating as a Layer 4 TCP passthrough, it masks the real client IPs, forcing Netcup's edge to blame your load balancer for all traffic anomalies. Convert your load balancer into a Layer 7 Reverse Proxy:

    • Preserve real IPs: Configure your load balancer (e.g., NGINX, HAProxy) to inject the real user IPs into the request headers via X-Forwarded-For and X-Real-IP.
    • Enable Proxy Protocol: Alternatively, enable Proxy Protocol (v1 or v2) on both your load balancer and your Netcup backend servers. This allows TCP-level forwarding while cleanly carrying client connection information over to netcup.

    3. Distribute the Load Using Multiple Egress IPs

    If netcup's network detects too many requests or concurrent TCP states from a single IP, distribute your load balancer's outgoing traffic across multiple IP addresses:

    • Assign an IP block/alias to your load balancing cluster.
    • Configure your proxy software to cycle through an outgoing pool of source IPs when connecting to the netcup backend (e.g., in NGINX, using the proxy_bind directive with a split or load-balanced pool). This keeps individual IP request frequencies below netcup’s automated threshold.

    4. Implement Strict Upstream Rate Limiting

    To completely prevent triggering upstream infrastructure blocks, you must enforce rate limiting at your load balancer level before the traffic ever reaches netcup's network boundaries:

    • Limit the maximum number of requests and concurrent connections per unique client IP at your load balancer.
    • Drop or block malicious bots, scraping tools, and aggressive clients at your edge so that netcup only receives clean, smoothed-out web traffic.

    To help tailor these steps, could you clarify: :?:

    • What load balancer software (e.g., HAProxy, NGINX) are you using?
    • Are you passing traffic through via Layer 4 (TCP) or Layer 7 (HTTP Proxy)?
    • Approximately how many requests per second (RPS) does your load balancer forward during peak hours?