Stay organized with collections
Save and categorize content based on your preferences.
Google Cloud load balancers typically require one or more firewall rules
to ensure that traffic from clients reaches the backends.
Most load balancers are required to specify a health check for backend
instances. For the health check probes to reach your backends, you must create
an ingress allow firewall rule that allows
health check probes to reach your backend instances.
Load balancers based on Google Front Ends (GFEs) require an ingress allow
firewall rule that permits traffic from the GFE proxy to reach the backend
instances. In most cases, GFE proxies use the same source IP ranges as the
health check probes and therefore don't require a separate firewall rule.
Exceptions are noted in the following table.
Load balancers based on the open source Envoy proxy require an ingress allow
firewall rule that permits traffic from the proxy-only subnet to reach the
backend instances. These load balancers terminate incoming connections and
traffic from the load balancer to the backends is then sent from IP addresses
in the proxy-only subnet.
The following table summarizes the minimum required firewall rules for each
type of load balancer.
Load balancer type
Minimum required ingress allow firewall rules
Overview
Example
Global external Application Load Balancer
Health check ranges:
35.191.0.0/16
130.211.0.0/22
For IPv6 traffic to the backends:
2600:2d00:1:b029::/64
2600:2d00:1:1::/64
GFE proxy ranges:
Same as health check ranges if the backends are instance
groups, zonal NEGs
(GCE_VM_IP_PORT), or hybrid connectivity NEGs
(NON_GCP_PRIVATE_IP_PORT)
IP address ranges listed in the _cloud-eoips.googleusercontent.com
DNS TXT record. You can extract the source IP addresses for global
internet NEG backends using the following example command on a
Linux system:
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Same as health check ranges if the backends are instance
groups, zonal NEGs
(GCE_VM_IP_PORT), or hybrid connectivity NEGs
(NON_GCP_PRIVATE_IP_PORT)
IP address ranges listed in the _cloud-eoips.googleusercontent.com
DNS TXT record. You can extract the source IP addresses for global
internet NEG backends using the following example command on a
Linux system:
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
External source IP addresses of clients on the internet.
For example, 0.0.0.0/0 (all IPv4 clients) or
::/0 (all IPv6 clients) or a
specific set of IP address ranges.
Target pool-based load balancers might proxy health checks
through the metadata server. In this case, health check probes
sources match the IP address of the metadata server:
169.254.169.254. However, traffic from the metadata
server is always allowed to reach VMs. No firewall rule is
required.
1
Allowing traffic from Google's health check probe ranges isn't required for hybrid
NEGs. However, if you're using a combination of hybrid and zonal NEGs in
a single backend service, you need to allow traffic from the Google
health check probe ranges for the zonal NEGs.
2
For regional internet NEGs, health checks are optional. Traffic from load
balancers using regional internet NEGs originates from the proxy-only subnet and is then
NAT-translated (by using Cloud NAT) to either manually or automatically allocated
NAT IP addresses. This traffic includes both health check probes and user
requests from the load balancer to the backends. For details, see Regional NEGs:
Use a Cloud NAT gateway.
[[["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-09-04 UTC."],[],[],null,["# Firewall rules\n\nGoogle Cloud load balancers typically require one or more firewall rules\nto ensure that traffic from clients reaches the backends.\n\n- Most load balancers are required to specify a health check for backend\n instances. For the health check probes to reach your backends, you must create\n an ingress allow [firewall rule](/firewall/docs/using-firewalls) that allows\n health check probes to reach your backend instances.\n\n- Load balancers based on Google Front Ends (GFEs) require an ingress allow\n firewall rule that permits traffic from the GFE proxy to reach the backend\n instances. In most cases, GFE proxies use the same source IP ranges as the\n health check probes and therefore don't require a separate firewall rule.\n Exceptions are noted in the following table.\n\n- Load balancers based on the open source Envoy proxy require an ingress allow\n firewall rule that permits traffic from the *proxy-only subnet* to reach the\n backend instances. These load balancers terminate incoming connections and\n traffic from the load balancer to the backends is then sent from IP addresses\n in the proxy-only subnet.\n\nThe following table summarizes the minimum required firewall rules for each\ntype of load balancer.\n\n^1^\nAllowing traffic from Google's health check probe ranges isn't required for hybrid\nNEGs. However, if you're using a combination of hybrid and zonal NEGs in\na single backend service, you need to allow traffic from the [Google\nhealth check probe ranges](/load-balancing/docs/health-check-concepts#ip-ranges) for the zonal NEGs.\n\n^2^\nFor regional internet NEGs, health checks are optional. Traffic from load\nbalancers using *regional* internet NEGs originates from the [proxy-only subnet](/load-balancing/docs/proxy-only-subnets) and is then\nNAT-translated (by using Cloud NAT) to either manually or automatically allocated\nNAT IP addresses. This traffic includes both health check probes and user\nrequests from the load balancer to the backends. For details, see [Regional NEGs:\nUse a Cloud NAT gateway](/load-balancing/docs/negs/internet-neg-concepts#nat-support)."]]
