Connectivity Issues

Diagnosing and resolving synchronizer connection failures, TLS errors, and VPN problems

Connectivity failures prevent your validator from communicating with the synchronizer. The symptoms vary — from outright connection refusals to subtle TLS handshake errors — but the diagnostic approach is consistent.

Cannot Connect to Synchronizer

If your validator logs show:

Request failed for sequencer. Is the server running?

or

SEQUENCER_SUBSCRIPTION_LOST: Lost subscription to sequencer

Work through these checks in order.

1. Verify the Sequencer URL

Confirm that your configuration points to the correct sequencer endpoint for your target network:

• DevNet: https://sequencer.dev.sync.global
• TestNet: https://sequencer.test.sync.global
• MainNet: https://sequencer.sync.global

A common mistake is using the scan URL (https://scan.sv-2...) instead of the SV sponsor URL during onboarding. The scan URL is for read-only network data, not for validator registration.

2. Test Network Reachability

# DNS resolution
dig +short sequencer.sync.global

# TCP connectivity
nc -zv sequencer.sync.global 443

# Full TLS handshake
openssl s_client -connect sequencer.sync.global:443 -servername sequencer.sync.global </dev/null

If nc times out, a firewall or security group is blocking egress on port 443.

3. Check Firewall and Security Groups

Your validator requires outbound HTTPS on port 443 to the synchronizer. If you run in a cloud environment, verify:

• The security group attached to your instance or pod allows outbound TCP/443.
• No network ACL is blocking the traffic.
• If you use an HTTP proxy, Canton supports proxy configuration via JVM system properties (-Dhttps.proxyHost, -Dhttps.proxyPort).

TLS Handshake Failures

TLS errors typically produce log messages like:

io.grpc.StatusRuntimeException: UNAVAILABLE: io exception
Channel Pipeline: [SslHandler#0, ...]
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed

Certificate Expiry

Check whether the server certificate has expired:

openssl s_client -connect sequencer.sync.global:443 -servername sequencer.sync.global 2>/dev/null \
  | openssl x509 -noout -dates

If the certificate has expired and you control it (e.g., for your own validator’s TLS termination), renew it and restart the TLS-terminating proxy or ingress controller.

CA Trust Chain

If you see PKIX path building failed, the validator’s JVM does not trust the server’s certificate authority. Possible fixes:

• Import the CA certificate into the JVM truststore:

  keytool -importcert -alias myca -file ca-cert.pem \
    -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit
  

• For Kubernetes, mount the CA bundle as a volume and set JAVA_OPTS:

  env:
    - name: JAVA_OPTS
      value: "-Djavax.net.ssl.trustStore=/etc/ssl/truststore.jks"
  

Hostname Mismatch

If the certificate’s Subject Alternative Name (SAN) does not include the hostname you are connecting to, the handshake will fail. Verify with:

openssl s_client -connect sequencer.sync.global:443 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

VPN Problems

DevNet requires a VPN connection. TestNet and MainNet validators connect over the public internet but may still use VPNs for internal infrastructure.

VPN Connection Drops

If your validator periodically loses connectivity, check:

• VPN client logs for reconnection events
• Whether the VPN assigns a stable IP (some providers rotate IPs on reconnect, which can break IP-whitelisted access)

MTU Issues

VPN tunnels reduce the effective MTU. If you see stalled connections that work for small requests but hang on larger payloads:

# Test with reduced packet size
ping -M do -s 1400 sequencer.dev.sync.global

If pings succeed at 1400 bytes but fail at 1500, lower the MTU on the VPN interface:

sudo ip link set dev tun0 mtu 1400

Split-Tunnel Configuration

If your VPN routes all traffic through the tunnel, the validator may be unable to reach external services (OIDC provider, container registries). Configure split-tunnel routing so that only synchronizer traffic goes through the VPN, while other traffic uses the default gateway.

Consult your VPN provider’s documentation for split-tunnel setup.