Restrict and verify Cloudflare access

Everything connects now. This lesson is about making sure not everything is allowed, and then proving it.

First, enable the Gateway proxy for the protocols your lab needs. Network policies only apply to traffic the proxy handles. Switch on TCP at minimum. Add UDP and ICMP too if you want your ping tests governed by policy, which I recommend, because otherwise ping succeeds for everyone and teaches you nothing.

Now create two policies. An allow policy for your test identity, destination, and port. Then a lower-priority catch-all block for the private range, so no enrolled device gets broad network access by accident:

priority  action  who               destination     port
1         allow   [email protected]   10.0.1.100/32   22, 80
2         block   everyone          10.0.0.0/8      any

Let’s prove the allowed path. From the remote device, open the private HTTP service and SSH into the host:

ssh [email protected]
curl -I http://10.0.1.100
# HTTP/1.1 200 OK

Both should work. If SSH hangs, check that port 22 is in the allow rule and that the Gateway proxy has TCP enabled.

Then test something that should be denied. Port 2222 on the same host falls outside your allow rule, so the catch-all should swallow it:

ssh -o ConnectTimeout=5 -p 2222 [email protected]
# ssh: connect to host 10.0.1.100 port 2222: Connection timed out

Here the timeout is the passing result. The denied test matters as much as the allowed one. A policy that permits correctly but fails to block is broken in the dangerous direction, and nothing on the happy path will ever tell you.

Now read the Gateway network logs. Each connection shows which policy matched it. You should see your allow rule for the SSH and HTTP connections, and your block rule for the port 2222 attempt. If a connection shows no matching policy at all, the proxy is not handling that protocol.

If the results confuse you, check in this order: device connection, Tunnel health, routes, policy logs, destination service. Each step either passes or points at the layer to fix.

Save evidence for both tests: log excerpts or screenshots, with the date. When someone later asks “who can reach this system?”, you answer with evidence instead of belief. I keep a short text file per lab with the exact commands and their output, and it has saved me more than once.

The classic misconfiguration is inverted priority, with the block rule sitting above the allows. Everything gets denied, and the logs show the block rule matching your own test connection. The logs make the fix obvious. That is one more reason to read them now, while nothing is on fire.