Console
    Contact Us Start free

    Firewall rules

    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
    Overview
    Example
    Classic Application Load Balancer
    • Health check ranges:
      • 35.191.0.0/16
      • 130.211.0.0/22
    • 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
    Overview
    Example
    Regional external Application Load Balancer
    • Health check ranges 1, 2 :
      • 35.191.0.0/16
      • 130.211.0.0/22
    • Proxy-only subnet 2
    Overview
    Example
    Cross-region internal Application Load Balancer
    • Health check ranges 1, 2 :
      • 35.191.0.0/16
      • 130.211.0.0/22
    • Proxy-only subnet 2
    Overview
    Example
    Regional internal Application Load Balancer
    • Health check ranges 1, 2 :
      • 35.191.0.0/16
      • 130.211.0.0/22
    • Proxy-only subnet 2
    Overview
    Example
    Global external proxy Network 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
    Overview
    Example
    Classic proxy Network Load Balancer
    • Health check ranges:
      • 35.191.0.0/16
      • 130.211.0.0/22
    • GFE proxy ranges: Same as health check ranges
    Overview
    Example
    Regional external proxy Network Load Balancer
    • Health check ranges 1, 2 :
      • 35.191.0.0/16
      • 130.211.0.0/22
    • Proxy-only subnet 2
    Overview
    Example
    Regional internal proxy Network Load Balancer
    • Health check ranges 1, 2 :
      • 35.191.0.0/16
      • 130.211.0.0/22
    • Proxy-only subnet 2
    Overview
    Example
    Cross-region internal proxy Network Load Balancer
    • Health check ranges 1, 2 :
      • 35.191.0.0/16
      • 130.211.0.0/22
    • Proxy-only subnet 2
    Overview
    Example
    External passthrough Network Load Balancer
    • Health check ranges

      For IPv4 traffic to the backends:

      • 35.191.0.0/16
      • 209.85.152.0/22
      • 209.85.204.0/22

      For IPv6 traffic to the backends:

      • 2600:1901:8001::/48

    • 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.

    Overview
    Examples
    Internal passthrough Network Load Balancer
    • Health check ranges:

      For IPv4 traffic to the backends:

      • 35.191.0.0/16
      • 130.211.0.0/22

      For IPv6 traffic to the backends:

      • 2600:2d00:1:b029::/64
    • Internal source IP addresses of clients
    Overview
    single-stack dual-stack

    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 .
    Create a Mobile Website
    View Site in Mobile | Classic
    Share by: