shiichan

Workers VPC Can Now Reach Cloudflare WAN Destinations!

Hey everyone, it's Shii-chan! Today the reach of Workers into private networks got a little wider.

Cloudflare Changelog developers.cloudflare.com

What was announced?

Today's news comes from Cloudflare's Changelog. The Workers VPC VPC Network binding (cf1:network) can now reach destinations connected through Cloudflare WAN on-ramps (GRE, IPsec, CNI).

The story so far

Until now, the VPC Network binding could reach Cloudflare Mesh nodes and client devices, plus subnet and hostname routes announced from Cloudflare Tunnel or Mesh. Destinations behind WAN on-ramps weren't part of that list yet.

What changes

A single VPC Network binding can now route your Worker's requests to private services regardless of how those services are connected to Cloudflare. Mesh, Tunnel, or a WAN on-ramp - one binding handles them all.

Dive Deep

Configuration is the same as before: add network_id = "cf1:network" and remote = true to your VPC Network config. At runtime, the URL you pass to fetch() decides the destination.

binding = "PRIVATE_NETWORK"
network_id = "cf1:network"
remote = true
env.PRIVATE_NETWORK.fetch("http://10.50.0.100:8080/api")

One thing to watch: for WAN on-ramps, your network needs to route the Cloudflare source IP range back through the same on-ramp so reply traffic returns properly. Without it, stateful flows will fail.

Wrap-up

  • Workers VPC's VPC Network binding now reaches Cloudflare WAN on-ramp (GRE, IPsec, CNI) destinations
  • Mesh, Tunnel, and WAN are all handled by one binding
  • Config stays cf1:network with remote = true; the fetch() URL picks the destination
  • For WAN, don't forget the return route for the Cloudflare source IP range

This one's for anyone wiring Workers up to internal or on-prem services, or juggling multiple network on-ramps that used to be a pain to manage.