CloudFlare Access and CloudFlare Tunnel Exploring

Exploring what could be an interesting, self hosting solution from CloudFlare

An interesting challenge to me anyway with self hosting, is the exposure of services to the outside world. Ultimately whether you’re running this in your house or on a server on the internet, you’re going to be faced with challenges. At home, you very well could be behind a carrier grade NAT from your ISP that will present a challenge to you getting services exposed correctly. Or, when running a server on the interwebs, you probably have more headaches around firewalls and what ports services run under. My normal workflow is to just whitelist my home IP address or my current address if behind a VPN (see this script that I used for a while with EC2) and go from there.

Depending on the firewall that could be tricky. EC2 was relatively fine, as per my script. If you’re relying on UFW, you might have a bit of a challenge if you need to whitelist a new IP without existing access, unless you’ve IPMI or some equivalent set up. OVH have a firewall service for their bare metal servers, which right now just feels incredibly clunky for a stateful firewall. So, I was interested in solutions that would allow me to securely access my self hosted services without jumping through a lot of hoops in the form of firewall updates so I could access them when traveling for example (a use case that only recently regained value since being vaccinated, hah!).

I was already using CloudFlare for my websites, but they recently made Argo Tunnels free to all while also renaming the product to CloudFlare Tunnel. What it does is basically creates an outbound only tunnel to CloudFlare, while generating a CNAME record for your Tunnel. You create a DNS entry on CloudFlare, then all you do is hit that and away you go, you can access your service! CloudFlare by design is a reverse proxy of sorts, so you can run your local services on random high number ports you pick, then CloudFlare fronts all that on 443. Now you can rely on your applications authentication services to decide who enters your app, or you can take it a step further with CloudFlare Access.

Access is one of several services underneath the CloudFlare for Teams umbrella that are designed to support a ‘Zero Trust’ model. Zero Trust has been around for a few years and I’ll be honest, I’m not an expert. But the crux in my mind is that in the old days, you had this model (much like the one I described) where you have devices and networks that trust each other via firewall entries. That’s all well and good till a device is compromised and that trust can be exploited. Where Zero Trust comes in, is that no device trusts anything, but instead you can rely on a system of Identity and Access Management (IAM) to say “hey, is this person even authorised to access that system?” If they are, then you rely on software such as proxies to make the connection and the person can go about their business. This is where Access comes in and paired with Tunnel, lead to this very nice configuration. At a high level, Access would front my Tunnel DNS entries and anyone trying to access the system, had to login. You can configure a range of IDPs or rely on one time passcodes, but if they authenticate and are authorised for that particular application, hey presto, you’re in!

From that, you’re probably thinking “wow this sounds like a perfect solution for you” and it did! Until, I started trying to implement it and boy oh boy did I experience pain. My next post will talk about my experiences with this, at a high level I feel that the products were not ready to be pushed by a load, even though what I was doing is comparatively tiny to say some of CloudFlare’s enterprise customers. But, it was an experience that overall has lead me towards moving away from CloudFlare, so expect a little series on CloudFlare over the next few posts and my plans for what to do next.