How to Set Up Cloudflare on Netcup (Full Strict SSL, Real Visitor IPs & Origin Firewall Lock)

If your domain is registered through Netcup (including .de or .eu domains managed inside your customer account), log in to the Customer Control Panel (customercontrolpanel.de) → Domains → Select Domain → Name Server, choose Own name servers, and enter the two Cloudflare nameservers assigned to your zone (for example, ada.ns.cloudflare.com and bob.ns.cloudflare.com). Because Netcup’s AS197540 core routers maintain direct high-capacity settlement-free peering with Cloudflare at DE-CIX Frankfurt and VIX Vienna, sub-2 ms round-trip latency between Cloudflare’s German/Austrian edge PoPs and your Netcup KVM node ensures minimal proxy overhead on cache misses.

Pay strict attention to the DNSSEC chain of trust before modifying authoritative nameservers. If DNSSEC was previously enabled on Netcup’s default nameservers (root-dns.netcup.net / second-dns.netcup.net / third-dns.netcup.net), you must disable DNSSEC in CCP before switching nameservers and wait 15 to 30 minutes for the parent registry (such as DENIC for .de or Verisign for .com) to purge the old DS record. Switching nameservers while a stale DS record remains published at the TLD registry causes validating DNS resolvers (1.1.1.1, 8.8.8.8, ISP resolvers) to return SERVFAIL for every query to your domain.

Once Cloudflare confirms your zone is active, re-enable DNSSEC inside the Cloudflare dashboard (DNS → Settings → Enable DNSSEC) and copy the newly generated Key Tag, Algorithm (13 for ECDSAP256SHA256), Digest Type (2 for SHA-256), and Digest back into the Netcup CCP DNSSEC panel. When creating your origin records in Cloudflare, always provision both an IPv4 A record (203.0.113.10) and an IPv6 AAAA record (2a03:4000:xx:xx::1). Cloudflare’s edge acts as a transparent dual-stack protocol translator: an IPv6-only mobile visitor can connect to Cloudflare over IPv6 while Cloudflare fetches from your origin over IPv4 or IPv6, and vice versa.

Keep non-HTTP protocols isolated from proxied hostnames. Cloudflare’s standard Reverse Proxy ("Orange Cloud") only forwards HTTP and HTTPS traffic on standard web ports (80, 443, 2053, 2083, 2087, 2096, 8443). If you leave your primary apex domain @ proxied and attempt to run ssh [email protected] or connect a PostgreSQL/SMTP client to example.com, the connection will time out at Cloudflare’s edge. Always connect to SSH via a dedicated unproxied ("Grey Cloud" / DNS-only) subdomain such as ssh.example.com or directly via your server’s static IPv4/IPv6 address:

• ▪ IPv4 Record: Type A, Name @ (and www), Content 203.0.113.10 (your Netcup IPv4 /32 address), Proxy status: Proxied.
• ▪ IPv6 Record: Type AAAA, Name @ (and www), Content 2a03:4000:xx:xx::1 (your primary Netcup IPv6 address from your /64 block), Proxy status: Proxied.
• ▪ SSH Subdomain Bypass: If you connect to SSH via a hostname, either connect directly to your raw IPv4/IPv6 address or create a separate ssh.example.com record set to DNS Only (Grey Cloud), as Cloudflare’s standard HTTP proxy only forwards HTTP/HTTPS ports.

In the Cloudflare dashboard under SSL/TLS → Overview, set your encryption mode to Full (Strict). Never leave a zone on Flexible SSL: under Flexible mode, Cloudflare terminates HTTPS from the visitor’s browser at the edge PoP and opens a plaintext HTTP connection on port 80 across the public internet to your Netcup server. Aside from exposing session cookies, API bearer tokens, and passwords in cleartext over transit links, Flexible mode sends X-Forwarded-Proto: http to your origin—causing Nginx or WordPress (FORCE_SSL_ADMIN) to issue an unending 301 Moved Permanently redirect loop (ERR_TOO_MANY_REDIRECTS).

Under Full (Strict) mode, Cloudflare validates that the TLS certificate presented by your Netcup Nginx server on port 443 is signed by a trusted public Certificate Authority (such as Let’s Encrypt) or by Cloudflare’s Origin CA, has not expired, and matches the requested hostname in its Subject Alternative Name (SAN) extension. If your server strictly receives web traffic through Cloudflare, generating a 15-Year Cloudflare Origin CA Certificate under SSL/TLS → Origin Server → Create Certificate eliminates the need for 90-day ACME renewal cron jobs while supporting wildcard SANs (*.example.com, example.com).

However, DNS records and Certificate Transparency (CT) logs are public. Tools like Censys and Shodan continuously scan the entire IPv4 space (0.0.0.0/0), inspect TLS server certificates on port 443, and map domain names back to their underlying origin IPs—even if your domain has been behind Cloudflare from day one. Once an attacker discovers your Netcup IPv4 address, they can forge a direct curl --resolve example.com:443:203.0.113.10 https://example.com request, completely bypassing Cloudflare’s WAF, Bot Management, and DDoS rate limiting.

To cryptographically close this loophole, enable Authenticated Origin Pulls (mutual TLS / mTLS) in Nginx alongside your firewall rules. When you configure ssl_client_certificate with Cloudflare’s Authenticated Origin Pull Root CA (authenticated_origin_pull_ca.pem) and set ssl_verify_client on;, Nginx requires the connecting client during the TLS 1.3 handshake to present a valid client certificate signed by Cloudflare’s internal edge key. Any scanner or attacker hitting your Netcup IP directly fails the TLS client-certificate verification check and is terminated before a single HTTP header is parsed. For production deployments, combine mTLS with Cloudflare Smart Tiered Cache (Caching → Tiered Cache) so only upper-tier Cloudflare PoPs near Frankfurt (FRA) and Vienna (VIE) pull from your Netcup origin:

# Download Cloudflare's official Authenticated Origin Pull Root CA certificate
sudo mkdir -p /etc/nginx/certs
sudo curl -fsSL https://developers.cloudflare.com/ssl/static/authenticated_origin_pull_ca.pem \
  -o /etc/nginx/certs/cloudflare-origin-pull-ca.pem

# Inside your /etc/nginx/sites-available/example.com.conf server { listen 443 ssl; ... } block, add:
# ssl_client_certificate /etc/nginx/certs/cloudflare-origin-pull-ca.pem;
# ssl_verify_client on;

sudo nginx -t && sudo systemctl reload nginx

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Because Cloudflare acts as a reverse proxy at the TCP layer, every packet arriving at your Netcup server’s eth0 interface carries a Cloudflare edge node IP (172.64.0.0/13, 104.16.0.0/12, 2606:4700::/32) as its Layer-3 source address. In a default Nginx installation, the internal $remote_addr variable is populated directly from the TCP socket peer address. Without explicitly configuring ngx_http_realip_module, your /var/log/nginx/access.log files will attribute every request to Cloudflare’s Frankfurt or Vienna PoP IPs rather than the actual end user.

This creates a dangerous operational failure mode when paired with host-level rate limiting (limit_req_zone $binary_remote_addr) or Fail2ban log filters. If a single malicious bot triggers your login rate limit or Fail2ban jail while $remote_addr still resolves to a Cloudflare edge IP, Nginx or UFW will block that Cloudflare PoP IP—instantly blackholing thousands of legitimate visitors routed through the same Cloudflare datacenter.

Never solve this by reading HTTP_CF_CONNECTING_IP or HTTP_X_FORWARDED_FOR directly in PHP/Node.js without network-layer validation. HTTP request headers are trivial for an attacker to forge (curl -H "CF-Connecting-IP: 127.0.0.1"). Instead, use Nginx’s compiled-in ngx_http_realip_module: by listing Cloudflare’s official IPv4 and IPv6 CIDR ranges via set_real_ip_from directives and setting real_ip_header CF-Connecting-IP;, Nginx will only overwrite $remote_addr and $binary_remote_addr when the underlying TCP connection genuinely originated from a trusted Cloudflare edge subnet.

Adding real_ip_recursive on; ensures that if a request passes through multiple trusted proxy hops (for instance, Cloudflare edge → your host Nginx proxy → an internal Docker container), Nginx strips trusted proxy addresses right-to-left until it isolates the first untrusted client IP. Create the automated script below to fetch Cloudflare’s official IPv4 and IPv6 CIDR lists, validate them atomically in a temporary file, and generate /etc/nginx/conf.d/cloudflare-realip.conf:

cat << 'EOF' | sudo tee /usr/local/sbin/update-cloudflare-realip.sh
#!/usr/bin/env bash
set -euo pipefail

CONF_FILE="/etc/nginx/conf.d/cloudflare-realip.conf"
TMP_FILE="$(mktemp)"

echo "# Auto-generated Cloudflare RealIP configuration ($(date -u +%Y-%m-%dT%H:%M:%SZ))" > "${TMP_FILE}"

for ip in $(curl -fsSL https://www.cloudflare.com/ips-v4); do
  echo "set_real_ip_from ${ip};" >> "${TMP_FILE}"
done

for ip6 in $(curl -fsSL https://www.cloudflare.com/ips-v6); do
  echo "set_real_ip_from ${ip6};" >> "${TMP_FILE}"
done

echo "real_ip_header CF-Connecting-IP;" >> "${TMP_FILE}"
echo "real_ip_recursive on;" >> "${TMP_FILE}"

mv "${TMP_FILE}" "${CONF_FILE}"
chmod 0644 "${CONF_FILE}"
nginx -t && systemctl reload nginx
EOF

sudo chmod +x /usr/local/sbin/update-cloudflare-realip.sh
sudo /usr/local/sbin/update-cloudflare-realip.sh

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful