Whitelisting Google IPs for Looker Studio with MySQL and Other Data Connectors

4 min read

When connecting Looker Studio to a database protected by a firewall, the most common and immediate requirement is to allow traffic from Google’s infrastructure. For many administrators, IP whitelisting is the fastest way to get a working connection, particularly when dealing with self-hosted MySQL or legacy environments.

This article starts with the IP ranges commonly used in practice, explains how to apply them, and then outlines the known limitations and alternative approaches you should be aware of.

Why IP whitelisting is commonly used

Despite its drawbacks, IP whitelisting remains popular because it:

  • Works with existing firewalls
  • Requires no architectural changes
  • Can be implemented quickly by hosting providers or network teams
  • Is often the only option in shared hosting or locked-down VPS setups

For many users, these IP ranges are sufficient to establish and maintain a stable Looker Studio connection.

Google IP addresses used by Looker Studio connectors

In real-world deployments, Looker Studio database connectors are observed to originate from Google-owned IP ranges.

The following ranges are commonly whitelisted to allow Looker Studio access:

  • IPv4: 142.251.74.0/23
  • IPv6 (optional): 2001:4860:4807::/48

These IP ranges are widely reported as working for Looker Studio MySQL and similar connectors, but they are not formally guaranteed to remain static.

Important context about these IPs

  • They belong to Google infrastructure, not a dedicated Looker Studio service
  • They may be expanded, rotated, or supplemented over time
  • Google does not publish an official Looker Studio–only IP list

This means IP whitelisting should be treated as a practical solution, not a permanent contract.

Firewall configuration overview

To allow Looker Studio access:

  1. Open your firewall or hosting control panel
  2. Add the IPv4 range 142.251.74.0/23 as an allowed source
  3. Add the IPv6 range if your server listens on IPv6
  4. Restrict access only to the database port (for example, 3306 for MySQL)

Avoid opening broad port ranges or removing existing firewall rules.

MySQL configuration considerations

Your database must also permit connections from external hosts.

Example: Read-only MySQL user

CREATE USER 'looker_ro'@'%' IDENTIFIED BY 'strong-password';
GRANT SELECT ON reporting_db.* TO 'looker_ro'@'%';
FLUSH PRIVILEGES;

Why this matters:

  • Limits access to read-only queries
  • Reduces impact if credentials are exposed
  • Matches typical reporting use cases

Avoid granting administrative privileges or embedding passwords in scripts or documentation.

Known limitations of IP whitelisting

Whilst IP whitelisting works for many users, it does come with trade-offs.

What can go wrong

  • Google may use additional IP ranges without notice
  • Connections can fail unexpectedly after infrastructure changes
  • IPv6 traffic may bypass IPv4-only rules
  • Firewalls that require single IPs may be too restrictive

If your Looker Studio connection works intermittently or fails after months of stability, IP rotation is a common cause.

For this reason, monitoring and periodic review are essential.

Alternative and more stable approaches

Once reporting becomes business-critical, consider moving beyond IP filtering.

Cloud SQL (recommended where possible)

If your database runs on Google Cloud:

  • Use Cloud SQL Authorised Networks
  • Or connect via the Cloud SQL Auth Proxy
  • Avoid exposing MySQL directly to the internet

SSH tunnels for self-hosted databases

For VPS or on-premise servers:

  • Restrict MySQL to localhost
  • Establish an SSH tunnel from a bastion host
  • Keep the database closed to the public network

VPN or private networking

In larger environments:

  • Use site-to-site VPNs
  • Limit database access to private address space
  • Remove public firewall exposure entirely

When IP whitelisting still makes sense

IP whitelisting remains reasonable when:

  • You are working with shared hosting
  • Firewall rules cannot be changed structurally
  • The reporting setup is non-critical
  • You need a fast, low-effort connection

The key is understanding its limitations and planning for growth.

Further notes…

Whitelisting Google IP ranges is often the first step, not the final architecture. It solves an immediate access problem and is widely used in practice, but it should be revisited as reporting workloads increase.

Related post