Confluent Developer Marketplace Get started
  1. Home
  2. Cloud
  3. Manage Networking on Confluent Cloud

Test Connectivity to Confluent Cloud

Test connectivity to Confluent Cloud with netcat, openssl, or telnet to verify reachability to the Kafka cluster and the Kafka REST endpoint before whitelisting those endpoints. Kafka broker hosts in Confluent Cloud don’t respond to ping.

Note that you need to whitelist both endpoints (ports 9092 and 443) on your firewall for the Confluent CLI. And you need to whitelist the endpoint on port 443 to ensure that the Terraform Provider for Confluent and the Kafka REST API to work properly.

Confluent Cloud bootstrap server and REST endpoint ports

Confluent Cloud Kafka clusters use port 9092 for the bootstrap server, typically over SASL_SSL, and port 443 for the Kafka REST endpoint. The bootstrap server and REST endpoint use the same host address and differ only by port.

Endpoint

Port

Protocol

Kafka bootstrap server

9092

SASL_SSL (or mTLS)

Kafka REST endpoint

443

HTTPS

Run through the following steps to validate Confluent Cloud connectivity is working correctly.

  1. Test connectivity to the Confluent Cloud cluster bootstrap endpoint:

  2. If connectivity can be successfully established, test data plane operations by producing/consuming using:

Test public, peering, and Transit Gateway connectivity to Confluent Cloud

For public networking, VPC peering, VNet peering, and AWS Transit Gateway, test connectivity to the Confluent Cloud cluster using one of the tools, openSSL, Netcat, or Telnet.

For public endpoint clusters, run the command from any computer that has internet access.

For the cluster in private network environments, such as VPC peering, VNet peering, and AWS Transit Gateway, run the tests from within your VPC or VNet that is connected to the Confluent Cloud cluster.

Note that the host addresses of the Kafka bootstrap server and the REST endpoint are the same, and only the port numbers differ:

  • Use port 9092 to test the connection to the Kafka bootstrap server.

  • Use port 443 to test the connection to the Kafka REST endpoint.

To only test TCP connectivity, use Telnet and Netcat (or its successor Socat):

  • Netcat

    nc -zv <bootstrap-url> 9092

nc -zv <bootstrap-url> 443

  • Telnet

    telnet <bootstrap-url> 9092

telnet <bootstrap-url> 443

In addition to TCP connectivity, to also test TLS handshake and the certificate, use openSSL. With openSSL, you can send an SNI header:

  • openSSL

    openssl s_client -servername <bootstrap-url> -connect <bootstrap-url>:9092

openssl s_client -servername <bootstrap-url> -connect <bootstrap-url>:443

    For details, see the OpenSSL documentation for the -connect option.

It is recommended that you use OpenSSL to test TCP and TLS because with the TCP testing only, it is difficult to make the distinction among the various causes when a connection fails, such as:

  • Timeout because of routing problems

  • Established connection, but you, as the client, are not initiating the TLS handshake

  • Confluent Cloud proxy disconnecting your connection because you do not send the SNI header

    For the TLS SNI extension requirement in Kafka clients, see TLS SNI extension requirement.

Troubleshoot connectivity issues

If connectivity to the bootstrap endpoint cannot be established, check your firewalls and other security configurations and restrictions that could prevent the connection to the Confluent Cloud cluster bootstrap endpoint.

Test connectivity to Kafka using Confluent CLI

After connectivity is successfully established, test data plane operations by producing/consuming using the Confluent CLI.

If using private networking, run the steps from an instance within the VPC or VNet to validate Kafka connectivity works correctly.

  1. Sign in to Confluent CLI with your Confluent Cloud credentials.

    confluent login

  2. List the clusters in your organization.

    confluent kafka cluster list

  3. Select the cluster you wish to test.

    confluent kafka cluster use ...

    For example:

    confluent kafka cluster use lkc-abcdef

  4. Get the endpoint to test with when using a cluster with PNI.

    If you are using a cluster with PNI, you need to use the PNI endpoint to test connectivity.

    1. List the endpoints in your cluster. For example:

      confluent kafka cluster endpoint list --cluster lkc-123456

      In the output, PNI endpoints will have the Connection Type of PRIVATE_NETWORK_INTERFACE.

    2. Select the endpoint you retrieved in the previous step to test. For example:

      confluent kafka cluster endpoint use "<pni-rest-endpoint>:443"

  5. Create a cluster API key to authenticate with the cluster.

    confluent api-key create --resource ... --description ...

    For example:

    confluent api-key create --resource lkc-abcdef --description "connectivity test"

  6. Select the API key you just created.

    confluent api-key use ... --resource ...

    For example:

    confluent api-key use WQDMCIQWLJDGYR5Q --resource lkc-abcdef

  7. Create a test topic.

    confluent kafka topic create test

  8. Start consuming events from the test topic.

    confluent kafka topic consume test

  9. Open another terminal tab or window.

  10. Start a producer.

    confluent kafka topic produce test

  11. Type anything into the produce tab and hit Enter; press Ctrl+D or Ctrl+C to stop the producer.

  12. The tab running consume will print what was typed in the tab running produce.

Troubleshoot connectivity to Kafka brokers

Test connectivity to Kafka using other tools

After connectivity is successfully established, you can use the other clients and tools to test producing/consuming messages when Confluent CLI is not a viable option. Examples are kafka-topics, kafka-console-consumer, native command line tools, or Java and other clients. The following are a few of the test workflows you can use as references. Note that some articles require you to log into the Confluent Support portal.

Test private networking connectivity for Flink

After you set up a private connectivity option for Confluent Cloud for Apache Flink, such as an ingress PrivateLink Gateway or Confluent Cloud network, validate that the private endpoints are reachable before you connect a client.

Unlike Kafka clusters, Flink doesn’t expose a raw broker port to clients. Flink statements and results are always served over HTTPS, so there’s no Kafka bootstrap port 9092 to test. Only Kafka REST endpoint port 443 applies.

Endpoint

Port

Protocol

Flink statement and results endpoint (flink.*)

443

HTTPS

Flink language service endpoint (flinkpls.*)

443

HTTPS (WSS, WebSocket Secure, for autocomplete in the Flink SQL shell)

To validate connectivity to Flink, complete the following steps from an instance within your VPC or VNet, or anywhere the private DNS is set up.

  1. Set an environment variable with your private Flink endpoint. You can find this value on the Flink Endpoints page in Confluent Cloud Console, or by running confluent flink endpoint list.

    export FLINK_ENDPOINT=flink.us-east-2.aws.private.confluent.cloud

  2. Test DNS resolution for the endpoint from your private network.

    dig $FLINK_ENDPOINT

    If resolution fails, confirm that the Confluent Cloud private DNS zone is associated with your VPC or VNet, and that the DNS records were created for the gateway or Confluent Cloud network.

  3. Test TLS connectivity to the endpoint on port 443 using openssl.

    openssl s_client -connect $FLINK_ENDPOINT:443 -servername $FLINK_ENDPOINT -verify_hostname $FLINK_ENDPOINT </dev/null 2>/dev/null | grep -E 'Verify return code|BEGIN CERTIFICATE' | xargs

    If the return output is -----BEGIN CERTIFICATE----- Verify return code: 0 (ok), connectivity to the endpoint is confirmed.

  4. If you use the Flink SQL shell, also test the language service endpoint, which uses the flinkpls prefix in place of flink.

    export FLINKPLS_ENDPOINT=flinkpls.us-east-2.aws.private.confluent.cloud

openssl s_client -connect $FLINKPLS_ENDPOINT:443 -servername $FLINKPLS_ENDPOINT -verify_hostname $FLINKPLS_ENDPOINT </dev/null 2>/dev/null | grep -E 'Verify return code|BEGIN CERTIFICATE' | xargs

    The Flink SQL shell requires access to both the flink and flinkpls endpoints. If you use private DNS resolution, you must route the flinkpls endpoint from your client as well. For more information, see private DNS resolution.

  5. After connectivity is confirmed, select the private endpoint in the Confluent CLI before you start the Flink SQL shell or run statements.

    confluent flink region use --cloud <cloud_provider> --region <region>

confluent flink endpoint list

confluent flink endpoint use

Troubleshoot Flink private networking connectivity

If connectivity to the flink or flinkpls endpoint cannot be established, check the following:

  • Your security group has inbound and outbound rules for port 443 from your VPC CIDR. The protocol should be TCP.

  • You created a private DNS zone with the correct Confluent Cloud DNS domain name, and it resolves both the flink and flinkpls hostnames.

  • For an ingress PrivateLink Gateway, confirm that the gateway is created in the same region as the Flink statement or workspace, and that the private endpoint or access point is attached to it. For Dedicated clusters, Flink requires a gateway even if a private link already exists for the cluster.

  • For Confluent Cloud network, confirm that at least one Kafka Dedicated cluster exists in the environment and region where you use Flink.

  • If your VPC isn’t configured to use the standard DNS resolver of the cloud provider, the instance won’t be able to resolve the private DNS zone. As a test, run dig with the resolver to use. For example:

    dig @<dns_resolver> <hostname>

    The cloud provider’s standard resolvers are:

    • For AWS: 169.254.169.253

    • For Azure: 168.63.129.16

    • For Google Cloud: 169.254.169.254

For more information about connectivity options and the endpoint patterns for each option, see Private Networking with |af-long|.