Why Port Forwarding is Risky and How Cloudflare Tunnels Keep Your Homelab Secure

In the last blog post, we explored how to use GitOps in a Kubernetes cluster and deployed Linkding, a self-hosted bookmark manager. Deploying self-hosted applications brings a unique sense of accomplishment. You’re running a service that’s fully yours, tailored to your needs. But once you’ve got these apps up and running, a critical question arises:

How do you access them?

If you’re sitting at your desk, tools like kubectl port-forward work great. They map the service port to your local machine, letting you access your app through something like localhost:<app-port>. But what about when you’re not at home? What if you need to use your apps on the go?

This blog post dives into that exact dilemma: how to securely expose your Kubernetes applications internally and externally using DNS records. Before we dive into solutions, though, let’s look at why one common approach—using your ISP’s public IP—poses more problems than it solves.

The Risks of Using Your Public IP

If you’ve ever Googled "What’s my IP?" or used a tool like IpChicken, you’ve seen your public-facing IP address. This is the unique identifier assigned to your home network by your ISP. Theoretically, you could forward a few ports on your router and use that public IP to access your apps remotely.

Sounds simple, right? But in practice, this approach is a security and maintenance nightmare. Here’s why:

1. A Bigger Attack Surface

When you expose your public IP, you’re effectively advertising your home network to the entire internet. Any open port becomes a potential entry point for attackers.

• Unauthorized Access: Without airtight security, malicious actors can probe your open ports and try to break into your services.
• DDoS Vulnerabilities: Once your public IP is out there, it can become a target for Distributed Denial of Service (DDoS) attacks, which can cripple your network.
• Exploitation of Known Vulnerabilities: Even well-maintained applications can have vulnerabilities. Exposing them directly to the internet increases the risk of someone exploiting these weaknesses.

2. Dynamic IP Challenges

Most ISPs assign dynamic public IPs, which means your address can change over time. Keeping your DNS records updated to reflect these changes requires either manual intervention or a Dynamic DNS (DDNS) service. Even with DDNS, the setup adds complexity to your infrastructure.

3. Human Errors and Misconfigurations

It’s easy to make mistakes when setting up port forwarding or configuring services. These errors can leave sensitive systems exposed. Here’s an example from my own experience:

A few years ago, I wanted to host a Minecraft server for my friends. I set up port forwarding on my router to expose the game’s server. It worked flawlessly… until it didn’t. During testing, I accidentally forwarded the Docker API port to the internet as well.

One day, the server started lagging terribly. When I SSH’d into the machine to investigate, I found that someone had exploited the exposed API to spin up cryptocurrency-mining containers on my server. It was a painful lesson in the importance of reducing your attack surface.

4. Infrastructure Overhead

To securely expose services via your public IP, you’ll need more than just port forwarding. A proper setup requires:

• A reverse proxy like NGINX or Traefik to route and secure traffic.
• A firewall to restrict unauthorized access.
• Potentially a VPN gateway to segment public and private traffic.

These add complexity, cost, and ongoing maintenance to your homelab, making it harder to achieve the simplicity and reliability you’re aiming for.

My Homelab Topology

To better understand the alternatives I recommend, let’s take a quick look at my homelab setup:

• ISP Router: This is the entry point to my network. It gets assigned a dynamic public IP by my ISP.
• Network Switch: Since the ISP router has limited ports, I use a switch to expand connectivity for my servers and devices.
• Servers: These run my Kubernetes cluster, hosting applications like FluxCD and self-hosted tools like Linkding.

Here’s a visual representation of this setup:

This simple yet scalable topology works well for hosting applications internally. But as I mentioned earlier, exposing services to the internet requires careful consideration to avoid security pitfalls.

Why You Should Consider Safer Alternatives

So, if using your public IP is so risky, what’s the alternative? The goal is to securely expose your services while minimizing your attack surface. One approach that works exceptionally well in homelab environments is using solutions like Cloudflare Tunnels.

Cloudflare Tunnels to the Rescue

Cloudflare Tunnels provide a secure way to expose your applications without requiring a publicly routable IP address. Instead of opening inbound ports on your router, Cloudflare Tunnels establish an outbound-only connection from your infrastructure to Cloudflare’s global network.

This approach dramatically reduces your exposure to external threats. Even if an attacker discovers your domain, they still need to bypass Cloudflare’s security measures before reaching your infrastructure—something far more difficult than exploiting an open port on a home router.

Here’s how it works, according to Cloudflare’s documentation:

Key Benefits of Cloudflare Tunnels

• No Public IP Exposure → Your home IP remains completely hidden from the public internet.
• Automatic Encryption → All traffic is encrypted between your homelab and Cloudflare’s edge network.
• Integrated Authentication → Cloudflare Access can require OAuth, SSO, or multi-factor authentication before granting access.
• Resilient and Scalable → Unlike port forwarding, which relies on a single router, Cloudflare Tunnels leverage Cloudflare’s global infrastructure for load balancing and redundancy.

With tools like Cloudflare Tunnels, you no longer have to worry about DDNS, securing open ports, or attackers scanning your network. You’re getting enterprise-grade security for a homelab setup, without the headaches.

A Personal Takeaway

The journey of building a homelab is as much about learning from mistakes as it is about celebrating wins. My Minecraft server mishap taught me an important lesson: even a small oversight can have outsized consequences when dealing with public IPs. It’s why I’ve become such an advocate for reducing attack surfaces and using more secure alternatives like Cloudflare Tunnels.

If you’re setting up your own homelab, take the time to think about how you expose your services. The effort you put into securing your setup today can save you from a lot of headaches down the road.