Cloudflare Configuration Check
Network Architecture & Data Flow
Data flow:
Internet -> Cloudflare LB -> Public IP of Bare Metal Node(s) -> K3s Ingress Controller
On the Public Network Interface (eth0, eno1, etc.)
This interface faces the internet. The goal is to only allow traffic from Cloudflare and your own IP for management.
| Port | Protocol | Source IP | Purpose |
|---|---|---|---|
| 80 | TCP | Cloudflare IPs¹ | HTTP traffic for your applications (Ingress). |
| 443 | TCP | Cloudflare IPs¹ | HTTPS traffic for your applications (Ingress). |
| 22 | TCP | Your Office/Home IP | Secure Shell (SSH) for server administration. |
¹ Security Best Practice: Only allow traffic from Cloudflare's official IP ranges. Allowing Any source on ports 80/443 would work but allows attackers to bypass Cloudflare and hit your server directly.
On the Private vRack Interface (eth1, eno2, etc.)
This interface is for secure, internal cluster communication. The rule is simple: allow all traffic from other nodes within your private subnet.
| Port | Protocol | Source IP Range | Purpose |
|---|---|---|---|
| All | TCP/UDP | Your vRack Subnet | All internal cluster communication. |
(e.g., 1-65535) | (e.g., 192.168.1.0/24) | K3s API, container networking (Flannel/VXLAN), etc. |
Allowing all traffic from your trusted private subnet is standard practice and much simpler than managing individual K3s ports (6443, 10250, 8472, etc.).
Direct Origin Server Access Issue
It is possible to directly access the origin servers by bypassing Cloudflare. This is a problematic security misconfiguration, as it exposes the infrastructure to direct attacks and circumvents Cloudflare's protection (WAF, DDoS mitigation) and caching layers.
Verifying Origin Access
We can verify this vulnerability by explicitly curling the origin server IP (51.222.105.111) while providing the expected Host header.
For instance, hitting the Argo CD endpoint directly works:
curl -k -H "Host: argocd.kube360.io" https://51.222.105.111
Output:
<!doctype html><html lang="en"><head><meta charset="UTF-8"><title>Argo CD</title><base href="/"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" type="image/png" href="assets/favicon/favicon-32x32.png" sizes="32x32"/><link rel="icon" type="image/png" href="assets/favicon/favicon-16x16.png" sizes="16x16"/><link href="assets/fonts.css" rel="stylesheet"><script defer="defer" src="main.b09d1843a052f9c6c3d3.js"></script></head><body><noscript><p>Your browser does not support JavaScript. Please enable JavaScript to view the site. Alternatively, Argo CD can be used with the <a href="https://argoproj.github.io/argo-cd/cli_installation/">Argo CD CLI</a>.</p></noscript><div id="app"></div></body><script defer="defer" src="extensions.js"></script></html>
(The server successfully returns the Argo CD HTML application)
However, testing against other endpoints like httpbin behaves differently:
curl -k -H "Host: httpbin.kube360.io" https://51.222.105.111
Output:
Misdirected Request
We can confirm the specific HTTP status code for this "Misdirected Request":
curl -w "%{http_code}\n" -s -o /dev/null -k -H "Host: httpbin.kube360.io" https://51.222.105.111
Output:
421
SSL/TLS Encryption Modes
"Full (Strict)" Mode Requirement
For the site to function correctly through Cloudflare, the SSL/TLS encryption mode must be set to Full (strict).
When it is misconfigured or set to a lower security level, Cloudflare may fail to properly negotiate a secure connection with the origin, resulting in a 520 error:
curl https://httpbin.kube360.io
Output:
error code: 520
Note: Once the encryption mode in Cloudflare is changed to "Full (strict)", the endpoint correctly serves traffic.