A Network Security Integration In-band (NSI in-band) is a regional load balancer that distributes traffic among internal virtual machine (VM) instances in the same region in a Virtual Private Cloud (VPC) network. It enables you to run and scale your services behind an internal IP address that is accessible only to systems in the same VPC network or systems connected to your VPC network.
It can be used under the following circumstances:
When you need high-performance, pass-through Layer 4 load balancer for TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, and GRE protocols.
If serving traffic through TLS (SSL), it is acceptable to have SSL traffic terminated by your backends instead of by the load balancer. The NSI in-band cannot terminate SSL traffic.
To forward the original packets unproxied. For example, if you need the client source IP address to be preserved.
When you have an existing setup that uses a pass-through load balancer, and you want to migrate it without changes.
For more information, refer to the Network Security Integration In-band overview.
How does a Network Security Integration In-band work?
A NSI in-band has a frontend (the forwarding rule) and a backend (the backend service). You can use either instance groups or GCE_VM_IP zonal NEGs as backends on the backend service.
It doesn't terminate connections from clients and then open new connections to backends. Instead, an NSI in-band routes connections directly from clients to the healthy backends, without any interruption. Responses from the healthy backend VMs go directly to the clients, not back through the load balancer. TCP responses use direct server return. For more information, see TCP and UDP request and return packets.
The load balancer monitors backend health by using health check probes. The load balancer's backend service must be associated with a global or regional health check. Special routes outside of the VPC network facilitate communication between health check systems and the backends. You can use an existing health check or define a new one. The internal passthrough network load balancers use health check status to determine how to route new connections.
The Google Cloud Linux guest environment, Windows guest environment, or an equivalent process configures each backend VM with the IP address of the load balancer. For VMs created from Google Cloud images, the Guest agent (formerly, the Windows Guest Environment or Linux Guest Environment) installs the local route for the load balancer's IP address. Google Kubernetes Engine instances based on Container-Optimized OS implement this by using iptables instead.
.png "GCP_NSI-InBand.png")
An internal passthrough network load balancer doesn't support the following:
Backend VMs in multiple regions.
IPv4 packets with fragmented headers.