Choose and clean up the right design

You built the same capability twice in this course: once with WireGuard, once with Cloudflare. Neither is “the right one”. Each fits different requirements, and now you know both well enough to choose.

Choose WireGuard when you want a small protocol, control of both peers, and your own endpoint. Nothing sits between you and your traffic. The cost is that everything is yours: key distribution, server patching, routing, DNS, and firewall design.

Choose Cloudflare private access when outbound-only connectivity, managed clients, identity, and destination policy are the central requirements. You accept a third party in the path. In exchange you get policies that understand who is connecting, not just which key they hold.

And sometimes neither is right. For one web application, Cloudflare Access in front of the app may be narrower than any network access. The user reaches one app in the browser and touches no network at all. For two networks that must behave as one, a site-to-site design fits better than per-device clients ever will.

Here is the summary I would pin above my desk:

one device → your network, full control        WireGuard remote access
workforce → internal apps, identity rules      Cloudflare private access
a few people → one web app                     Access in front of the app, no tunnel
network ↔ network, permanently                 site-to-site design

Decide from the sentence you wrote back in the first module: who must reach what. The design falls out of the sentence. If you can’t write the sentence, you are not ready to pick a tool.

Now finish the course by removing the lab completely. That means lab peers, keys, routes, policies, enrolled devices, tunnels, firewall rules, and any paid server. Leftover access paths are a real risk. A forgotten peer key is a credential, and a forgotten tunnel is a door.

Then confirm the private resource is unreachable. The proof of a cleanup is a failed connection:

ping -c 2 -W 2 10.0.1.100
# 2 packets transmitted, 0 received, 100% packet loss

ssh -o ConnectTimeout=5 [email protected]
# ssh: connect to host 10.0.1.100 port 22: Operation timed out

Here, the timeout is the passing test. If the ping still gets replies, something is still routing that address, and you are not done.

The cleanup mistake people make is walking only one list. Deleting the cloud server while the Zero Trust organization still holds routes and enrolled devices leaves config pointing at nothing. Or worse, pointing at whatever gets that IP next.

So walk both inventories. The cloud provider’s resources: servers, firewall rules, security groups. And the Cloudflare organization’s configuration: tunnels, routes, policies, devices, enrollment rules. Done means both are empty.

I do this cleanup the same day I finish a lab, while I still remember every piece I created. A week later, I won’t.