Stay organized with collections
Save and categorize content based on your preferences.
Policy-based routes
This document provides an overview of Policy-based Routing.
Policy-based routes let you select a next hop based on more than a packet's
destination IP address. You can match traffic by protocol and source IP address
as well. Matching traffic is redirected to an internal passthrough Network Load Balancer. This can help
you insert appliances such as firewalls into the path of network traffic.
Specifications
When you create a policy-based
route, you select which resources
the policy-based route applies to. The route can apply to:
All VM instances, Cloud Interconnect VLAN attachments, and
Cloud VPN tunnels that are in the same VPC network
as the route
Only VM instances that are in the same VPC network
as the route and identified by network
tags
Only VLAN attachments that are in a specific region of the same
VPC network as the route. You can't create a policy-based
route that only applies to a single VLAN attachment or Cloud VPN
tunnel
The next hop of a policy-based route must be a valid
internal passthrough Network Load Balancer. This internal passthrough Network Load Balancer must
either be in the same VPC network as the policy-based route or
in a VPC network that is connected to the route's
VPC network through
VPC Network Peering.
The backend VM instances of the next hop internal passthrough Network Load Balancer must have IP
forwarding enabled.
Policy-based routes are evaluated before subnet routes, static routes, and
dynamic routes, but after special routing
paths. For more information, see the
Policy-based routes step in the routing
order.
If two or more policy-based routes have the same priority, and a packet's
characteristics match at least two of those policy-based routes, Google Cloud
selects a single policy-based route by using an internal algorithm. The
selected policy-based route might not be the most specific match for the
packet's characteristics because policy-based routes don't use longest-prefix
matching. Make sure that all policy-based routes in the same
VPC network have unique priorities.
A policy-based route can apply to either IPv4 or IPv6 traffic.
You can create a single rule for one-way traffic or multiple rules to handle
bidirectional traffic.
Limitations
Policy-based routes are not exchanged between VPC networks that
are connected through VPC Network Peering.
Policy-based routes don't support matching traffic based on port.
It is not possible to update a policy-based route after it is created. If you
want to update a route, delete the route
and then create a new one.
The internal passthrough Network Load Balancer forwarding rule must have a dedicated IP address that's
not used by any other internal passthrough Network Load Balancer. Using a shared IP address (IP address
purpose set to SHARED_LOADBALANCER_VIP) is not supported.
Policy-based routes can interfere with communication between the
GKE control plane and nodes. For more information, see
Use policy-based routes with GKE.
Policy-based routes can't route packets to Private Service Connect
endpoints or backends.
You can create a policy-based route that skips other policy-based
routes by using the Google Cloud CLI or sending an API request. For the
gcloud CLI, use the
--next-hop-other-routes=DEFAULT_ROUTING flag. For an API request,
include "nextHopOtherRoutes": "DEFAULT_ROUTING" with the request body.
If a policy-based
route of this type matches a packet's characteristics and has
a higher priority than other matching policy-based routes, Google Cloud
ignores the other policy-based routes and proceeds to the most specific
destination step of the
VPC routing order.
For example, consider a policy-based route that uses a next hop
internal passthrough Network Load Balancer. This policy-based route has a source
range of 0.0.0.0/0 and a network tag of compute-vm.
To skip evaluation of the first policy-based route when packet sources match
a specific IP address range, create a higher-priority policy-based route that
is configured to skip other policy-based routes. Set the source IP
address range for this higher-priority policy-based route to the
source IP address range of the systems that need to skip policy-based routing.
Quota
There is a limit for how many policy-based routes you can create in a single
project. For more information, see the per-project quotas
in the VPC documentation.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[],[],null,["# Policy-based routes\n===================\n\nThis document provides an overview of Policy-based Routing.\n\nPolicy-based routes let you select a next hop based on more than a packet's\ndestination IP address. You can match traffic by protocol and source IP address\nas well. Matching traffic is redirected to an internal passthrough Network Load Balancer. This can help\nyou insert appliances such as firewalls into the path of network traffic.\n\nSpecifications\n--------------\n\n- When you [create a policy-based\n route](/vpc/docs/use-policy-based-routes#create), you select which resources the policy-based route applies to. The route can apply to:\n - All VM instances, Cloud Interconnect VLAN attachments, and Cloud VPN tunnels that are in the same VPC network as the route\n - Only VM instances that are in the same VPC network as the route and identified by [network\n tags](/vpc/docs/add-remove-network-tags)\n - Only VLAN attachments that are in a specific region of the same VPC network as the route. You can't create a policy-based route that only applies to a single VLAN attachment or Cloud VPN tunnel\n- The next hop of a policy-based route must be a valid [internal passthrough Network Load Balancer](/load-balancing/docs/internal). This internal passthrough Network Load Balancer must either be in the same VPC network as the policy-based route or in a VPC network that is connected to the route's VPC network through [VPC Network Peering](/vpc/docs/vpc-peering).\n- The backend VM instances of the next hop internal passthrough Network Load Balancer must have [IP\n forwarding](/vpc/docs/using-routes#create-vm-canipforward) enabled.\n- Policy-based routes are evaluated before subnet routes, static routes, and dynamic routes, but after [special routing\n paths](/vpc/docs/routes#special_return_paths). For more information, see the [Policy-based routes](/vpc/docs/routes#check-for-pbrs) step in the routing order.\n- If two or more policy-based routes have the same priority, and a packet's characteristics match at least two of those policy-based routes, Google Cloud selects a single policy-based route by using an internal algorithm. The selected policy-based route might not be the most specific match for the packet's characteristics because policy-based routes don't use longest-prefix matching. Make sure that all policy-based routes in the same VPC network have unique priorities.\n- A policy-based route can apply to either IPv4 or IPv6 traffic.\n- You can create a single rule for one-way traffic or multiple rules to handle bidirectional traffic.\n\nLimitations\n-----------\n\n- Policy-based routes are not exchanged between VPC networks that are connected through [VPC Network Peering](/vpc/docs/vpc-peering).\n- Policy-based routes are not exchanged between [Network Connectivity Center spokes and hubs](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview).\n- Policy-based routes don't support matching traffic based on port.\n- It is not possible to update a policy-based route after it is created. If you want to update a route, [delete the route](/vpc/docs/use-policy-based-routes#delete) and then create a new one.\n- The internal passthrough Network Load Balancer forwarding rule must have a dedicated IP address that's not used by any other internal passthrough Network Load Balancer. Using a shared IP address (IP address purpose set to `SHARED_LOADBALANCER_VIP`) is not supported.\n- Policy-based routes can interfere with communication between the GKE control plane and nodes. For more information, see [Use policy-based routes with GKE](/vpc/docs/use-policy-based-routes#pbr-with-gke).\n- Policy-based routes can't route packets to Private Service Connect endpoints or backends.\n - For information about using policy-based routes in VPC networks with endpoints or backends that access published services, see [Policy-based routes and Private Service Connect for published services](/vpc/docs/use-policy-based-routes#pbr-with-psc).\n - For information about using policy-based routes in VPC networks with endpoints or backends that access Google APIs and services, see [Policy-based routes and accessing Google APIs and services](/vpc/docs/use-policy-based-routes#pbr-with-pga-psc-apis).\n- Only VLAN attachments that use [Dataplane v2](/network-connectivity/docs/interconnect/concepts/terminology#dataplaneVersion) can use policy-based routes. To inspect your VLAN attachment to check what version it uses, see the instructions for [Dedicated Interconnect](/network-connectivity/docs/interconnect/how-to/dedicated/viewing-vlans#dataplane) or [Partner Interconnect](/network-connectivity/docs/interconnect/how-to/partner/viewing-vlans#dataplane).\n\nSkipping other policy-based routes\n----------------------------------\n\nYou can create a policy-based route that skips other policy-based\nroutes by using the Google Cloud CLI or sending an API request. For the\ngcloud CLI, use the\n`--next-hop-other-routes=DEFAULT_ROUTING` flag. For an API request,\ninclude `\"nextHopOtherRoutes\": \"DEFAULT_ROUTING\"` with the request body.\n\nIf a policy-based\nroute of this type matches a packet's characteristics and has\na higher priority than other matching policy-based routes, Google Cloud\nignores the other policy-based routes and proceeds to the *most specific\ndestination* step of the\n[VPC routing order](/vpc/docs/routes#routeselection).\n\nFor example, consider a policy-based route that uses a next hop\ninternal passthrough Network Load Balancer. This policy-based route has a source\nrange of `0.0.0.0/0` and a network tag of `compute-vm`.\n\nTo skip evaluation of the first policy-based route when packet sources match\na specific IP address range, create a higher-priority policy-based route that\nis configured to skip other policy-based routes. Set the source IP\naddress range for this higher-priority policy-based route to the\nsource IP address range of the systems that need to skip policy-based routing.\n\nQuota\n-----\n\nThere is a limit for how many policy-based routes you can create in a single\nproject. For more information, see the per-project [quotas](/vpc/docs/quota#policy-based-routes-quota)\nin the VPC documentation."]]