I’ve heard this before and as bad as that security posture is (and very un-zero trust like) it is unfortunately much more common than I would have ever have believed. And when your end client or critical vendor tells you that you must hit yourself in the face with a hammer, I’d prefer you use this kind:
Instead of this kind:
@leonid.makarov I am in no way implying you aren’t already aware of all of these caveats, but since this is the Interwebs and someone else will come along who doesn’t have full context I’m going to emphasize up front that IP address restrictions are a poor form of security. Trusting an egress IP address and all of the random machines behind it is on many, many levels. So my notes below on how to achieve this try to help improve your security posture to the extent possible.
This can be achieved using what we refer to as TeamNet or Warp to Tunnel Connect from WARP to a private network on Cloudflare using Cloudflare Tunnel · Cloudflare for Teams documentation. While the instructions in the above tutorial mention RFC1918 address space, it’s possible to use this for any address space.
I’m going to assume you are running in our ‘standard’ Exclude mode (Teams | Settings | Networks | Exclude IPs and Domains). For this example we are going to use
iplocation.net which has a public IP of
18.104.22.168 at the moment.
Stand up a tunnel somewhere… in your DC, in the cloud, on a Raspberry Pi. Modifying the steps in the Warp to tunnel scenario you’d add the CIDR range of this website
cloudflared tunnel route ip add 22.214.171.124 your-tunnel-id. Start the tunnel as a service, give it a couple of minutes to sync to our edge and when you visit
iplocation.net it should see the public IP address of the machine running the tunnel.
- Make that IP static in production obviously, else you will have to update it with the vendors if it changes.
1a. You can run multiple instances of this named tunnel for (geo)redundancy.
- Create a network level policy to restrict access to that IP to only the groups / users who need it.
- Monitor for a change to any of the resources you map this way and update the CIDR ranges the tunnel is proxying if the DNS target changes.
- Try not to hit yourself in the face with a hammer any more than is absolutely necessary.
Yeah basically, except ingress rules really only work for hostnames you control; in some instances you can fake that I suppose, but Warp to Tunnel seems to be more flexible overall.