Static outbound IP address with WARP for Team

I’m trying to figure out whether Cloudflare for Teams can provide a solution to an old school approach of securing access to network resources - IP whitelisting.

My team is distributed around the globe. We have clients that would often ask for a list of IPs to whitelist access to their network resources. What we do today, is have several regional VPN instances with a static outbound IP addresses. We give clients the list of these outbound IPs. Now, to access protected resources on the client side you have to be connected to the regional “office” VPN.

Can this be achieved with WARP for Team?
The outbound IP address has to be dedicated and cannot be shared with any other Cloudflare customer.

That sounds very un-Cloudflare like. Why aren’t your clients using a better form of authentication?

I can’t begin to imagine how it’d be possible for Cloudflare to tell WARP which IP address to use for egress, let alone their willingness to surrender an IPv4 address to your organization.

It would seem to me that if you had your own “VPN” box in-house that ran cloudflared with Ingress rules that would connect to your various clients, then they would only need to whitelist that one IP address.

2 Likes

Agree to Sdayman answer. Just 1 VPN server and create some user to access. All other users just connect to that VPN so it’s a private LAN now, then no need to whitelist WAN IP anymore.

It is.

It is.

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:

sledge hammer

@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 :facepalm: 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 107.154.102.114 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 107.154.102.114 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.

  1. 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.
  2. Create a network level policy to restrict access to that IP to only the groups / users who need it.
  3. 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.
  4. 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.

4 Likes

I lost it with the hammer, fantastic response :laughing:

They are large organizations, with established IT rules and policies that don’t change in a snap.
With enterprise clients, you either comply with their rules or move along.

@cscharff very interesting and thank you for a detailed constructive response!
This sounds like a reasonable middle ground solution. I will try it out.

How do I calculate the cost of such setup?
Would it be Teams users + Cloudflare Tunnel ingress/egress (+ ingress/egress of the tunnel host)?

1 Like

From Cloudflare -

Other costs—

  • the cost of hosting your tunnel compute and any bandwidth charges from wherever you’re hosting the tunnels.