Back to all posts

Bypassing Telekom's Cloudflare Congestion with Tailscale

networkingtailscalenixoscloudflare

Following up on my post about Telekom’s peering issues, here’s a workaround using Tailscale subnet routing. Connection times to Cloudflare-hosted sites dropped from 11+ seconds to under 400ms by routing traffic through a VPS with better peering.

The Setup

I have a NixOS router at home on Telekom fiber (AS3320) and a small VPS at IONOS (€1/month) already running Tailscale for other purposes.

IONOS (AS8560) and Cloudflare (AS13335) are both present at BCIX Berlin with 100Gbps each and open peering policies. Traffic between them stays local instead of traversing congested transit links. Routing through the VPS bypasses Telekom’s bottleneck.

Why Tailscale?

I could set up a dedicated WireGuard tunnel, but Tailscale is already running on both machines. Tailscale supports advertising routes — any node can announce “send traffic for these prefixes through me” and other nodes will route accordingly.

No manual key management. No firewall rules. Just config changes on both ends.

The Configuration

First, get the current Cloudflare IP ranges:

# IPv4
173.245.48.0/20, 103.21.244.0/22, 103.22.200.0/22, 103.31.4.0/22,
141.101.64.0/18, 108.162.192.0/18, 190.93.240.0/20, 188.114.96.0/20,
197.234.240.0/22, 198.41.128.0/17, 162.158.0.0/15, 104.16.0.0/13,
104.24.0.0/14, 172.64.0.0/13, 131.0.72.0/22

# IPv6
2400:cb00::/32, 2606:4700::/32, 2803:f800::/32, 2405:b500::/32,
2405:8100::/32, 2a06:98c0::/29, 2c0f:f248::/32

These are published at cloudflare.com/ips.

VPS Configuration (NixOS)

The VPS needs to advertise these routes and forward traffic:

networking.nat = {
  enable = true;
  externalInterface = "eth0";
  internalInterfaces = [ "tailscale0" ];
};

services.tailscale = {
  enable = true;
  useRoutingFeatures = lib.mkForce "server";
  extraUpFlags = [
    "--accept-dns=false"
    "--advertise-routes=173.245.48.0/20,103.21.244.0/22,103.22.200.0/22,103.31.4.0/22,141.101.64.0/18,108.162.192.0/18,190.93.240.0/20,188.114.96.0/20,197.234.240.0/22,198.41.128.0/17,162.158.0.0/15,104.16.0.0/13,104.24.0.0/14,172.64.0.0/13,131.0.72.0/22,2400:cb00::/32,2606:4700::/32,2803:f800::/32,2405:b500::/32,2405:8100::/32,2a06:98c0::/29,2c0f:f248::/32"
  ];
};

Setting useRoutingFeatures = "server" enables IP forwarding and sets up masquerading automatically. Tailscale handles both IPv4 and IPv6 NAT via its own iptables chains.

Router Configuration (NixOS)

The home router needs to accept the advertised routes:

services.tailscale = {
  useRoutingFeatures = lib.mkForce "both";
  extraUpFlags = [
    "--accept-dns=false"
    "--accept-routes"
  ];
};

Approve the Routes

After deploying both configs, approve the routes in the Tailscale admin console. Find your VPS, click the three dots, and enable the subnet routes.

Verify the routes are installed:

❯ ip route get 104.16.0.1
104.16.0.1 dev tailscale0 table 52 src 100.x.x.x
❯ ip -6 route get 2606:4700::1
2606:4700::1 dev tailscale0 table 52 src fd7a:...

Results

Before (via AS3320):

Connect: 1.19s
TTFB: 11.5s

After (via IONOS):

Connect: 0.013s
TTFB: 0.36s

Checking the trace endpoint confirms traffic exits via the VPS:

❯ curl -s https://www.cloudflare.com/cdn-cgi/trace | grep -E 'ip=|colo='
ip=217.154.155.100 # VPS IP, not home IP
colo=TXL

Download speeds are reasonable too:

❯ curl -so /dev/null -w '%{speed_download}\n' https://speed.cloudflare.com/__down?bytes=100000000
69368668 # ~69 MB/s

That’s around 550 Mbps, limited by the VPS connection.

Caveats

  • Latency overhead: Traffic now goes home → VPS → Cloudflare instead of direct. This adds around 5ms in my case.
  • VPS bandwidth: My IONOS plan has no transfer cap but tops out around 500 Mbps. Still faster than a congested Telekom path.
  • Route updates: Cloudflare occasionally adds IP ranges. The current list has been stable for years, but check annually.
  • Single point of failure: If the VPS goes down, Cloudflare becomes unreachable. Fine for a home setup, but production would need failover.

For €1/month the peering problem is solved. The traffic still crosses Telekom’s network to reach the VPS, but from there it takes a direct path to Cloudflare.

Comments