Request: Fly IP ranges

It would be helpful if there was a queryable list (global to fly or just IPs specific to me) with all the IP addresses in use. I’d like to add IP restriction and therefore another layer of security to a host that my fly servers query.

here’s the AWS equivalent.
https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html

1 Like

Here’s their current IPs. It may be best to use Fly’s ASN rather than their IP range if possible (Some tools & services let you do this).

Importantly: anyone can run a server on fly, so it’s not much of a security improvement.

If you aren’t using it yet, consider mutual TLS for protecting traffic between your services.

1 Like

Thanks! That helps. Yes definitely using TLS, but just trying to add more layers to my security.

You mean either mutual TLS or SSL with an authorisation key, right? Because I can still start a Fly app and make requests to your server over TLS.

What kind of IP restriction are you planning on adding? Filtering based on remote IP address?

If that’s the case, our AS40509 IPs may not be the ones you see. You’ll most likely see each individual server’s IP addresses which aren’t assigned to our AS. Unfortunately that means there’s no specific range of IPs we can publish. We could publish each one of our IPs though :thinking:. Will have to check with the team.

1 Like

An issue we’ll run into with trying to publish IP ranges is we regularly add IPs, so even if we could provide an up-to-date page to pull them from, there would still be windows of time where the local copy your app would have would be out of sync. For a security-relevant feature, it’s probably better to keep it clear that our IP addresses are subject to change.

1 Like

yeah filtering based on remote IP address was the goal. I suspect I may be thinking about things wrong though.

Personally, I’d avoid filtering in this way - it’s a layer of security through obscurity doesn’t stop an attacker (anyone can use Fly’s IPs) and could likely result in your app breaking if Fly’s IPs change. Mutual TLS (client certificates validated on the server to be signed by a CA you control) should be more than good enough.

Out of curiosity, are your DBs accessible over IPv6? We’re working on exposing the v6 IPs for a given app through our API, you could use those to keep a firewall updated pretty easily. Those IPs aren’t shared so they’re the only ones I’d use for something like this.

@david what kind of host are you querying? The holy grail for this would be to bridge from your host into your app with Wireguard and just get it on the same logical private network. We’re working on this. :wink:

1 Like

Yes they are! Or at least I think they are IPV6 accessible. They’re AWS RDS instanced. Count me as very interested in the IPV6 approach

Regarding wireguard… I’m not familiar with that beyond my cursory googling saying it’s a tunnel. Happy to try something in alpha or beta though!

Thanks Ben and Kurt!

Hey,

I was looking for fly’s IP ranges (the equivalent of e.g https://www.cloudflare.com/en-gb/ips/) and came across this.

Since hosted databases from Azure and AWS don’t support mutual TLS and fly’s own database is still in beta, I wondered whether there had been progress with the proposed IPv6 approach?

How else do people handle this situation of accessing a hosted database or anything with a firewall? Do you have to open it to any IP?

Thanks.

We do have a decent example of how to connect to an RDS instance, it runs a wireguard peer + pgbouncer within a VPC: GitHub - fly-apps/rds-connector: Trivial Terraform example for a WireGuard peer to RDS

The best way to do this is to create “gateways” in your Azure or AWS private networks. You make Fly wireguard peers work, or you can run something like Tailscale in your app instances and let it manage all that.

As much as I hate IP allow lists, we might have what you need to use those in a few months. We just need a whole bunch more IPs first.

1 Like

Thanks @kurt I’ll take a look

Thinking about this, yes, IP-allow lists certainly aren’t perfect (as a determined attacker could go via fly, in theory, as discussed).

But the big appeal of them is they remove that one more thing to deal with, at my end (that inevitably decides to stop working at 2am). Whether its an additional vm gateway through which all requests pass, a software process, proxy, etc. It’s something which then needs monitoring and redundancy. As without that thing working, no database access. Big problem.

So personally I’d +1 for IP lists.

(And also given that a certain rival provides the option of assigning an external IP to an app to solve this problem. And I don’t want to give them any more money :slight_smile: )

@kurt We have a client who wants to give access to a specific endpoint on their infrastructure. As this is a quick one-off project, nobody wants to setup a system around Wireguard and instead use simple IP whitelisting. Is there a list of ip ranges from the ams region?

There are a lot of IPs these could be in Amsterdam, and they could change at any time. If it gets you unstuck you can use them but your life will be way easier if you find some other way to get this working.

Right now they’ll need to allow:

104.225.98.0/24
145.40.96.0/24
147.75.85.0/24
104.225.98.0/24
147.75.87.0/24

Got it, thanks!

Can I please have a list of IPs for ewr I have this very same issue. The service I am using MUST have have a list of IPs and the ones in the app overview don’t work.

@tchillo all the same caveats apply, here are ranges we use in ewr:

139.178.64.0/24
136.144.58.0/24
209.177.145.0/24
199.38.181.0/24
1 Like