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 Virtual Private Cloud (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 with the target type set to either INSTANCES or unspecified:

  • 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 a regional 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 a regional 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 a 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

When a static route with the default internet gateway next hop routes egress packets from a VM network interface, the destination IP address determines the network context, as listed in the following table:

Destination IP address of egress packet Network contexts
External IP addresses outside of Google's network Internet network context
External IP address of global Google APIs and services, including request packets sent to Cloud Run or App Engine services Non-internet network context
Regional external IPv4 address of a VM network interface, forwarding rule of a regional external Application Load Balancer, regional external proxy Network Load Balancer, regional external passthrough Network Load Balancer, or external protocol forwarding Internet network context
Regional external IPv6 address of a VM network interface, forwarding rule of a regional external Application Load Balancer, regional external proxy Network Load Balancer, regional external passthrough Network Load Balancer, or external protocol forwarding Internet network context, except when subnet routes route egress packets to external IPv6 destinations
Global external IPv4 or IPv6 address of a forwarding rule of a global external Application Load Balancer, global external proxy Network Load Balancer, or global external passthrough Network Load Balancer Internet network context
Regional external IPv4 address of a Cloud VPN gateway Internet network context
Regional external IPv4 address of a Cloud NAT gateway Internet network context
Egress packets to external IPv6 destinations routed by subnet routes

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 an IPv6 subnet route provides the path for egress traffic from a VM network interface to these regional external IPv6 address destinations, the traffic belongs to the non-internet network context instead.

Non-internet network context

You can use the non-internet network context (NON-INTERNET) as part of a source combination of an ingress rule or as part of a destination combination of an egress rule with the target type set to either INSTANCES or unspecified:

  • For an ingress rule, specify the non-internet context source and 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 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 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 passthrough Network Load Balancer, or forwarding rule for internal protocol forwarding.
    • A regional external IPv6 address destination of a VM network interface, forwarding rule of an external passthrough Network 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, and traffic among them belongs to the VPC networks network context.

  • 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

Additionally, packets that enter a VPC network through direct VPC egress also belong to the VPC networks network context.

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, and traffic between them belongs to the intra-VPC network context:

  • 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

Additionally, packets that enter a VPC network through direct VPC egress also belong to the intra-VPC network context.