Connect to external services with IP block lists

If you're migrating from a traditional office network or a centralized VPN concentrator, you might have external servers that don't run Tailscale but still need their connections secured.

Third-party or internal services running on serverless cloud providers such as Heroku might use an IP block list (sometimes called an IP allowlist). When a service uses an IP block list, the service expects all user traffic to originate from a single IP address or a few IP addresses. Because Tailscale doesn't need to send all traffic through a central concentrator, your user traffic will suddenly start arriving from all over the internet, running into the IP block list protections operated by your service provider.

What is an IP block list?

Setting up secure links between devices in different locations often proves challenging. As a result, it’s common to operate "internal use" services that still use internet-facing ports and IP addresses between devices in different locations and connect to those servers from their office locations. This is common with SSH, RDP (remote desktop protocol), and various web services.

The exposed port allows attacks from anywhere on the internet, including attacks such as port scanning, password guessing, infrastructure zero-days, and so on. Even if the service itself requires encryption and multifactor authentication, a bug anywhere in the stack could result in a complete bypass of security protections.

To make these kinds of attacks harder, the best practice is to restrict which IP addresses are allowed to initiate connections to your service, usually at the firewall level. This makes your server invisible to most of the internet, so potential malicious actors don't know where to attack.

Unfortunately, IP block lists have a few flaws:

• IP block lists are, essentially, security by obscurity. If an attacker can learn which IP addresses are allowed to initiate connections—and this is not always too hard to guess—then a sufficiently dedicated attacker can forge packets from that address or take control of a device located at that address (for example, using a botnet), to talk to the server.

• Users are not all at a single location. Remote workers, multiple offices, or servers in various data centers generate traffic from different IP addresses. IP block lists need to become longer and longer to ensure that all those locations can access the service. And the longer the block list, the more ways an attacker can get in.

• Cloud VPCs make IP address propagation even worse. If you have internal services running in a cloud provider that accesses the internet using NAT gateways and elastic IP addresses, then your traffic might come from a variety of IP addresses, possibly entire subnets. This can require an extensive IP block list to cover, for example, whole AWS address blocks, just in case your services get allocated one of those blocks. This makes an attacker's job much easier because all they need to do is run their attack from one of those cloud providers and wait until they get allocated an IP address in one of your permitted subnets.

• To avoid this problem, some companies route all their internal traffic through a single VPN concentrator or central internet gateway, making all traffic appear to come from a single IP address. However, this approach adds a lot of latency for devices not near the central gateway (geographically). It also adds a single point of failure and a choke point for internet bandwidth.

Nevertheless, IP block-listed services are a fact of life. If you can't make a secure VPN tunnel to your service provider, for example, because you don't have the rights to install any software at the hosting provider or because a third party operates the software, IP block lists are still considered the best practice (in addition to other security measures).

Use Tailscale app connectors to improve IP block lists

In a pure Tailscale network, you don't need IP block lists because you have something better: Tailscale's secure IP addresses, which aren't allowed over the physical network. You also have Tailscale role-based ACLs, which let you configure which groups of users are allowed to access a particular server. This lets you build something like a central IP block list, using encryption keys instead of IP addresses for protection.

However, most networks are not pure Tailscale, and you eventually need to integrate with a third-party service. Luckily, Tailscale can help you significantly reduce the size of your IP block list (and consequently the surface area for attack) without centralizing your network access. This approach also lets your users access the service from anywhere.

To use Tailscale to improve IP block lists, set up an app connector to route traffic for a specific application through a single IP address. This IP address is the only one that needs to be on the IP block list. The app connector acts as a subnet router, providing access to the external service from your Tailscale network.