Forum Discussion
Kudo CommanderSnowflake Refresh Failures – CURLcode 35 / SSL Connect Error
Hi everyone,
We are facing intermittent refresh failures in Power BI Service for reports connected to Snowflake through an On-premises Data Gateway.
The refresh sometimes succeeds and sometimes fails without making any changes to the report or connection.
The main error we are seeing is:
- CURLcode=35
- SSL connect error
- Arrow chunk download failed – max retries done
- [Microsoft][Snowflake]
We initially suspected that this could be related to the Snowflake Connector 2.0 implementation, so we also tested the same reports using Snowflake Connector 1.0.
We manually refreshed multiple reports one by one, including 3 large reports and 1 small report. The issue is still occurring with Connector 1.0.
For example:
- Agent Performance: Failure → Failure → Success
- Queue Performance: Failure → Success → Failure
So the issue appears to be intermittent rather than a consistent connector failure.
The error also includes:
CURLEasy_perform() failed - code=35 msg=SSL connect error
and in some attempts:
Arrow chunk download failed max retries done
We would appreciate any guidance on what could cause this type of intermittent SSL connection failure between the Power BI Gateway and Snowflake.
Specifically:
- Could this be related to the Gateway-to-Snowflake network connection or SSL/TLS handshake?
- Are there any specific Gateway logs or diagnostic logs we should check for this CURLcode=35 error?
- Could firewall, proxy, or SSL inspection cause this type of intermittent failure?
- Is there any known issue with Snowflake Connector 1.0/2.0 that could cause intermittent CURLcode=35 errors when downloading larger result sets?
- Are there any recommended connectivity tests that we can perform directly from the Gateway server to isolate whether the issue is Power BI/Gateway, Snowflake, or the network path?
I have attached the screenshots/testing results showing the failures for reference.
Any suggestions on what we should check next would be greatly appreciated.
Thanks!
Hi manoj_0911,
The detail that narrows this fastest is your own test. You switched to Connector 1.0 and got the same failures, with Agent Performance going Failure, Failure, Success. Implementation 1.0 is the Simba ODBC driver and 2.0 is the ADBC one, so if both fail the same way the driver is not the variable. What they share is the network path, and there is one hop on that path that is not your Snowflake account host.
Snowflake splits large results out to cloud storage and the client downloads them separately. Their connectivity docs put it plainly: retrieving large results, meaning over 100KB, requires clients to have full network access with certificate passthrough to all STAGE endpoints. Those stage endpoints are a different hostname from the one you authenticate against, usually S3 or Azure Blob. That is why a connection test passes, small queries are fine, and Arrow chunk download failed with max retries done turns up on the big ones. CURLcode 35 is a TLS handshake failure, and Snowflake explicitly does not support altering or modifying the TLS certificates for its services, so anything re-signing that traffic will break it.
The test I would run first, from the gateway server itself rather than from a laptop: run SELECT SYSTEM$ALLOWLIST() in Snowflake and pull out the entries whose type is STAGE. Then open a TLS connection from the gateway to that stage host on 443 and look at who issued the certificate that comes back. If the issuer is your own corporate CA rather than a public one, SSL inspection is in the path and that is your answer. Ask your network team about the stage host specifically, not about Snowflake, because the account host is very likely allowed already and that is why this has stayed hidden.
One correction worth having before you spend time on it: SnowCD has reached end of life. Snowflake now points you at the snow connection test command in their CLI instead.
The intermittency fits this too, since whether a result crosses the chunking threshold moves with how much data each refresh happens to pull.
2 Replies
PauReisResolver II
Hi manoj_0911,
The detail that narrows this fastest is your own test. You switched to Connector 1.0 and got the same failures, with Agent Performance going Failure, Failure, Success. Implementation 1.0 is the Simba ODBC driver and 2.0 is the ADBC one, so if both fail the same way the driver is not the variable. What they share is the network path, and there is one hop on that path that is not your Snowflake account host.
Snowflake splits large results out to cloud storage and the client downloads them separately. Their connectivity docs put it plainly: retrieving large results, meaning over 100KB, requires clients to have full network access with certificate passthrough to all STAGE endpoints. Those stage endpoints are a different hostname from the one you authenticate against, usually S3 or Azure Blob. That is why a connection test passes, small queries are fine, and Arrow chunk download failed with max retries done turns up on the big ones. CURLcode 35 is a TLS handshake failure, and Snowflake explicitly does not support altering or modifying the TLS certificates for its services, so anything re-signing that traffic will break it.
The test I would run first, from the gateway server itself rather than from a laptop: run SELECT SYSTEM$ALLOWLIST() in Snowflake and pull out the entries whose type is STAGE. Then open a TLS connection from the gateway to that stage host on 443 and look at who issued the certificate that comes back. If the issuer is your own corporate CA rather than a public one, SSL inspection is in the path and that is your answer. Ask your network team about the stage host specifically, not about Snowflake, because the account host is very likely allowed already and that is why this has stayed hidden.
One correction worth having before you spend time on it: SnowCD has reached end of life. Snowflake now points you at the snow connection test command in their CLI instead.
The intermittency fits this too, since whether a result crosses the chunking threshold moves with how much data each refresh happens to pull.
- ShahRukhSameer
Continued Contributor
Hi manoj_0911,
I would look at the network connection before focusing too much on the connector version. CURLcode 35 generally points to an SSL/TLS connection problem, and the fact that the same refresh can fail and then succeed makes me think there is something intermittent in the connection rather than a problem with the report itself.
The Arrow chunk download message is also worth looking at. With larger result sets, Snowflake may need to download the data in chunks, so I'd check whether the gateway server can consistently reach all of the required Snowflake endpoints. A proxy, firewall or SSL inspection device could potentially allow the initial connection but interfere with the subsequent downloads.
Since you're using an On-premises Data Gateway, I'd do the testing directly from the gateway server. In particular, I'd check:
- Whether the gateway server is going through a proxy or SSL inspection.
- Whether the firewall is resetting or dropping connections at the time of the failed refresh.
- Whether the Snowflake Network Policy allows the public/NAT IP used by the gateway.
- If you have multiple gateway servers in a cluster, whether the failures happen only when a particular node is used.
- Whether the gateway and Snowflake driver versions are up to date.
I would also compare the gateway logs from one successful refresh and one failed refresh at exactly the same time. That may give you a better indication of where the connection is being dropped.
The fact that you see the same behaviour with Connector 1.0 makes me less inclined to think this is specifically a Connector 2.0 issue. I'd first try to rule out the network/proxy/firewall side.
If the failures are mainly happening with the larger reports while the smaller one is more reliable, I'd pay particular attention to the Arrow chunk download part and whether something in the network path is timing out or terminating those longer connections.
