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?
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
@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.
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 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
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 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