This page describes scenarios for accessing an internal load balancer in your Virtual Private Cloud (VPC) network from a connected network. Before reviewing the information on this page, you should already be familiar with the concepts in the following guide:
Use VPC Network Peering
When you use VPC Network Peering to connect your VPC network to another network, Google Cloud shares subnet routes between the networks. The subnet routes allow traffic from the peer network to reach internal load balancers in your network. Access is allowed if the following is true:
- You create ingress firewall rules to allow traffic from client VMs in the peer network. Google Cloud firewall rules aren't shared among networks when using VPC Network Peering.
- For regional internal Application Load Balancers, client virtual machine (VM) instances in the peer network must be located in the same region as your internal load balancer. This restriction is waived if you configure global access.
You cannot selectively share only some internal passthrough Network Load Balancers, regional internal proxy Network Load Balancers, or internal Application Load Balancers by using VPC Network Peering. All internal load balancers are shared automatically. You can limit access to the load balancer's backends by using ingress firewall rules applicable to the backend VM instances.
Use Cloud VPN and Cloud Interconnect
You can access an internal load balancer from a peer network that is connected through a Cloud VPN tunnel or VLAN attachment for a Dedicated Interconnect connection or Partner Interconnect. The peer network can be an on-premises network, another Google Cloud VPC network, or a virtual network hosted by a different cloud provider.
Access through Cloud VPN tunnels
You can access an internal load balancer through a Cloud VPN tunnel when all of the following conditions are met.
In the internal load balancer's network
- Both the Cloud VPN gateway and tunnel(s) must be located in the same region as the load balancer when global access is disabled. If global access is enabled on the load balancer's forwarding rule, this restriction is waived.
Routes must provide response paths from the load balancer's backends to the on-premises or peer network where the client is located. If you're using Cloud VPN tunnels with dynamic routing, consider the dynamic routing mode of the load balancer's Cloud VPN network. The dynamic routing mode determines which custom dynamic routes are available to the load balancer's backends.
You must configure ingress allow firewall rules with on-premises source IP address ranges so that on-premises clients can send packets to the load balancer. Targets for these firewall rules must include the backends of the load balancer. See Targets and IP addresses for details.
In the peer network
The peer network must have at least one Cloud VPN tunnel with routes to the subnet where the internal load balancer is defined.
If the peer network is another Google Cloud VPC network:
The peer network's Cloud VPN gateway and tunnel(s) can be located in any region.
For Cloud VPN tunnels that use dynamic routing, the dynamic routing mode of the VPC network determines which routes are available to clients in each region. To provide a consistent set of custom dynamic routes to clients in all regions, use global dynamic routing mode.
Ensure on-premises or peer network firewalls permit packets sent to the IP address of the load balancer's forwarding rule. Ensure on-premises or peer network firewalls permit response packets received from the IP address of the load balancer's forwarding rule.
The following diagram highlights key concepts when accessing an internal load balancer by way of a Cloud VPN gateway and its associated tunnel. Cloud VPN securely connects your on-premises network to your Google Cloud VPC network using Cloud VPN tunnels.
Note the following configuration elements associated with this example:
- In the
lb-network, a Cloud VPN tunnel that uses dynamic routing has been configured. The VPN tunnel, gateway, and Cloud Router are all located in REGION_A, the same region where the internal load balancer's components are located. - Ingress allow firewall rules have been configured to apply to the backend
VMs in the instance groups A and B so that they can
receive traffic from IP addresses in the VPC network and from
the on-premises network,
10.1.2.0/24and192.168.1.0/24. No egress deny firewall rules have been created, so the implied allow egress rule applies. - Packets sent from clients in the on-premises networks, including from
192.168.1.0/24, to the IP address of the internal load balancer,10.1.2.99, are delivered directly to a healthy backend VM, such asvm-a2, according to the configured session affinity. - Replies sent from the backend VMs (such as
vm-a2) are delivered through the VPN tunnel to the on-premises clients.
To troubleshoot Cloud VPN, see Cloud VPN troubleshooting.
Access through Cloud Interconnect
You can access an internal load balancer from an on-premises peer network that is connected to the load balancer's VPC network when all the following conditions are met in the internal load balancer's network:
Both the VLAN attachment and Cloud Router must be located in the same region as the load balancer when global access is disabled. If global access is enabled on the load balancer's forwarding rule, this restriction is waived.
On-premises routers must provide response paths from the load balancer's backends to the on-premises network. VLAN attachments for both Dedicated Interconnect and Partner Interconnect must use Cloud Routers; thus, custom dynamic routes provide response paths. The set of custom dynamic routes they learn depends on the dynamic routing mode of the load balancer's network.
Ensure on-premises firewalls permit packets sent to the IP address of the load balancer's forwarding rule. Ensure on-premises firewalls permit response packets received from the IP address of the load balancer's forwarding rule.
- You must configure ingress allow firewall rules with on-premises source IP address ranges so that on-premises clients can send packets to the load balancer. Targets for these firewall rules must be the backends of the load balancer. See Targets and IP addresses for details.
Use global access with Cloud VPN and Cloud Interconnect
By default, clients must be in the same network or in a VPC network connected by using VPC Network Peering. You can enable global access to allow clients from any region to access your load balancer.
When you enable global access, the following resources can be located in any region:- Cloud Routers
- Cloud VPN gateways and tunnels
- VLAN attachments
In the diagram:
- The load balancer's frontend and backends are in the
REGION_Aregion. - The Cloud Router is in the
REGION_Bregion. - The Cloud Router peers with the on-premises VPN router.
- The Border Gateway Protocol (BGP) peering session can be through Cloud VPN or Cloud Interconnect with Direct Peering or Partner Interconnect.
The VPC network's
dynamic routing mode is set to
global to enable the Cloud Router in REGION_B to advertise the
subnet routes for subnets in any region of the load balancer's
VPC network.
Multiple egress paths
In production environments, you should use multiple Cloud VPN tunnels or VLAN attachments for redundancy. This section discusses requirements when using multiple tunnels or VLAN attachments.
In the following diagram, two Cloud VPN tunnels connect lb-network to
an on-premises network. Although Cloud VPN tunnels are used here, the
same principles apply to Cloud Interconnect.
You must configure each tunnel or each VLAN attachment in the same region as the internal load balancer. This requirement is waived if you enabled global access.
Multiple tunnels or VLAN attachments can provide additional bandwidth or can serve as standby paths for redundancy.
Keep in mind the following points:
- If the on-premises network has two routes with the same priorities, each
with a destination of
10.1.2.0/24and a next hop corresponding to a different VPN tunnel in the same region as the internal load balancer, traffic can be sent from the on-premises network (192.168.1.0/24) to the load balancer by using equal-cost multipath (ECMP). - After packets are delivered to the VPC network, the internal load balancer distributes them to backend VMs according to the configured session affinity.
- If the
lb-networkhas two routes, each with the destination192.168.1.0/24and a next hop corresponding to different VPN tunnels, responses from backend VMs can be delivered over each tunnel according to the priority of the routes in the network. If different route priorities are used, one tunnel can serve as a backup for the other. If the same priorities are used, responses are delivered by using ECMP. - Replies sent from the backend VMs (such as
vm-a2) are delivered directly to the on-premises clients through the appropriate tunnel. From the perspective oflb-network, if routes or VPN tunnels change, traffic might egress by using a different tunnel. This might result in TCP session resets if an in-progress connection is interrupted.
What's next
- To configure and test an internal passthrough Network Load Balancer, Set up an internal passthrough Network Load Balancer.