Data connector setup fails for on-premise ERP due to firewall restrictions

We’re trying to set up a Snowflake data connector to pull data from our on-premise ERP system, but the connection keeps timing out during the initial handshake. Our network team has opened standard HTTPS ports (443), but we’re still seeing connection failures in the connector logs.

I’ve verified the connector configuration multiple times - credentials are correct, the ERP endpoint is accessible internally, and the Snowflake account details match our production instance. The error suggests the handshake isn’t completing, which makes me think there’s something blocking the outbound connection to Snowflake’s endpoints.

Has anyone dealt with similar firewall issues when connecting on-prem data sources to Snowflake? I’m particularly concerned about:

  • Whether we need to whitelist specific Snowflake IP ranges for outbound traffic
  • Any special firewall rules beyond standard HTTPS
  • How to troubleshoot the connector handshake process to identify exactly where it’s failing

Our data sync is completely blocked right now, and we need to get this resolved quickly.

Don’t forget about the Snowflake stage endpoints! If your connector uses internal stages for data transfer, you’ll need to whitelist those IPs separately from the main account endpoints. We spent two days troubleshooting this only to discover our firewall was blocking the stage URLs. Also, some connectors require access to Snowflake’s metadata services on different ports - check the connector documentation for the complete port list beyond just 443.

Have you checked if your firewall has rate limiting or connection throttling enabled? Some enterprise firewalls will drop connections that they perceive as too frequent or too long-lived. Snowflake connectors often maintain persistent connections for efficiency, which can trigger these rules. You might need to create an exception for Snowflake traffic to bypass rate limiting. Also verify that your firewall timeout settings allow connections to stay open long enough for large data transfers.

Quick troubleshooting tip - enable debug logging on your connector to see exactly where the handshake fails. The logs should show whether it’s a DNS resolution issue, TCP connection timeout, or SSL certificate validation problem. Each points to different firewall rules you might need. Also check if your corporate firewall does SSL inspection - that can break the Snowflake connector’s certificate validation.

I’ve seen this before. The issue is usually that Snowflake connectors need access to multiple endpoint IPs, not just one. Check your Snowflake account region - each region has its own set of IP addresses that need to be whitelisted. You can find the complete list in the Snowflake documentation under Network Policies. Also, make sure your firewall allows persistent connections, not just one-time requests.

Adding to what network_admin_22 said - we had the exact same problem last year. The connector needs bidirectional communication during handshake. Your firewall might be blocking the response from Snowflake back to your on-prem system. Check if your firewall has stateful inspection enabled and if it’s allowing established connections back through. We had to create specific rules for the Snowflake IP ranges with both inbound and outbound permissions. Also verify that your proxy settings (if you use one) aren’t interfering with the SSL handshake.