Cloudflare Teams provides an excellent alternative for VPN protections where you want to provide remote, work from home or even inside the office staff with controlled access to protected web apps, SASS platforms and even SSH.
The very generous free tier includes 50 users with basic logging functionality. You can pay extra for upgraded features such as longer log retention if those are worth it for you.
In this walk through, we’re going to hook it up with Google Workspace – (formerly Suite – (formerly Apps)) for single sign on
If you would like help getting your infrastructure protected by Cloudflare Teams – get in touch today!
- Already have a Cloudflare account
- You need to be using Google Workspace (Suite/Apps) if you want to use this for single sign on (SSO)
- Only one level subdomains are supported (easily)
See official docs before you get started section.
Allow Google Workspace to Connect
Sign into Google workspace console and adjust security settings:
In the Google Admin console, navigate to Security > API controls.
Check the Trust internal, domain-owned apps option.
Open up Port 7844 on Any Firewalls
If your servers are running firewalls and/or behind firewalls, then you need to make sure that port 7844 is open for outbound connections
Configure SSL in Cloudflare
You need to ensure SSL is set to “full” – you can try “full strict” but you might hit issues
Within Cloudflare teams, you can create “groups” which are then able to be assigned permissions.
To start with, its suggested that you make a general group for everyone with an email address at the Google workplace domain, so you will “require” emails ending in
Google Workplace Authentication
We want to allow users to authenticate using Google Workplace logins. Strongly suggest Google Workplace has 2FA required for all users.
Go to Settings->Authentication, scroll down to Login Methods and click Add New, then select Google Workplace.
You are required to configure a new app within Google Cloud Console. The process is well documented here
You need to generate an App ID and Client Secret. Your Google Workspace domain is simply the domain that you use for Google workplace emails, eg
Suggestion – Remove One Time Pin
Once you have enabled Google Workplace authentication, you should remove the One Time Pin login method – simply click Edit and then press the Delete button.
Creating Application Config
You need to add an application that will be protected. You can protect both self hosted and some SAAS apps. For this guide we will focus on self hosted apps.
When creating the app, you should create a single policy to allow
@mydomain.co.uk users by using the “Assign a group” functionality and choosing the group you previously created.
See official docs on self hosted applications
Applications you create should default to using the Google Workplace authentication you previously created.
Installing Tunnel on Server
This depends on your particular server. Suggest you hit the official docs page on installing on Linux if you intend to do this by hand.
First you need to install the binary. There are apt and rpm packages available. In Ansible you might do something like:
tasks: - name: Install Binary yum: name: https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-x86_64.rpm
See official docs
Next you need to authenticate with Cloudflare, which is a step that needs you to have access to a logged in browser session on Cloudflare. You can run this step manually on the server or you could choose to do this step on a local machine and simply capture the created file so that you can push this to servers.
cloudflared tunnel login
This command will generate a URL which you can follow to authorise the request and once authorised it will create a cert file in
See official docs
Again this is a step you can run manually on the server, or you can run locally and capture the generated files in order to deploy to a production server.
cloudflared tunnel create TUNNEL_NAME
This will create the tunnel and will also create a file in your
The name of the file is the UUID of the tunnel and with a
Connecting Tunnel to Self Hosted Application
The tunnel running on the server does nothing until we configure cloudflared to actually use that tunnel to connect it to a specific application or entire network. For this guide, we’re focussing on connecting a specific application.
Create Config File
You need to create a
config.yml file in your
The file should reference the tunnel UUID you previously created, and look something like this:
tunnel: (uuid) credentials-file: /root/.cloudflared/(uuid).json
Note, we will update this config file further once we are configuring our application.
Now you can test run the tunnel to confirm that it can connect properly
cloudflared --config ~/.cloudflared/config.yaml tunnel run
If this is all green, then you can go to the next step, but if you see some red errors then you need to debug.
Connection failures along the lines of:
Then you need to reconfirm that you have opened up all firewalls to allow outbound port 7844
Once you have confirmed the tunnel can be started manually, you should install the service and enable it:
cloudflared service install systemctl enable --now cloudflared systemctl status cloudflared
Confirm the output of
systemctl status does not show any errors.
When creating the service, the config file in
~/.cloudflared/config.yml is actually copied to
/etc/cloudflared/config.yml. If you are like me, this could confuse the hell out of you for quite some time as you continue to edit the file in it’s original location.
Easy solution here is to have one canonical config file and symlink the other one to it.
cd /etc/cloudflared rm config.yml ln -s /root/.cloudflared/config.yml systemctl restart cloudflared systemctl status cloudflared
Configuring Web Server for Tunnel Protection
We need to have a web server that is listening on whatever port we want. That server should be offering up SSL protection and if possible be running a valid SSL certificate (using letsencrypt is a good option). We need to configure cloudflared to support the service.
- Web server with
- SSL protection
- IP restriction
- Cloudflared config updated with ingress rules
Remove Domains from DNS
If you are trying to protect a subdomain/domain that is already in your cloudflare DNS, then you need to remove it as the tunnel config will create a new CNAME entry.
Create DNS CNAME for Domains
To actually route your protected domain via the tunnel so that it gets the Teams protection, we need to create a CNAME entry. This could be done manually, however the cloudflared tool makes this easy
cloudflared tunnel route dns (uuid) foo.mydomain.co.uk cloudflared tunnel route dns (uuid) bar.mydomain.co.uk
Note (uuid) should be replaced with the uuid of the tunnel you created previously.
Configuring your webserver is up to you and depends on the specific web server software you have installed.
I would hope you already had valid SSL in place. If not, look into using letsencrypt to generate free valid SSL, or you can generate SSL certificates for your origin server within Cloudflare.
IP restriction is generally quite easy to do, but make sure you allow not only 127.0.0.1 but also ::1.
You can choose to restrict all other traffic which then enforces that traffic comes through Cloudflare, or you could opt to allow a few other IPs – those IPs would then need to have custom DNS or hosts file entries to allow direct access.
You need to update your cloudflared config with ingress rules and I’d suggest you do something that looks like this:
tunnel: (uuid) credentials-file: /root/.cloudflared/(uuid).json protocol: http2 loglevel: info logfile: /var/log/cloudflared.log ingress: - hostname: foo.mydomain.co.uk service: https://localhost:443 httpHostHeader: foo.mydomain.co.uk originRequest: connectTimeout: 10s originServerName: foo.mydomain.co.uk noTLSVerify: true - hostname: bar.mydomain.co.uk service: https://localhost:443 httpHostHeader: bar.mydomain.co.uk originRequest: connectTimeout: 10s originServerName: bar.mydomain.co.uk noTLSVerify: true - service: http_status:404
This configure 2 services running on
bar.mydomain.co.uk. This configuration allows you to keep your existing webserver configuration largely unchanged and you should only need to update IP restriction
This also configures a catchall 404 service which is required.
Once you have configured your webserver and cloudflared, make sure you restart both services and then try accessing the protected services via a browser – you should see the teams login page and that’s it, you are now protected.
Tips – Cloudflare Teams is a relatively new name for things that have existed for a while.
Tunnels used to be Argo Tunnels and you will find lots more stuff if you search for Argo Tunnels.
Teams was previously called Cloudflare Access
this article for centmin is also quite useful
WARP is the official Cloudflare Teams client software which can be installed on desktop and mobile devices. Warp is not required for Teams protection of self hosted apps. You may decide you want to use it though for other reasons.
See official install docs
For Fedora, I found that it was needed to do the following:
# Install repo sudo rpm -ivh http://pkg.cloudflareclient.com/cloudflare-release-el8.rpm # Hard code for Centos 8 as we are in Fedora sudo echo '[cloudflare] name=Cloudflare CentOS Packages #baseurl=https://pkg.cloudflareclient.com/dists/$releasever/main/binary-$basearch baseurl=https://pkg.cloudflareclient.com/dists/8/main/binary-$basearch enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CLOUDFLARE-3 '> /etc/yum.repos.d/cloudflare.repo # Install the cli tool sudo dnf install cloudflare-warp # Get warp running sudo warp-cli register sudo warp-cli connect # Ensure this contains warp=on curl https://www.cloudflare.com/cdn-cgi/trace/ # Connect to teams sudo warp-cli teams-enroll