Configure routes

Cloudflare Virtual Network uses a routing table to steer your traffic from Cloudflare's global network to your connected networks via next-hop. You can add entries to the Cloudflare Virtual Network routing table through static route configuration or routes learned from BGP peering over IPsec and GRE tunnels or CNI with Dataplane v2 (closed beta).

Refer to Traffic Steering for more information about all the technical aspects related to:

Routes' priorities and weights
Regional scoping of traffic to reduce latency
BGP peering
Automatic Return Routing (ARR)

Configure static routes

The following IPv4 address ranges are allowed in the Cloudflare Virtual Network routing table:

RFC 1918 ↗︎ address space, specifically 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.

When using Cloudflare WAN and Cloudflare Tunnel together, consider the IP ranges utilized in the static routes of Cloudflare Tunnel when selecting static routes for Cloudflare WAN. For more information, refer to Cloudflare Tunnel.

For prefixes outside RFC 1918, contact your Cloudflare customer service manager.

Create a static route

Log in to Cloudflare One ↗︎, and go to Networks.
Go to Routes > WAN Routes, and select Create to add a new route.
Enter a descriptive name for your route in Description.
In Prefix, enter your range of IP addresses. For example, 10.10.10.100/24.
In Tunnel/Next hop, select a tunnel for your route from the tunnels you created in Configure tunnel endpoints.
Choose the Priority for your route. Lower numbers have higher priorities.
Note
Cloudflare routing applies longest-prefix match. A more specific static route (like /30) always takes precedence over a less specific one (like /29), regardless of tunnel priority — unless you remove the more specific route. Keep this in mind when configuring priorities for your routes. Refer to Route prioritization for more information.
(Optional) Choose a Weight for your route. Refer to Set priority and weights for static routes for examples.
(Optional) If you need to scope your route to a specific region, you can do it in Region code.
(Optional) We highly recommend testing your route before adding it by selecting Test routes.
Select Add routes.

Create a POST request using the API to create one or more static routes.

Example:

Required API token permissions

At least one of the following token permissions is required:

Magic WAN Write
Magic Transit Write

Create a Routebash

curl "https://api.cloudflare.com/client/v4/accounts/%3C/span%3E%3Cspan%20class="nb-shiki-140thh">$ACCOUNT_ID/magic/routes" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"nexthop": "<IP_NEXT_HOP>",
		"prefix": "<YOUR_IP_PREFIX>",
		"priority": 0,
		"id": "023e105f4ecef8ad9ca31a8372d0c353",
		"description": "<ROUTE_DESCRIPTION>",
		"scope": {
				"colo_names": [
						"den01"
				],
				"colo_regions": [
						"APAC"
				]
		},
		"weight": 0
	}'

{
  "errors": [
    {
      "code": 1000,
      "message": "message"
    }
  ],
  "messages": [
    {
      "code": 1000,
      "message": "message"
    }
  ],
  "result": {
    "routes": [
      {
        "nexthop": "203.0.113.1",
        "prefix": "192.0.2.0/24",
        "priority": 0,
        "id": "023e105f4ecef8ad9ca31a8372d0c353",
        "description": "New route for new prefix 203.0.113.1",
        "scope": {
          "colo_names": [
            "den01"
          ],
          "colo_regions": [
            "APAC"
          ]
        },
        "weight": 0
      }
    ]
  },
  "success": true
}

Edit a static route

In Routes > WAN Routes, locate the route to modify.
Select the three dots next to it > Edit.
Enter the updated route information.
(Optional) We highly recommend testing your route before adding it by selecting Test routes.
Select Edit routes.

Create a PUT request using the API to update one or more static routes.

Example:

Required API token permissions

At least one of the following token permissions is required:

Magic WAN Write
Magic Transit Write

Update Routebash

curl "https://api.cloudflare.com/client/v4/accounts/%3C/span%3E%3Cspan%20class="nb-shiki-140thh">$ACCOUNT_ID/magic/routes/$ROUTE_ID" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"nexthop": "<IP_NEXT_HOP>",
		"prefix": "<YOUR_IP_PREFIX>",
		"priority": 0,
		"id": "023e105f4ecef8ad9ca31a8372d0c353",
		"description": "<ROUTE_DESCRIPTION>",
		"scope": {
				"colo_names": [
						"den01"
				],
				"colo_regions": [
						"APAC"
				]
		},
		"weight": 0
	}'

{
  "errors": [
    {
      "code": 1000,
      "message": "message"
    }
  ],
  "messages": [
    {
      "code": 1000,
      "message": "message"
    }
  ],
  "result": {
    "modified": true,
    "modified_route": {
      "nexthop": "203.0.113.1",
      "prefix": "192.0.2.0/24",
      "priority": 0,
      "id": "023e105f4ecef8ad9ca31a8372d0c353",
      "description": "New route for new prefix 203.0.113.1",
      "scope": {
        "colo_names": [
          "den01"
        ],
        "colo_regions": [
          "APAC"
        ]
      },
      "weight": 0
    }
  },
  "success": true
}

Delete static route

In Routes > WAN Routes, locate the static route to delete.
Select the three dots next to it > Delete.
Confirm the action by selecting the checkbox and select Delete.

Create a DELETE request using the API to delete a static route.

Example:

Required API token permissions

At least one of the following token permissions is required:

Magic WAN Write
Magic Transit Write

Delete Routebash

curl "https://api.cloudflare.com/client/v4/accounts/%3C/span%3E%3Cspan%20class="nb-shiki-140thh">$ACCOUNT_ID/magic/routes/$ROUTE_ID" \
	--request DELETE \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

{
  "errors": [
    {
      "code": 1000,
      "message": "message"
    }
  ],
  "messages": [
    {
      "code": 1000,
      "message": "message"
    }
  ],
  "result": {
    "deleted": true,
    "deleted_route": {
      "nexthop": "203.0.113.1",
      "prefix": "192.0.2.0/24",
      "priority": 0,
      "id": "023e105f4ecef8ad9ca31a8372d0c353",
      "description": "New route for new prefix 203.0.113.1",
      "scope": {
        "colo_names": [
          "den01"
        ],
        "colo_regions": [
          "APAC"
        ]
      },
      "weight": 0
    }
  },
  "success": true
}

Configure Automatic Return Routing

Automatic Return Routing allows Cloudflare to track network flows from your Cloudflare WAN (formerly Magic WAN) connected locations, ensuring return traffic is routed back to the connection where it was received without requiring static or dynamic routes. This functionality requires Unified Routing mode.

To enable ARR:

Follow the Add tunnels information to learn how to create an IPsec or GRE tunnel.
On the tunnel's options, select Automatic return routing.
Select Add tunnels to save your changes.

Create a POST request to create an IPsec or GRE tunnel with ARR enabled. For example:

Required API token permissions

At least one of the following token permissions is required:

Magic WAN Write
Magic Transit Write

Create an IPsec tunnelbash

curl "https://api.cloudflare.com/client/v4/accounts/%3C/span%3E%3Cspan%20class="nb-shiki-140thh">$ACCOUNT_ID/magic/ipsec_tunnels" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"cloudflare_endpoint": "<CLOUDFLARE_ENDPOINT>",
		"interface_address": "<INTERFACE_ADDRESS>",
		"name": "IPsec_1",
		"customer_endpoint": "<CUSTOMER_ENDPOINT>",
		"description": "Tunnel for ISP X",
		"psk": "<PSK>",
		"automatic_return_routing": "true"
	}'

Configure BGP routes

BGP peering is available when using the following on-ramps:

IPsec and GRE tunnels. Requires Unified Routing.
CNI with Dataplane v2 (closed beta and not available to new customers).

Choose an ASN for BGP peering

The Cloudflare Virtual Network routing table is managed by the customer. You can select both the Cloudflare-side ASN (Autonomous System Number) and the ASN for your customer device. The customer device ASN can be 2-byte or 4-byte.

By default, each BGP peering session uses the same Cloudflare-side ASN to represent peering with the Cloudflare Virtual Network routing table. This ASN is called the CF Account ASN and is set to 13335. You can configure this to a private 2-byte ASN (any value between 64512 and 65534, such as 65000).

The CF Account ASN applies to all BGP sessions in your account, over both IPsec/GRE tunnels and CNI. It must be different from the customer device ASN on each tunnel.

To set this ASN:

Log in to Cloudflare One ↗︎, and go to Networks.
Go to Routes > WAN configuration.
In Border Gateway Protocol (BGP) configuration, select Edit and enter your ASN.
Select Save.

Create a PUT request to update the BGP settings for your account. The following example sets the CF Account ASN to 65000:

Update BGP Settingsbash

curl "https://api.cloudflare.com/client/v4/accounts/%3C/span%3E%3Cspan%20class="nb-shiki-140thh">$ACCOUNT_ID/magic/bgp/settings" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"cloudflare_asn": 65000
	}'

Cloudflare WAN customers should also be aware of the following:

The customer chooses their device ASN, which must be different from the Cloudflare-side ASN.
The Cloudflare side ASN will be included in the AS_PATH of announced routes to any BGP enabled on-ramp (interconnect, IPsec or GRE tunnel).
The customer-announced AS_PATH is transitive between on-ramps — meaning the origin (customer) ASN is visible in the AS_PATH of routes received from Cloudflare via BGP. Due to default BGP loop prevention mechanisms, a router will reject any route that contains its own ASN in the AS_PATH. For example, if two Cloudflare WAN-connected sites both use ASN 65000, site A will not accept routes from site B, and vice versa, because each site sees its own ASN in the advertised AS_PATH.
To enable routing between private networks over Cloudflare WAN, you should either:
- Assign a unique ASN to each site/network, or
- Configure your edge CPE to accept BGP routes that include its own ASN in the AS_PATH.

Set up BGP peering

You need to configure two ASNs:

The Cloudflare account-scoped ASN named CF Account ASN.
One ASN for each on-ramp you want to configure with BGP.

If you have already set up your Cloudflare account ASN, skip steps two and three below.

Set up BGP for an interconnect

Log in to Cloudflare One ↗︎, and go to Networks.
Go to Routes > WAN configuration.
In Border Gateway Protocol (BGP) configuration, select Edit ASN and enter your ASN.
Go to Networks > Connectors > Interconnects.
Locate the CNI interconnect with Dataplane v2 to configure with BGP > select the three dots next to it > Configure BGP.
In Customer device ASN, enter the ASN for your network.

Note
Multiple tunnels or interconnects with the same ASN will not exchange routes if standard BGP loop prevention is enabled. Consider using a different ASN per session, or enabling duplicate ASNs (like Cisco's allowas-in feature) to exchange routes between networks.
In MD5 key, you can optionally enter the key for your network. Note that this is meant to prevent accidental misconfigurations and is not a security mechanism.
(Optional) In Additional Advertised prefix list, input any additional prefixes you want to advertise alongside your existing routes. Leave this blank if you do not want to advertise extra routes. Typical prefixes to configure here include:
- A route to 0.0.0.0/0, the default route — to attract all Internet-bound traffic if using Cloudflare WAN with Gateway.
- A route to 100.96.0.0/12, the portion of CGNAT space used by default with Cloudflare One Clients.
- A route to 100.64.0.0/12, the portion of CGNAT space used by default for Cloudflare Source IPs.
Select Save.

Set up BGP for IPsec/GRE tunnels

Log in to Cloudflare One ↗︎, and go to Networks.
Go to Routes > WAN configuration.
In Border Gateway Protocol (BGP) configuration, select Edit ASN and enter your ASN.
Go to Networks > Connectors > Cloudflare WAN.
In IPsec/GRE tunnels, locate the tunnel you want to configure with BGP > select the three dots next to it > Configure BGP.
In Customer device ASN, enter the ASN for your network.

Note
Multiple tunnels or interconnects with the same ASN will not exchange routes if standard BGP loop prevention is enabled. Consider using a different ASN per session, or enabling duplicate ASNs (like Cisco's allowas-in feature) to exchange routes between networks.
In MD5 key, you can optionally enter the key for your network. Note that this is meant to prevent accidental misconfigurations and is not a security mechanism.
(Optional) In Additional Advertised prefix list, input any additional prefixes you want to advertise alongside your existing routes. Leave this blank if you do not want to advertise extra routes. Typical prefixes to configure here include:
- A route to 0.0.0.0/0, the default route — to attract all Internet-bound traffic if using Cloudflare WAN with Gateway.
- A route to 100.96.0.0/12, the portion of CGNAT space used by default with Cloudflare One Clients.
- A route to 100.64.0.0/12, the portion of CGNAT space used by default for Cloudflare Source IPs.
Select Save.

Important remarks for GRE/IPsec tunnels

If you are configuring BGP peering for a tunnel (GRE or IPsec) you must be aware of the following:

Your Customer Premises Equipment (CPE) must initiate the BGP peering session. Cloudflare will not initiate.
Your BGP speaker must peer with the tunnel's IPv4 interface address. Your CPE may use any IPv4 address for its side of the peering connection; it does not need to use the other address from the /31 or /30 interface subnet.

Caution
If the tunnel is to an Azure VPN gateway, the tunnel interface address must not be in the link-local range. Azure will not initiate BGP sessions to peers using link-local addresses. Use an RFC 1918 address for your tunnel interface address instead.
Hold time must be 30 seconds or greater. Cloudflare recommends at least 90 seconds. Cloudflare advertises a hold time of 240 seconds, so if you set a value greater than 240 seconds, the negotiated hold time will be 240 seconds.
Connect retry time should be low (for example, five or 10 seconds).
Your CPE may advertise up to 5,000 prefixes on one BGP session.
MD5 authentication is optional. You can use a maximum of 80 characters. Supported characters include a-zA-Z0-9'!@#$%^&*()+[]{}<>/.,;:_-~`= \\|

Caution
MD5 authentication is not a valid security mechanism. The MD5 key is not treated as a secret value. This is only supported for preventing misconfiguration, not for defending against malicious attacks.
When MD5 is enabled, you cannot use Telnet to test BGP connectivity (Telnet does not support TCP MD5 authentication).

Filter BGP routes

BGP filter profiles control routes exchanged over your peering session with Cloudflare. They apply to BGP over GRE or IPsec tunnels.

Each account-scoped profile requires a unique name, one match action, and up to 1,000 Classless Inter-Domain Routing (CIDR) targets.

Match actions have the following behavior:

Match action	Behavior
`allow`	Accept matching routes and reject everything else.
`deny`	Reject matching routes and accept everything else.

Each CIDR target has a matching mode that determines whether the prefix and its subnets match:

Matching mode	Syntax	Matches
Exact prefix	`10.0.0.0/8`	Only `10.0.0.0/8`.
Prefix and more-specific routes	`10.0.0.0/8+`	`10.0.0.0/8` and every more-specific subnet.
Exact length	`10.0.0.0/8{16}`	Every `/16` subnet within `10.0.0.0/8`.
Length range	`10.0.0.0/8{16,24}`	Every `/16` through `/24` subnet within the prefix.

Each tunnel supports one import filter and one export filter.

Import filters apply to routes Cloudflare receives from the peer. Rejected routes do not enter the Magic routing table. Rejected routes remain in the local routing information base (RIB-in). Making the filter more permissive adds them to the Magic routing table without a route refresh.

Export filters apply to routes selected for peer advertisement. Prefixes in the tunnel's extra_prefixes field bypass export filters.

Create profiles

Go to the Routes page.
Go to Routes ↗
From the BGP filter profiles tab, select Create filter profile.
Enter a descriptive Name for your filter profile and optionally add a Description.
Choose Allow or Deny as the Action to take when a route matches a target.
Add a Target by entering a CIDR prefix in CIDR prefix. Choose which Match mode this target should use.
If you want to add more targets, choose Add target.
Select Create.

You need your account ID and API token to use the API.

The following request creates an allow profile for corporate subnets:

Create BGP Filter Profilebash

curl "https://api.cloudflare.com/client/v4/accounts/%3C/span%3E%3Cspan%20class="nb-shiki-140thh">$ACCOUNT_ID/magic/bgp/filter_profiles" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Allowed on-premises imports",
		"description": "Corporate subnets accepted from the customer router",
		"match_action": "allow",
		"targets": [
				"10.0.0.0/8+",
				"192.168.0.0/16",
				"2001:db8::/32+"
		]
	}'

Profile targets have these requirements:

Targets must use valid CIDR network addresses without whitespace. Cloudflare rejects duplicate or equivalent targets.
Profiles support IPv4 and IPv6 targets, but not IPv4-mapped IPv6 targets.

Assign profiles

Go to the Connectors page and choose IPsec/GRE tunnels.
Go to Connectors ↗
Choose Create a tunnel to make a new tunnel or choose Configure BGP from the three-dot menu next to an existing tunnel.
Select a profile from Import filter profile. To remove it, select X next to the selected profile.
Repeat for Export filter profile.
Choose Add tunnels or Save.

The following request assigns import and export profiles to a GRE tunnel. Set each field to a profile ID from your account.

Required API token permissions

At least one of the following token permissions is required:

Magic WAN Write
Magic Transit Write

Update GRE Tunnelbash

curl "https://api.cloudflare.com/client/v4/accounts/%3C/span%3E%3Cspan%20class="nb-shiki-140thh">$ACCOUNT_ID/magic/gre_tunnels/$GRE_TUNNEL_ID" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"bgp": {
				"import_filter_id": "a1b2c3d4e5f647890a1b2c3d4e5f6789",
				"export_filter_id": "b2c3d4e5f6a78901b2c3d4e5f6a78901"
		}
	}'

To remove an assigned profile, set its corresponding field to null.

Profile assignments have these behaviors and limits:

Changing a profile or a tunnel's profile assignments does not reset BGP sessions.
You cannot delete an in-use profile. Detach the profile from all tunnels first.
Cloudflare enforces the 5,000-route RIB-in limit before import filtering. Rejected routes still count toward this limit.

Next steps

Now that you have configured your tunnels and routes, the next step is to create a site. Sites represent the local network of a data center, office, or other physical location, and combine all on-ramps available there. Sites also allow you to check, at a glance, the state of your on-ramps and set up health alert settings so that Cloudflare notifies you when there are issues with the site's on-ramps.

Refer to Set up a site for more information.