Setting Up SSL proxy for Google Cloud Load Balancing

Google Cloud SSL proxy terminates user SSL (TLS) connections at the global load balancing layer, then balances the connections across your instances via SSL or TCP. Cloud SSL proxy is intended for non-HTTP(S) traffic. For HTTP(S) traffic, HTTP(S) load balancing is recommended instead.

Overview

With SSL (TLS) proxying for your SSL traffic, you can terminate your customers’ SSL sessions at the global load balancing layer, then forward the traffic to your virtual machine instances using SSL (recommended) or TCP.

SSL proxy is a global load balancing service. You can deploy your instances in multiple regions, and the load balancer automatically directs traffic to the closest region that has capacity. If the closest region is at capacity, the load balancer automatically directs new connections to another region with available capacity. Existing user connections remain in the current region.

We recommend use of end-to-end encryption for your SSL proxy deployment. To do this, configure your backend service to accept traffic over SSL. This ensures that the client traffic decrypted at the SSL proxy layer is encrypted again before being sent to the backend instances. This end-to-end encryption requires you to provision certificates and keys on your instances so they can perform SSL processing.

SSL proxy advantages:

  • Intelligent routing — the load balancer can route requests to backend locations where there is capacity. In contrast, an L3/L4 load balancer must route to regional backends without paying attention to capacity. Use of smarter routing allows provisioning at N+1 or N+2 instead of x*N.
  • Better utilization of the virtual machine instances — SSL processing can be very CPU intensive if the ciphers used are not CPU efficient. In order to maximize CPU performance, use ECDSA SSL certs, TLS1.2 and prefer the ECDHE-ECDSA-AES128-GCM-SHA256 cipher suite for SSL between the load balancer and your instances.
  • Certificate management — You only need to update your customer-facing certificate in one place when you need to switch certs. You can also reduce the management overhead for your virtual machine instances by using self-signed certificates on your instances.
  • Security patching — If vulnerabilities arise in the SSL or TCP stack, we will apply patches at the load balancer automatically in order to keep your instances safe.
  • SSL proxy supports the following ports: 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995

Notes:

  • While choosing to send the traffic over unencrypted TCP between the global load balancing layer and instances enables you to offload SSL processing from your instances, it also comes with reduced security between your global load balancing layer and instances and is therefore not recommended.
  • SSL proxy can handle HTTPS, but this is not recommended. You should instead use HTTP(S) load balancing for HTTPS traffic. See the FAQ for details.

We now describe how SSL proxy works and walk you through configuring an SSL proxy for load balancing traffic to some instances.

Google Cloud Load Balancing with SSL proxy

With SSL proxy at the global load balancing layer, SSL connections are terminated at the global layer then proxied to the closest available instance group.

In this example, traffic from users in Iowa and Boston is terminated at the global load balancing layer, and a separate connection is established to the selected backend instance.

Google Cloud Load Balancing with SSL termination (click to enlarge)
Google Cloud Load Balancing with SSL termination (click to enlarge)

Setting up SSL load balancing

This example demonstrates setting up global SSL load balancing for a simple service that exists in two regions: us-central1 and us-east1. We will configure the following:

  1. Four instances spread across two regions
  2. Instance groups for holding the instances
  3. Backend components, which include the following:
    • health check - used to monitor instance health
    • backend service - monitors instance groups and prevents them from exceeding configured usage
    • backends - hold the instance groups
  4. Frontend components, which include the following:
    • An SSL certificate resource
    • The SSL proxy itself with its SSL certificate
    • A public static IP address and a forwarding rule that sends user traffic to the proxy
  5. A firewall rule that allows traffic from the load balancer and health checker to the instances.

After that, we'll test our configuration.

Configure instances and instance groups

This section shows how to create instances and instance groups, then add the instances to the instance groups. A production system would normally use managed instance groups based on instance templates, but this setup is quicker for initial testing.

Create instances

For testing purposes, let's install Apache on four instances, two in each of two instance groups. Normally, you wouldn't use SSL load balancing for HTTP traffic, but Apache is commonly used and is easy to set up for testing.

These instance are all being created with a tag of ssl-lb. This tag is used later by the firewall rule.

Console


Create instances

  1. Go to the VM instances page in the Google Cloud Platform Console.
    Go to the VM instances page
  2. Click Create instance.
  3. Set Name to ig-us-central1-1.
  4. Set the Zone to us-central1-b.
  5. Click Management, disk, networking, SSH keys to reveal advanced settings.
  6. Under Management, populate the Tags field with ssl-lb.
  7. Set the Startup script to
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-1</h1></body></html>' | sudo tee /var/www/html/index.html
  8. Leave the default values for rest of the fields.
  9. Click Create.
  10. Create ig-us-central1-2 with the same settings, except with Startup script set to
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-2</h1></body></html>' | sudo tee /var/www/html/index.html
  11. Create ig-us-east1-1 with the same settings, except with Zone set to us-east1-b and Startup script set to
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-east1-1</h1></body></html>' | sudo tee /var/www/html/index.html
  12. Create ig-us-east1-2 with the same settings, except with Zone set to us-east1-b and Startup script set to
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-east1-2</h1></body></html>' | sudo tee /var/www/html/index.html

gcloud


  1. Create ig-us-central1-1 in zone us-central1-b

    gcloud compute instances create ig-us-central1-1 \
        --image-family debian-8 \
        --image-project debian-cloud \
        --tags ssl-lb \
        --zone us-central1-b \
        --metadata startup-script="#! /bin/bash
          sudo apt-get update
          sudo apt-get install apache2 -y
          sudo a2ensite default-ssl
          sudo a2enmod ssl
          sudo service apache2 restart
          echo '<!doctype html><html><body><h1>SSL load balanced instance - US central 1</h1></body></html>' | tee /var/www/html/index.html
          EOF"
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/ig-us-central1-1].
    NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-central1-1 us-central1-b n1-standard-1             10.240.0.8  23.251.150.133 RUNNING

  2. Create ig-us-central1-2 in zone us-central1-b

    gcloud compute instances create ig-us-central1-2 \
        --image-family debian-8 \
        --image-project debian-cloud \
        --tags ssl-lb \
        --zone us-central1-b \
         --metadata startup-script="#! /bin/bash
          sudo apt-get update
          sudo apt-get install apache2 -y
          sudo a2ensite default-ssl
          sudo a2enmod ssl
          sudo service apache2 restart
           echo '<!doctype html><html><body><h1>SSL load balanced instance - US central 2</h1></body></html>' | tee /var/www/html/index.html
           EOF"
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/ig-us-central1-2].
    NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-central1-2 us-central1-b n1-standard-1             10.240.0.11 23.251.148.160 RUNNING

  3. Create ig-us-east1-1 in zone us-east1-b

    gcloud compute instances create ig-us-east1-1 \
        --image-family debian-8 \
        --image-project debian-cloud \
        --tags ssl-lb \
        --zone us-east1-b \
        --metadata startup-script="#! /bin/bash
          sudo apt-get update
          sudo apt-get install apache2 -y
          sudo a2ensite default-ssl
          sudo a2enmod ssl
          sudo service apache2 restart
          echo '<!doctype html><html><body><h1>SSL load balanced instance - US east 1</h1></body></html>' | tee /var/www/html/index.html
          EOF"
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instances/ig-us-east1-1].
    NAME          ZONE       MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-east1-1 us-east1-b n1-standard-1             10.240.0.12 104.196.31.214 RUNNING

  4. Create ig-us-east1-2 in zone us-east1-b

    gcloud compute instances create ig-us-east1-2 \
        --image-family debian-8 \
        --image-project debian-cloud \
        --tags ssl-lb \
        --zone us-east1-b \
        --metadata startup-script="#! /bin/bash
          sudo apt-get update
          sudo apt-get install apache2 -y
          sudo a2ensite default-ssl
          sudo a2enmod ssl
          sudo service apache2 restart
          echo '<!doctype html><html><body><h1>SSL load balanced instance - US east 2</h1></body></html>' | tee /var/www/html/index.html
          EOF"
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instances/ig-us-east1-2].
    NAME          ZONE       MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-east1-2 us-east1-b n1-standard-1             10.240.0.13 104.196.25.101 RUNNING

Create an instance group for each zone and add instances

Console


  1. Go to the Instance groups page in the Google Cloud Platform Console.
    Go to the Instance groups page
  2. Click Create instance group.
  3. Set the Name to us-ig1.
  4. Set the Zone to us-central1-b.
  5. Click Specify port name mapping.
    1. Under Port name mapping, click Add item.
    2. Enter a Port name of ssl-lb and Port numbers of 443.
  6. Under Instance definition, click Select existing instances.
  7. From VM instances select ig-us-central1-1 and ig-us-central1-2.
  8. Leave other settings as they are.
  9. Click Create.
  10. Repeat steps, but set the following:
    • Name: us-ig2
    • Zone: us-east1-b
    • Port name of ssl-lb and Port numbers of 443
    • Instances: ig-us-east1-1 and ig-us-east1-2.
  11. Confirm that you now have two instance groups, each with two instances.

gcloud


  1. Create the us-ig1 instance group.

    gcloud compute instance-groups unmanaged create us-ig1 --zone us-central1-b
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instanceGroups/us-ig1].
    NAME   ZONE          NETWORK MANAGED INSTANCES
    us-ig1 us-central1-b                 0

  2. Set a named port for the instance group.

    gcloud compute instance-groups set-named-ports us-ig1 \
        --named-ports ssl-lb:443 \
        --zone us-central1-b
    

  3. Add ig-us-central1-1 and ig-us-central1-2 to us-ig1

    gcloud compute instance-groups unmanaged add-instances us-ig1 \
        --instances ig-us-central1-1,ig-us-central1-2 \
        --zone us-central1-b
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instanceGroups/us-ig1].

  4. Create the us-ig2 instance group.

    gcloud compute instance-groups unmanaged create us-ig2 --zone us-east1-b
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instanceGroups/us-ig2].
    NAME   ZONE       NETWORK MANAGED INSTANCES
    us-ig2 us-east1-b                 0

  5. Set a named port for the instance group.

    gcloud compute instance-groups set-named-ports us-ig2 \
        --named-ports ssl-lb:443 \
        --zone us-central1-b
    

  6. Add ig-us-east1-1 and ig-us-east1-2 to us-ig2

    gcloud compute instance-groups unmanaged add-instances us-ig2 \
         --instances ig-us-east1-1,ig-us-east1-2 \
         --zone us-east1-b
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instanceGroups/us-ig2].

You now have an instance group in each of two regions, each with two instances.

Configure load balancer

Console


Create the load balancer and configure a backend service

  1. Go to the Load balancing page in the Google Cloud Platform Console.
    Go to the Load balancing page
  2. Click Create load balancer.
  3. Under TCP load balancing, click Start configuration.
  4. Under Internet facing or internal only select From Internet to my VMs.
  5. Under Connection termination select Yes (SSL Proxy).
  6. Click Continue.
  7. Set the Name to my-ssl-lb.
  8. Click Backend configuration.
  9. The Name of the backend service appears as my-ssl-lb.
  10. Set Protocol to SSL.
  11. Under New backend, select instance group us-ig1.
  12. Set Port numbers to 443.
  13. Leave other settings as they are.
  14. Click Add backend.
  15. Select instance group us-ig2.
  16. Set Port numbers to 443.
  17. Under Health check, select Create health check.
    1. Set the health check Name to my-ssl-health-check.
    2. Set Protocol to SSL.
    3. Leave the other settings the same.
    4. Click Save and continue.
  18. Verify that there is a green check mark next to Backend configuration in the Google Cloud Platform Console. If not, double-check that you have completed all the steps above.

Configure frontend services

  1. Click Frontend configuration.
  2. Under IP, select Create IP address.
    1. Enter a Name of ssl-lb-static-ip.
    2. Click Reserve.
  3. Under Certificate, select Create a new certificate.
    1. Enter a Name of my-ssl-cert.
    2. In the appropriate fields upload your
      • Public key certificate (.crt file)
      • Certificate chain (.csr file)
      • Private key (.key file).
    3. Turn on Proxy protocol if desired.
    4. Click Create.
  4. Verify that there is a green check mark next to Frontend configuration in the Google Cloud Platform Console. If not, double-check that you have completed all the steps above.

Review and finalize

  1. Click Review and finalize.
  2. Double-check your settings.
  3. Click Create.

gcloud


Create a health check

gcloud compute health-checks create ssl my-ssl-health-check --port 443

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks/my-ssl-health-check].
NAME                PROTOCOL
my-ssl-health-check SSL

Create a backend service

gcloud compute backend-services create my-ssl-lb \
    --protocol SSL \
    --health-checks my-ssl-health-check \
    --timeout 5m \
    --global

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/my-ssl-lb].
NAME      BACKENDS PROTOCOL
my-ssl-lb          SSL

Alternatively you could configure unencrypted communication between from the load balancer to the instances with --protocol TCP.

Add instance groups to your backend service

gcloud compute backend-services add-backend my-ssl-lb \
    --instance-group us-ig1 \
    --instance-group-zone us-central1-b \
    --balancing-mode UTILIZATION \
    --max-utilization 0.8 \
    --global

Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/my-ssl-lb].

gcloud compute backend-services add-backend my-ssl-lb \
    --instance-group us-ig2 \
    --instance-group-zone us-east1-b \
    --balancing-mode UTILIZATION \
    --max-utilization 0.8 \
    --global

Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/my-ssl-lb].

Reserve a global static IP address

This IP address is the one your customers will use to access your load balanced service.

gcloud compute addresses create ssl-lb-static-ip --global

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/addresses/ssl-lb-static-ip].
NAME                 REGION ADDRESS        STATUS
ssl-lb-static-ip     [LB_STATIC_IP]        RESERVED

Configure your SSL certificate resource

You must already have an SSL certificate to upload. If you do not, see SSL certificates.

gcloud compute ssl-certificates create my-ssl-cert \
    --certificate [CRT_FILE_PATH] \
    --private-key [KEY_FILE_PATH]

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/sslCertificates/ssl-cert1].
NAME      CREATION_TIMESTAMP
ssl-cert1 2016-02-20T20:53:33.584-08:00

Configure a target SSL proxy

If you want to turn on the proxy header, set it to PROXY_V1 instead of none.

gcloud compute target-ssl-proxies create my-ssl-lb-target-proxy \
    --backend-service my-ssl-lb \
    --ssl-certificate my-ssl-cert \
    --proxy-header NONE

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/targetSslProxies/my-ssl-lb-target-proxy].
NAME                   PROXY_HEADER SERVICE   SSL_CERTIFICATES
my-ssl-lb-target-proxy NONE         my-ssl-lb ssl-cert1

Configure a global forwarding rule

To create a global forwarding rule associated with the target proxy, replace [LB_STATIC_IP] with the IP address you generated in Reserve a global static IP address.

gcloud compute forwarding-rules create my-ssl-lb-forwarding-rule \
    --global \
    --target-ssl-proxy my-ssl-lb-target-proxy \
    --address [LB_STATIC_IP] \
    --port-range 443

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/forwardingRules/my-ssl-lb-forwarding-rule].
NAME                         REGION IP_ADDRESS     IP_PROTOCOL TARGET
my-ssl-lb-forwarding-rule           [LB_STATIC_IP] SSL         my-ssl-lb-target-proxy

Create a firewall rule for the SSL load balancer

Configure the firewall to allow traffic from the load balancer and health checker to the instances.

Console


  1. Go to the Firewall rules page in the Google Cloud Platform Console.
    Go to the Firewalls rules page
  2. Click Create firewall rule.
  3. Enter a Name of allow-ssl-lb-and-health.
  4. Select Network to be default.
  5. Set Source filter to IP ranges.
  6. Set Source IP ranges to 130.211.0.0/22 and 35.191.0.0/16.
  7. Set Allowed protocols and ports to tcp:443.
  8. Set Target tags to ssl-lb.
  9. Click Create.

gcloud


gcloud compute firewall-rules create allow-ssl-lb-and-health \
     --source-ranges 130.211.0.0/22,35.191.0.0/16 \
     --target-tags ssl-lb \
     --allow tcp:443

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-ssl-lb-and-health].
NAME                     NETWORK SRC_RANGES                  RULES   SRC_TAGS TARGET_TAGS
allow-ssl-lb-and-health default 130.211.0.0/22,35.191.0.0/16 tcp:443          ssl-lb

Test your load balancer

In your web browser, connect to your static IP address via HTTPS. In this test setup, the instances are using self-signed certificates. Therefore, you will see a warning in your browser the first time you access a page. Click through the warning to see the actual page.

https://[LB_STATIC_IP]

You should see one of the hosts from the region closest to you. Reload the page until you see the other instance in that region. To see instances from the other region, stop the instances in the closest region.

Alternatively, you can use curl from the your local machine's command line. If you are using a self-signed certificate on the SSL proxy, you must also specify -k.

curl -k https://[LB_STATIC_IP]

Additional SSL proxy commands

List target SSL proxies

Console


Go to the Target proxy list page in the Google Cloud Platform Console.
Go to the Target proxy list page

gcloud


gcloud compute target-ssl-proxies list

NAME                   PROXY_HEADER SERVICE   SSL_CERTIFICATES
my-ssl-lb-target-proxy NONE         my-ssl-lb ssl-cert1

Describe target SSL proxies

Console


  1. Go to the Target proxy list page in the Google Cloud Platform Console.
    Go to the Target proxy list page
  2. Click on the name of your target SSL proxy.

gcloud


gcloud compute target-ssl-proxies describe my-ssl-lb-target-proxy

creationTimestamp: '2016-02-20T20:55:17.633-08:00'
id: '9208913598676794842'
kind: compute#targetSslProxy
name: my-ssl-lb-target-proxy
proxyHeader: NONE
selfLink: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/targetSslProxies/my-ssl-lb-target-proxy
service: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/my-ssl-lb
sslCertificates:
- https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/sslCertificates/ssl-cert1

Delete target SSL proxy

To delete a target proxy, you must first delete any global forwarding rules that reference it.

Console


  1. Go to the Global forwarding rule list page in the Google Cloud Platform Console.
    Go to the Global forwarding rule list page
  2. Select the checkbox next to your global forwarding rule.
  3. Click Delete.
  4. Go to the Target proxy list page in the Google Cloud Platform Console.
    Go to the Target proxy list page
  5. Select the checkbox next to your target SSL proxy.
  6. Click Delete.

Alternatively, you can delete all load balancer components by doing the following:

  1. Go to the Load balancing page in the Google Cloud Platform Console.
    Go to the Load balancing page
  2. Click the trash can icon on the right side of the desired row.
  3. Click Delete load balancer to confirm.

gcloud


  1. Delete the global forwarding rule.

    gcloud compute forwarding-rules delete my-ssl-lb-forwarding-rule \
        --global
    

    The following global forwarding rules will be deleted:
     - [my-ssl-lb-forwarding-rule]

    Do you want to continue (Y/n)? y

    Deleted [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/forwardingRules/my-ssl-lb-forwarding-rule].

  2. Delete the SSL proxy.

    gcloud compute target-ssl-proxies delete my-ssl-lb-target-proxy
    

    The following target ssl proxies will be deleted:
     - [my-ssl-lb-target-proxy]

    Do you want to continue (Y/n)? y

    Deleted [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/targetSslProxies/my-ssl-lb-target-proxy].

Update a backend service for the target SSL proxy

You can use the update command to point your SSL proxy at a different backend service. In this example, we'll create a new backend service and point the proxy at it. Then, we will make an update and point the proxy back to the original backend service.

Console


Use the gcloud command-line tool for this step.

gcloud


  1. Create a second backend service using the same health check.

    gcloud compute backend-services create my-other-backend-service \
        --protocol SSL \
        --health-checks my-ssl-health-check \
        --global
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/my-other-backend-service].
    NAME                     BACKENDS PROTOCOL
    my-other-backend-service          SSL

  2. Point the SSL proxy at the new backend.

    gcloud compute target-ssl-proxies update my-ssl-lb-target-proxy \
        --backend-service my-other-backend-service
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/targetSslProxies/my-ssl-lb-target-proxy].

  3. This backend service has no instances, so if you try to use the proxy right now, you won't get your web pages. To continue testing the original configuration, point your SSL proxy back at the first backend service.

    gcloud compute target-ssl-proxies update my-ssl-lb-target-proxy \
        --backend-service my-ssl-lb
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/targetSslProxies/my-ssl-lb-target-proxy].

Update the SSL certificate resource for the target SSL proxy

Use this command to replace the SSL certificate on the SSL proxy. You must already have created the other SSL certificate resource.

Console


  1. Go to the Load balancing page in the Google Cloud Platform Console.
    Go to the Load balancing page
  2. Click Edit next to your load balancer.
  3. Click Frontend configuration.
  4. In the Certificate drop-down menu, select the new certificate.
  5. Click Update.

gcloud


gcloud compute target-ssl-proxies update my-ssl-lb-target-proxy \
    --ssl-certificate ssl-cert2

Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/targetSslProxies/my-ssl-lb-target-proxy].

Optional parameters

PROXY protocol for retaining client connection information

Google Cloud Load Balancing with SSL proxy terminates SSL connections from the client and creates new connections to the instances, hence the original client IP and port information is not preserved by default.

If you would like to preserve and send this information to your instances, then you will need to enable PROXY protocol (version 1) where an additional header containing the original connection information including source IP address, destination IP address, and port numbers is added and sent to the instance as a part of the request.

You can also set this parameter for TCP and SSL health checks.

The PROXY protocol header will typically be a single line of user-readable text with the following format:

PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n

An example of the PROXY protocol is show below:

PROXY TCP4 192.0.2.1 198.51.100.1 15221 443\r\n

Where client IP is 192.0.2.1, load balancing IP is 198.51.100.1, client port is 15221 and the destination port is 443.

In cases where the client IP is not known, the load balancer will generate a PROXY protocol header in the following format:

PROXY UNKNOWN\r\n

Update PROXY protocol header for the proxy

Use this command to change the PROXY protocol header for an existing target SSL proxy.

Console


  1. Go to the Load balancing page in the Google Cloud Platform Console.
    Go to the Load balancing page
  2. Click Edit for your load balancer.
  3. Click Frontend configuration.
  4. Change the value of the Proxy protocol field.
  5. Click Update to save your changes.

gcloud


gcloud compute target-ssl-proxies update my-ssl-lb-target-proxy \
    --proxy-header [NONE | PROXY_V1]

Connection draining

You can enable connection draining on backend services to ensure minimal interruption to your users when an instance that is serving traffic is terminated, removed manually, or removed by an autoscaler. To learn more about connection draining, read the Enabling Connection Draining documentation.

Load balancer components

Health checking

Health checks determine which instances can receive new connections. You can configure a TCP, SSL, HTTP, or HTTPS health check for determining the health of your instances.

  • If the service running on your backend instances is based on HTTP, use an HTTP health check
  • If the service running on your backend instances is based on HTTPS, use an HTTPS health check
  • If the service running on your backend instances uses SSL, use an SSL health check
  • Unless you have an explicit reason to use a different kind of health check, use a TCP health check

Health check firewall rules

Health check probes to your load balanced instances come from addresses in the ranges 130.211.0.0/22 and 35.191.0.0/16. Your firewall rules must allow these connections on the relevant port.

The section Create a firewall rule for the SSL load balancer covers this step.

See the Health Checks page for details on health checks.

Backend service

A backend service defines the capacity, max utilization, and health check of the instance groups it contains.

  • Backend services direct incoming traffic to one or more attached backends (depending on the load balancing mode, discussed later). Each backend consists of an instance group and additional configuration to balance traffic among the instances in the instance group. Each instance group is composed of one or more instances.
  • Each backend service also specifies which health checks will be performed for the instances in an all the instance groups added to the backend service.
  • The duration of idle SSL proxy connections through the load balancer is limited by the backend service timeout.

When you configure a backend service, you must add instance groups and specify a balancing mode that determines how much traffic the load balancer can send to instances in each instance group. Once the limit is reached for a particular instance group, additional requests are sent to an instance group that is next closest to the user, as long as it has capacity.

SSL proxy supports the following balancing modes:

  • UTILIZATION (default): instances can accept traffic as long as the average current CPU utilization of the instance group is below a specified value. To set this value, use the --max-utilization parameter and pass a value between 0.0 (0%) and 1.0 (100%). Default is 0.8 (80%).
  • CONNECTION: instances can accept traffic as long as the number of connections is below a specified value. This value can be one of the following:
    • --max-connections: the maximum number of connections across all of the backend instances in the instance group.
    • --max-connections-per-instance: the maximum number of connections a single instance can handle. Requests are forwarded as long as the average for the group does not exceed this number.

You can specify a --max-connections or --max-connections-per-instance even if you set balancing mode to UTILIZATION. If both --max-utilization and a connection parameter are specified, the group is considered at full utilization when either limit is reached.

SSL certificate and key

If you don’t have a private key and signed certificate, you can create and use a self-signed certificate for testing purposes, or get real certificate from an authority. See SSL Certificates for further information. You should not use a self-signed certificate on the load balancer for production purposes.

See SSL Certificates for more information.

Global forwarding rule

Create a global forwarding rule to forward specific IPs and ports to the target SSL proxy. When customer traffic arrives at your external IP address, this forwarding rule tells the network to send that traffic to your SSL proxy.

See Global forwarding rules for more information.

Recommendations

  • You should configure the load balancer to prepend a PROXY protocol version 1 header if you need to retain the client connection information.
  • If your traffic is HTTPS, then you should use HTTPS Load Balancing and not SSL proxy for load balancing.

Troubleshooting

Pages fail to load from load balancer IP

Verify the health of instances

Verify that the instances are HEALTHY.

gcloud compute backend-services get-health my-ssl-lb
---
backend: https://www.googleapis.com/resourceviews/v1/projects/[PROJECT_ID]/zones/us-central1-b/resourceViews/us-ig1
status:
  kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instanceGroups/us-ig2
status:
  kind: compute#backendServiceGroupHealth

Confirm that your firewall rule is correct

  • Both the health checker and the load balancer need 130.211.0.0/22 and ,35.191.0.0/16 to be open
  • If you are doing SSL between the load balancer and the instances, you should do an SSL health check. In that case, tcp:443 must be allowed by the firewall from 130.211.0.0/22 and 35.191.0.0/16. If you are doing TCP to the instances, do a TCP health check and open tcp:80 from 130.211.0.0/22 and 35.191.0.0/16 instead.
  • If you are leveraging instance tags, make sure the tag is listed as under TARGET_TAGS in the firewall rule, and make sure all your instances have that tag. In this example, instances are tagged with ssl-lb.
gcloud compute firewall-rules list
NAME                      NETWORK SRC_RANGES                  RULES                        SRC_TAGS TARGET_TAGS
allow-ssl-lb-and-health  default 130.211.0.0/22,35.191.0.0/16 tcp:443                               ssl-lb

Try to reach individual instances

Temporarily set a firewall rule that allows you to access your instances individually, then try to load a page from a specific instance.

  1. Open the firewall to allow traffic from any source to the tagged instances.

    gcloud compute firewall-rules create allow-ssl-0-0-0-0   \
        --source-ranges 0.0.0.0/0   \
        --target-tags ssl-lb    \
        --allow tcp:443
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-ssl-0-0-0-0].
    NAME              NETWORK SRC_RANGES RULES   SRC_TAGS TARGET_TAGS
    allow-ssl-0-0-0-0 default 0.0.0.0/0  tcp:443          ssl-lb

  2. Look up the EXTERNAL_IP address of one of the instances.

    gcloud compute instances list
    

    NAME             ZONE           MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-central1-1 us-central1-b  n1-standard-1             10.240.0.8  EXTERNAL_IP RUNNING
    ig-us-central1-2 us-central1-b  n1-standard-1             10.240.0.11 EXTERNAL_IP RUNNING
    ig-us-east1-1    us-east1-b     n1-standard-1             10.240.0.12 EXTERNAL_IP RUNNING
    ig-us-east1-2    us-east1-b     n1-standard-1             10.240.0.13 EXTERNAL_IP RUNNING

  3. Then access one or more of your instances directly from your browser.

    https://[EXTERNAL_IP]
    
  4. If your instances are not accessible by this method, make sure that your software is running correctly. If it is, make sure your load balancer firewall rule is correct.

    gcloud compute firewall-rules describe allow-ssl-lb-and-health
    

    allowed:
    - IPProtocol: tcp
      ports:
      - '443'
    creationTimestamp: '2016-02-20T22:27:15.094-08:00'
    description: ''
    id: '5304629236729177644'
    kind: compute#firewall
    name: allow-130-211-0-0-22-ssl
    network: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default
    selfLink: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-ssl-lb-and-health
    sourceRanges:
    - 130.211.0.0/22,35.191.0.0/16
    targetTags:
    - ssl-lb

  5. When you're sure the instances are working, remove the "from anywhere" firewall rule.

    gcloud compute firewall-rules delete allow-ssl-0-0-0-0
    

    The following firewalls will be deleted:
     - [allow-ssl-0-0-0-0]

    Do you want to continue (Y/n)? y

    Deleted [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-ssl-0-0-0-0].

FAQ

When should I use HTTPS load balancing instead of SSL proxy load balancing?

Though SSL proxy can handle HTTPS traffic, HTTPS Load Balancing has additional features that make it a better choice in most cases.

HTTPS load balancing has the following additional functionality:

  • Negotiates HTTP/2 and SPDY/3.1
  • Rejects invalid HTTP requests or responses
  • Forwards requests to different instance groups based on URL host and path
  • Integrates with Cloud CDN.
  • Spreads the request load more evenly among instances, providing better instance utilization. HTTPS load balances each request separately, whereas SSL proxy sends all bytes from the same SSL or TCP connection to the same instance.

SSL proxy for Google Cloud Load Balancing can be used for other protocols that use SSL, such as Websockets and IMAP over SSL.

Can I view the original IP address of the connection to the global load balancing layer?

Yes. You can configure the load balancer to prepend a PROXY protocol version 1 header to retain the original connection information. See Update proxy protocol header for the proxy for details.

Send feedback about...

Compute Engine Documentation