Connectivity Tests can drop a test packet for any of the following reasons.
For a full list of possible reasons, see Configuration analysis states.
Dropped due to a firewall rule
Configuration analysis determined that the packet is dropped because of a firewall rule, unless the packet is allowed due to connection tracking.
Connectivity Tests might deny a test packet because the packet matches a blocking firewall rule or a firewall policy. However, the actual data plane might allow the packet through due to connection tracking on the firewall rule. Connection tracking allows packets for an existing connection to return despite the firewall rule.
Every VPC network has two implied firewall rules that allow egress traffic to everywhere and block incoming traffic from everywhere.
However, if you have a higher priority deny egress firewall rule, it takes effect.
For connectivity to succeed, you need an egress firewall rule at the source allowing access to the destination endpoint and ingress firewall rule at the destination to allow this connection.
VPC firewall rules are stateful. If the specified destination endpoint is normally the side that initiates the communication, response traffic is automatically allowed with connection tracking and there is no need for an ingress firewall rule.
Delete the deny rule or create an allow rule based on the details in the Connectivity Tests results. For more information, see Use firewall rules.
Private traffic to internet
A packet with an internal destination address was sent to an internet gateway.
The destination IP address is a private IP address, which cannot be reached through the internet. The packet leaves the source VM, but there is no internal route to reach the destination endpoint and is following the path to the internet gateway.
If you'd like to access the destination IP address through the internet, make sure that your VM has internet connectivity and you can use the destination endpoint's public IP address.
If you'd like to access the VM through its private IP address, you need to establish connectivity between networks. You can do this in any of the following ways:
- If your destination endpoint is within an on-premises network, use a hybrid connectivity solution such as Cloud VPN or Cloud Interconnect.
- If your destination endpoint is within Google Cloud:
If you already have a connection to the destination network:
- The source endpoint network does not have a route through this connection or uses the default route that goes through the internet gateway. Make sure that routes are advertised correctly at both sides of the connection.
If you are testing connectivity to an on-premises network from a peered network, see this example for custom advertisement, network routing mode, and exchanging custom routes.
Transitive VPC peering is not supported. You can use VPN or peering for these two VPC networks.
Forwarding rules do not match
The forwarding rule's protocol and ports do not match the packet header.
The forwarding rule's protocol and ports do not match the packet header, or the packet does not originate from the same region or it is not directed to the same region as the regional load balancer.
Confirm the destination forwarding rule protocol and port.
If the forwarding rule is regional, the client (for example, VM or VPC connector) should be in the same region as the load balancer.
While connecting from an on-premises network, make sure that client accesses the load balancer through Cloud VPN tunnels or VLAN attachments that are in the same region as the load balancer. For more details, see Internal HTTP(S) Load Balancing and connected networks.
You can enable global access on an internal TCP/UDP load balancer to access from clients in any region. Global access to an internal HTTP(S) load balancer is not possible.
Dropped due to no route
Dropped due to no routes.
There is no applicable route to reach the destination endpoint. In the Google Cloud console, go to the VPC network page. Click Routes. Filter the routes for the VPC network where the source VM exists and confirm that there is no route that includes the destination IP address.
If you try to access the destination endpoint using its private IP address, make sure that the source and destination networks are connected.
If you already have connectivity between the networks, make sure that the routes are advertised correctly on both sides of the connection. If you are testing connectivity to an on-premises network from a peered network, see this example for custom advertisement, network routing mode, and exchanging custom routes.
Transitive VPC peering is not supported. Consider using VPN or peering these two VPC networks.
If you try to access the destination endpoint through the internet, make sure that you have a route for this destination through the default internet gateway.
No external address available
A VM instance with only an internal IP address tried to access external hosts through a route whose next hop is the default internet gateway. Expected when Cloud NAT is not enabled in the subnet or when there's no other default route that uses a different type of next hop (such as a proxy VM).
An instance with only an internal IP address tried to access an external host but it did not have an external IP address or Cloud NAT was not enabled in the subnet.
If you'd like to access external endpoints, you can assign an external IP address to your instance. Alternatively, you can enable Cloud NAT on its subnet unless the connection goes through a proxy instance that gives access to the internet.
Forwarding rule with no instances
The forwarding rule does not have backends configured.
The forwarding rule you are trying to reach does not have any backends configured.
Check the load balancer configuration and make sure that the backend service of the load balancer has backends configured.
Traffic type is blocked
The type of traffic is blocked and you cannot configure a firewall rule to enable it. For more details, see Always blocked traffic.
This traffic type is blocked by default, and can't be enabled by creating firewall rules. Common scenarios are as follows:
- Sending egress traffic to an external destination with TCP port 25 (SMTP). For more details, see Always blocked traffic.
- Sending traffic to an unsupported port on a Cloud SQL instance. For example, sending traffic to TCP port 3310 to a MySQL Cloud SQL instance with port 3306 open.
- Sending egress traffic from a Cloud Function using protocols other than TCP or UDP through a Serverless VPC Access connector.
For egress SMTP (egress traffic to an external destination with TCP port 25) traffic, see Sending email from an instance.
For DHCP protocol, including UDP IPv4 packets to destination port 68 (DHCPv4 responses) and UDP IPv6 packets to destination port 546 (DHCPv6 responses), DHCP traffic is only allowed from the metadata server (169.254.169.254).
For Cloud SQL connectivity, make sure the port used is correct.
Serverless VPC Access connector is not configured
Packet was dropped because the Cloud Function does not have a Serverless VPC Access connector configured.
The destination IP address is a private IP address, which cannot be reached through the internet. The packet leaves the source Cloud Function, but there is no Serverless VPC Access connector for the Cloud Function.
If you try to access the destination endpoint using its private IP address, make sure that you have configured a Serverless VPC Access connector for the Cloud Function.
Serverless VPC Access connector is not running
Packet was dropped because the Serverless VPC Access connector is not running.
The packet is dropped because all the Serverless VPC Access connector instances are stopped.
For a list of troubleshooting steps, see Troubleshooting.