gem-netsec-cloud-dns

Activate Cloud Shell

Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud. Cloud Shell provides command-line access to your Google Cloud resources.

1. Click Activate Cloud Shell at the top of the Google Cloud console.

When you are connected, you are already authenticated, and the project is set to your PROJECT_ID. The output contains a line that declares the PROJECT_ID for this session:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.

2. (Optional) You can list the active account name with this command:

gcloud auth list

3. Click Authorize.

4. Your output should now look like this:

Output:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Optional) You can list the project ID with this command:

gcloud config list project

Output:

[core] project = <project_ID>

Example output:

[core] project = qwiklabs-gcp-44776a13dea667a6 Note: For full documentation of gcloud, in Google Cloud, refer to the gcloud CLI overview guide.

Overview

This lab simulates a scenario where outbound DNS resolution fails for a Google Compute Engine instance due to a misconfigured Cloud NAT. You will learn how to identify the root cause using a systematic approach, examining instance configurations, Cloud NAT settings, and VPC network routes. This lab will provide you with hands-on experience in troubleshooting network connectivity issues in Google Cloud.

Task 1. Setting up the Environment

In this task, you will set the project ID, region, and zone configurations for your Google Cloud environment. This ensures that subsequent commands are executed in the correct context.

1. Set your Project ID to

   gcloud config set project {{{ project_0.project_id | "PROJECT_ID" }}} Note:
   This command sets your active project identity. It ensures that all subsequent `gcloud` commands are executed within the correct project.

2. Set your default region to

   gcloud config set compute/region {{{ project_0.default_region | "REGION" }}} Note:
   This command sets your active compute region. It specifies the region where resources will be created.

3. Set your default zone to

   gcloud config set compute/zone {{{ project_0.default_zone | "ZONE" }}} Note:
   This command sets your active compute zone. It specifies the zone where resources will be created within the specified region.

Task 2. Creating the VPC Network and Subnet

Create a VPC network named test-vpc with a subnet test-subnet in the specified region. This VPC will host the instance you will use for testing.

1. Create the VPC network test-vpc.

   gcloud compute networks create test-vpc --subnet-mode=custom Note:
   This command creates a new VPC network in your project with custom subnet mode. Custom subnet mode provides flexibility in defining subnets.

2. Create a subnet test-subnet in the test-vpc network within the specified region. Use the IP range 10.10.10.0/24.

   gcloud compute networks subnets create test-subnet --network=test-vpc --region={{{ project_0.default_region | "REGION" }}} --range=10.10.10.0/24 Note:
   This command creates a new subnet in the specified VPC network. The `--range` flag specifies the IP address range for the subnet.

3. Create a second subnet named another-subnet within the test-vpc network. We will intentionally misconfigure the Cloud NAT to use this subnet instead of the one where our VM resides.

   gcloud compute networks subnets create another-subnet --network=test-vpc --region={{{ project_0.default_region | "REGION" }}} --range=10.20.20.0/24 Note:
   This command creates a new subnet that will be used to intentionally misconfigure the NAT gateway. The test-instance is in test-subnet, not another-subnet.

4. Add Firewall rule for IAP access.

   gcloud compute firewall-rules create allow-iap-ssh \ --direction=INGRESS \ --priority=1000 \ --network=test-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20 \ --target-tags=iap-gce Note:
   This command creates a new IAP firewall rule for the specified VPC network.

Task 3. Creating the Compute Engine Instance

Create a Compute Engine instance test-instance in the test-subnet subnet without an external IP address. This instance will be used to test outbound DNS resolution.

1. Create a Compute Engine instance named test-instance in the test-subnet without assigning an external IP address.

   gcloud compute instances create --machine-type=e2-micro test-instance --subnet=test-subnet --no-address --tags="iap-gce" --zone={{{ project_0.default_zone | "ZONE" }}} Note:
   This command creates a new Compute Engine instance in the specified subnet without an external IP address. The `--no-address` flag ensures that the instance does not receive a public IP.

2. Connect to the test-instance using SSH.

   gcloud compute ssh test-instance --zone={{{ project_0.default_zone | "ZONE" }}} Note:
   This command opens an SSH connection to the instance. You will use this connection to test DNS resolution.

3. Also, attempt to ping 8.8.8.8

   ping 8.8.8.8 -c 3 Note:
   This command attempts to ping Google's Public DNS server. You should see a timeout or failure (i.e. ping does not resolve the IP), indicating a network connectivity issue.

4. Press CTRL+C to cancel the Ping command to test-instance.

   Note:
   The ping will eventually timeout if left, but use CTRL+C to terminate the request.

5. Exit from SSH connection to test-instance.

   exit Note:
   Exit the SSH session to the VM.

Task 4. Creating a Misconfigured Cloud NAT Gateway

In this task, you will create a Cloud NAT gateway with an incorrect subnet association to simulate a common misconfiguration. This will prevent outbound traffic from the test-instance, even though the gateway exists.

1. Reserve a static external IP for NAT. This step ensures a named NAT IP (nat-ip) is available before assigning it to the NAT gateway.

   gcloud compute addresses create nat-ip --region={{{ project_0.default_region | "REGION" }}} Note:
   This command reserves a static external IP address named nat-ip in the specified region. This IP will be used by the NAT gateway.

2. Create a Cloud Router.

   gcloud compute routers create test-nat-router --network=test-vpc --region={{{ project_0.default_region | "REGION" }}} Note:
   This command creates a Cloud Router, which is a prerequisite for a Cloud NAT gateway.

3. Create the Cloud NAT gateway, but intentionally associate it with the wrong subnet, another-subnet.

   gcloud compute routers nats create test-nat --router=test-nat-router --region={{{ project_0.default_region | "REGION" }}} --nat-external-ip-pool=nat-ip --nat-custom-subnet-ip-ranges=another-subnet Note:
   This command creates the NAT gateway but incorrectly specifies another-subnet for the --nat-custom-subnet-ip-ranges flag. This misconfiguration will prevent traffic from the test-instance (which is in test-subnet) from being processed by the NAT gateway.

Task 6. Troubleshooting the Misconfigured Subnet

Now, you will test the connectivity again and troubleshoot the NAT configuration to identify the subnet mismatch.

1. Connect to the test-instance using SSH.

   gcloud compute ssh test-instance --zone={{{ project_0.default_zone | "ZONE" }}}

2. Attempt to ping 8.8.8.8.

   ping 8.8.8.8 Note:
   You should see a timeout. Even though a NAT gateway exists, it is not configured to handle traffic from the subnet where the instance is located.

3. Exit the SSH connection.

   exit

4. Inspect the details of the Cloud NAT gateway to find the misconfiguration.

   gcloud compute routers nats describe test-nat --router=test-nat-router --region={{{ project_0.default_region | "REGION" }}} enableEndpointIndependentMapping: false endpointTypes: - ENDPOINT_TYPE_VM name: test-nat natIpAllocateOption: MANUAL_ONLY natIps: - https://www.googleapis.com/compute/v1/projects/{{{ project_0.project_id | "PROJECT_ID" }}}/regions/{{{ project_0.default_region| "REGION" }}}/addresses/nat-ip sourceSubnetworkIpRangesToNat: LIST_OF_SUBNETWORKS subnetworks: - name: https://www.googleapis.com/compute/v1/projects/{{{ project_0.project_id | "PROJECT_ID" }}}/regions/{{{ project_0.default_region| "REGION" }}}/subnetworks/another-subnet sourceIpRangesToNat: - PRIMARY_IP_RANGE type: PUBLIC Note:
   Examine the output, paying close attention to the subnetworks field. You will see that the NAT gateway is only configured for another-subnet, not test-subnet. This confirms the root cause of the connectivity failure.

Task 7. Fixing the Cloud NAT Subnet

Correct the Cloud NAT configuration to include the correct subnet, thereby resolving the outbound connectivity issue.

1. Update the Cloud NAT configuration to associate it with the correct subnet, test-subnet.

   gcloud compute routers nats update test-nat --router=test-nat-router --region={{{ project_0.default_region | "REGION" }}} --nat-custom-subnet-ip-ranges=test-subnet Note:
   This command updates the NAT gateway to use test-subnet instead of another-subnet. This change will correctly enable outbound network connectivity for the test-instance.

Task 8. Testing DNS Resolution (Success)

Reconnect to the test-instance and attempt to resolve an external domain name again. You should now observe a successful resolution.

1. Connect to the test-instance using SSH.

   gcloud compute ssh test-instance --zone={{{ project_0.default_zone | "ZONE" }}} Note:
   This command opens an SSH connection to the instance. Re-establish the connection to verify DNS resolution.

2. Attempt to ping 8.8.8.8

   ping 8.8.8.8 -c 3 Note:
   This command attempts to ping Google's Public DNS server. You should now see a successful ping, confirming network connectivity.

3. Install dns utilities on the test-instance.

   sudo apt install -y dnsutils Note:
   This command installs dns utilities to perform additional testing.

4. Inside the test-instance, attempt to resolve google.com using nslookup.

   nslookup google.com Note:
   This command attempts to resolve the domain name google.com. You should now see a successful resolution, confirming that the DNS issue is resolved.

Congratulations!

You have successfully simulated and resolved a Cloud DNS outbound resolution failure caused by a misconfigured Cloud NAT. By systematically examining the instance configurations, Cloud NAT settings, and VPC network routes, you were able to identify the root cause and implement the necessary fix. This lab provides valuable experience in troubleshooting network connectivity issues in Google Cloud. Ensure that all your NAT gateways are correctly configured to allow necessary traffic, including DNS, for proper functionality.

Additional Resources

• Cloud NAT Documentation
• Cloud DNS Documentation

Manual Last Updated Jul 26, 2025

Lab Last Tested Jul 26, 2025