Network contexts

Network contexts help you meet your security goals by using fewer firewall policy rules more efficiently. Cloud NGFW supports four network contexts that can be used to create a source combination or destination combination in a rule of a hierarchical firewall policy, global network firewall policy, or regional network firewall policy.

The following table shows how the four network contexts can be used in firewall rules.

Network contexts Supported target type Supported direction, source combination, or destination combination
INSTANCES INTERNAL_MANAGED_LB Source combination of an ingress rule Destination combination of an egress rule
Internet (INTERNET)
Non-internet (NON_INTERNET)
VPC networks (VPC_NETWORKS)
Intra-VPC (INTRA_VPC)

The internet and non-internet network contexts are mutually exclusive. The VPC networks and intra-VPC network contexts are subsets of the non-internet network context.

Internet network context

The internet network context (INTERNET) can be used as part of a source combination of an ingress rule or as part of a destination combination of an egress rule:

  • For an ingress rule, specify the internet context source and at least one other source parameter, except for a secure tag source. Packets match the ingress rule if they match at least one of the other source parameters and internet network context criteria for ingress packets.

  • For an egress rule, specify the internet context destination and at least one other destination parameter. Packets match the egress rule if they match at least one of the other destination parameters and internet network context criteria for egress packets.

Criteria for internet network context

This section describes the criteria that Cloud Next Generation Firewall uses to determine whether a packet belongs to the internet network context.

Internet network context for ingress packets

Ingress packets routed to a virtual machine (VM) network interface by a Google Maglev belong to the internet network context. Packets are routed by a Maglev to a VM network interface when the packet destination matches one of the following:

  • A regional external IPv4 address of a VM network interface, forwarding rule of an external passthrough Network Load Balancer, or forwarding rule for external protocol forwarding.
  • A regional external IPv6 address of a VM network interface, forwarding rule of an external passthrough Network Load Balancer, or forwarding rule for external protocol forwarding, and the packet was not routed using a local subnet route or a subnet route that was imported by VPC Network Peering or from a VPC spoke on a NCC hub.

For more information about packets routed by Maglev to backend VMs for an external passthrough Network Load Balancer or external protocol forwarding, see Paths for external passthrough Network Load Balancers and external protocol forwarding.

Internet network context for egress packets

Most egress packets sent from VM network interfaces, routed by a static route whose next hop is the default internet gateway, belong to the internet network context. However, if the destination IP addresses of these egress packets are for global Google APIs and services, these packets belong to the non-internet network context. For more information about connectivity to global Google APIs and services, see Non-internet network context.

When the packets are routed using a static route whose next hop is the default internet gateway, any packets sent by the VM network interfaces to the following destinations belong to the internet network context:

  • An external IP address destination outside of Google's network.
  • A regional external IPv4 address destination of a VM network interface, forwarding rule of a regional external load balancer, or forwarding rule for external protocol forwarding.
  • A regional external IPv6 address destination of a VM network interface, forwarding rule of a regional external load balancer, or forwarding rule for external protocol forwarding.
  • A global external IPv4 and IPv6 address destination of a forwarding rule of a global external load balancer.

Packets sent by the VM network interfaces to Cloud VPN and Cloud NAT gateways belong to the internet network context:

  • Egress packets sent from a network interface of a VM running Cloud VPN software to a Cloud VPN gateway's regional external IPv4 address belong to the internet network context.
  • Egress packets sent from one Cloud VPN gateway to another Cloud VPN gateway don't belong to any network context because firewall rules don't apply to Cloud VPN gateways.
  • For Public NAT, response packets sent from a VM network interface to a Cloud NAT gateway's regional external IPv4 address belong to the internet network context.

If VPC networks are connected using VPC Network Peering or if VPC networks participate as VPC spokes on the same NCC hub, IPv6 subnet routes can provide connectivity to regional external IPv6 address destinations of VM network interfaces, regional external load balancer forwarding rules, and external protocol forwarding rules. When the connectivity to those regional external IPv6 address destinations is provided using a subnet route, the destinations are in the non-internet network context instead.

Non-internet network context

The non-internet network context (NON-INTERNET) can be used as part of a source combination of an ingress rule or as part of a destination combination of an egress rule:

  • For an ingress rule, specify the non-internet context source and at least one other source parameter, except for a secure geolocations or source Google Threat Intelligence list. Packets match the ingress rule if they match at least one of the other source parameters and non-internet network context criteria for ingress packets.

  • For an egress rule, specify the non-internet context destination and at least one other destination parameter. Packets match the egress rule if they match at least one of the other destination parameters and non-internet network context criteria for egress packets.

Criteria for non-internet network context

This section describes the criteria that Cloud NGFW uses to determine whether a packet belongs to the non-internet network context.

Non-internet network context for ingress packets

Ingress packets belong to the non-internet network context if the packets are routed to the network interface of a VM instance or to an internal load balancer forwarding rule in one of the following ways:

  • The packets are routed by using a subnet route, and the packet destinations match one of the following:
    • A regional internal IPv4 or IPv6 address destination of a VM network interface, forwarding rule of an internal load balancer, or forwarding rule for internal protocol forwarding.
    • A regional external IPv6 address destination of a VM network interface, forwarding rule of a regional external load balancer, or forwarding rule for external protocol forwarding.
  • The packets are routed by using a static route to a next hop VM instance or next hop internal passthrough Network Load Balancer.
  • The packets are routed by using a policy-based route to a next hop internal passthrough Network Load Balancer.
  • The packets are routed by using one of the following special routing paths:

Ingress response packets from global Google APIs and services also belong to the non-internet network context. Response packets from global Google APIs and services can have any of the following sources:

Non-internet network context for egress packets

Egress packets sent from VM network interfaces belong to the non-internet network context if the packets are routed in one of the following ways:

VPC networks context

The VPC networks network context (VPC_NETWORKS) can only be used as part of a source combination of an ingress rule. To use the VPC networks context as part of a source combination of an ingress rule, do the following:

  1. You must specify a list of source VPC networks:

    • The source network list must contain at least one VPC network. You can add a maximum of 250 VPC networks to the source network list.
    • A VPC network must exist before you can add it to the source network list.
    • You can add the network by using either its partial or full URL identifier.
    • VPC networks that you add to the source network list don't need to be connected to each other. Each VPC network can be located in any project.
    • If a VPC network is deleted after it is added to the source network list, the reference to the deleted network remains in the list. Cloud NGFW ignores deleted VPC networks when enforcing an ingress rule. If all VPC networks in the source network list are deleted, ingress rules that rely on the list are ineffective because they don't match any packets.

  2. You must specify at least one other source parameter, except for a Google Threat Intelligence list source or geolocation source.

Packets match the ingress rule if they match at least one of the other source parameters and criteria for VPC networks context.

Criteria for VPC networks context

This section describes the criteria that Cloud NGFW uses to determine whether a packet belongs to the VPC networks context.

A packet matches an ingress rule that uses the VPC networks context in its source combination if all of the following conditions are true:

  • The packet matches at least one of the other source parameters.

  • The packet is sent by a resource located in one of the source VPC networks.

  • The source VPC network and the VPC network to which the firewall policy containing the ingress rule applies are the same VPC network, or are connected either by using VPC Network Peering or as VPC spokes on a Network Connectivity Center hub.

The following resources are located in a VPC network:

  • VM network interfaces
  • Cloud VPN tunnels
  • Cloud Interconnect VLAN attachments
  • Router appliances
  • Envoy proxies in a proxy-only subnet
  • Private Service Connect endpoints
  • Serverless VPC Access connectors

Intra-VPC network context

The intra-VPC networks network context (INTRA_VPC) can only be used as part of a source combination of an ingress rule. To use the intra-VPC networks context as part of a source combination of an ingress rule, you must specify at least one other source parameter, except for a Google Threat Intelligence list source or geolocation source.

Packets match the ingress rule if they match at least one of the other source parameters and criteria for intra-VPC networks context.

Criteria for intra-VPC network context

This section describes the criteria that Cloud NGFW uses to determine whether a packet belongs to the intra-VPC network context.

A packet matches an ingress rule that uses the intra-VPC context in its source combination if all of the following conditions are true:

  • The packet matches at least one of the other source parameters.

  • The packet is sent by a resource located in the VPC network to which the firewall policy containing the ingress rule applies.

The following resources are located in a VPC network:

  • VM network interfaces
  • Cloud VPN tunnels
  • Cloud Interconnect VLAN attachments
  • Router appliances
  • Envoy proxies in a proxy-only subnet
  • Private Service Connect endpoints
  • Serverless VPC Access connectors