Using WARP 1.1.1.1 with remote db/cloud servers that require static ip to restrict access

Hello everyone,

I am not new to Cloudflare but I am new to WARP/1.1.1.1. We just set up our teams account a week or so ago and have started to implement WARP and other team features.

Certain members of my development team need to direct access to our cloud databases and those databases utilize ip address whitelisting, along with basic authentication in order to gain access.

Other members of my development team need to direct access to our back end cloud servers in which I can also utilize utilize ip address whitelisting with SSH keypair authentication (no other ports are open here/ only SSH/22). Essentially, I grant and deny access to a server manually (today) by whitelisting a developers IP and then ensuring their SSH creds are on the server.

This method is not really scalable ands we were contemplating implementing a VPN solution to solve the ip W/L issue.

With that said, there are two things that I need help with in our attempt to utilize WARP/1.1.1.1. Hoping someone smarter and more experienced than me can provide some direction.

(1) Remote db access: I need to be able to provide a IP address (static) to restrict within our remote database configuration. So when a developer is connected to WARP, then at least they will be able to connect to the db using their basic auth credentials. If someone is terminated from the company or their access needs to change, then those changes can be made at the user level in Teams.

(2) Access to cloud servers: Similar to the #1, I need to be able to provide a IP address (static) to restrict within our cloud firewalls. So when a developer is connected to WARP, then at least they will be able to connect via ssh to the back end. If someone is terminated from the company or their access needs to change, then those changes can be made at the user level in Teams.

Any ideas as to how we would solve this without too much complication?

Any ideas?

Why not use cloudflare teams features instead of ip whitelisting, like you can connect the vpc of your db and database to cloudflare based which you create access policy

Use Warp to Tunnel with the IPs of the cloud dabs they will be connecting to and allow list the public up of the servers hosting the tunnel.

https://developers.cloudflare.com/cloudflare-one/tutorials/warp-to-tunnel

1 Like

@cscharff and @cloudcreatr thank you for the replies. I think I should add a bit more color.

We are using managed db’s by Digital ocean and it only allows access by WL ip’s (for direct access to the DB). We cannot change this feature.

As far as I have seen, most if not all cloud managed DB services will be the same. We have tested Scalegrid, Google Cloud Managed DB and Cicso Managed db as well. All services, WL ip’s for direct access.

If the DB’s were running on a local host (my own server), the of course this would be a little easier.

I am not an expert on setting up tunnels, but I have the technical proficiency to follow the documentation and understand what I am doing.

Are you suggesting that I set up a tunnel between CF and one of my cloud servers which already has access to the databases in question?

And then I can grant access to that tunnel in Teams (to a user)?

If so, I would ask this…does it make sense to set up a server that only serves as a host for the tunnels. i.e. a tunnel server, and then I give that server access to the db (and potentially other resources)?

Can a teams user then get access to multiple tunnels in a single session?

Let me make this clear warp doesn’t provide static ip and you can use warp for better security, let me tell how it works

You have VPC in which you have DB and cloud server, that VPC is associated with a private ip range.

You connect the VPC to cloudflare teams using tunnel , now anyone with warp for teams can SSH in your cloud server with private ip. So you can now lockdown the public ip and the firewall. You can even close the port 22 in digital ocean firewall

In cloudflare for team’s, when user use warp for teams you have access to what ip or destination an user can reach so you first block all the request to that private ip range and then you only allow people who are authorised to access like the cloud server.

When someone leaves the organisation you can revoke user access from dashboard and adjust the policy to not include him

With Warp to Tunnel you can have known egress IPs. 3rd parties rarely care about your needs for security unless you are in the S&P 500. Legacy security requirements are legacy but exist nonetheless.

1 Like

This all makes sense and I get it. I’m still confused as to how I’d connect to the remote db since I’d need to WL my local ip?

What’s that’s, can you elaborate

WL = WhiteList

To connect to managed db’s (remote connections) you can only connect if the ingress ip is white listed in the remote ip settings of the db host. We use digital ocean managed databases for our use case.

Interesting :nerd_face: what would be the private ip of my local machine when connecting to AWS VPC also if connecting to AWS VPC will not my public ip Change to AWS public ip as i am connecting to AWS VPC

Try using the private ip of the machine on which the cloudflared is installed

I’m semi-confused as to why cloudflared isn’t working as intended in the first place. As far as I’m aware, the IP problem shouldn’t be occurring, as cloudflared uses an outbound connection to Cloudflare, not an inbound. This alone should mean that requests should look like 127.0.0.1/localhost is making the connection from the perspective of the database, not any other IP. This is how cloudflared works, even when there are no ports open. Using WARP is just a glorified WireGuard VPN, I highly doubt changing to a different VPN would fix this.

All of the access control requirements should be handled in Cloudflare Access anyway.

Hmm, for a test i spin up two VM in same vpc and in one i install cloudflared and add warp routing to it. When i wanted to access the second VM using private ip it was not possible but when i Whitelisted the private ip of the first VM in second VM both were able to communicate and moreover I was able to access the second VM ssh using private ip. So i guess the private ip of the machine in which cloudflared is installed can be used of whitelisting and the private ip of that machine is our private ip

I get the point. Here is our real work scenario.

VPC 1
— dev server VM
— prod sever VM
— other prod severs

Only accessible when using tunnel to VPC VM
— dev db cluster
— prod db cluster

I want to be able restrict/allow access to each or any of the above.

Do I need Cloudflared running on both dev an prod servers above? And then I can restrict access to each tunnel via WARP?

I don’t get clearly but one cloudflared on one server is enough to access whole VPC until the server is able to communicate with in the VPC with other server

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.