We are encountering issues with credentials used to connect to a Microsoft SQL database. We are in the process of migrating all workflows from one n8n environment to another, which includes transferring the credentials.
However, in the new n8n instance, these credentials are failing with the following error:
The same credentials work without issues in other n8n instances and when connecting via SSMS, suggesting this could be an n8n-specific issue. We’ve already updated to the latest version, but the error persists. Notably, these credentials were working in the new environment until 9/19/24, when they suddenly stopped. The issue seems to be tied to a specific server, as credentials for other servers continue to work.
Based on the information you have provided I don’t think this is an n8n issue and this is based on you saying that the same credentials work fine in other n8n instances. Also based on that and the credentials working in SSMS and also working in the new environment until the 19th it rules out credenitals as the issue.
So what is left… Well looking at it the only thing I can think of is there was a network change or config change somewhere on the 19th and that is stopping the n8n instance from connecting to the SQL server.
You have said that you are using n8n Cloud for this so the first thing I would check is the firewall to make sure that the IP for your cloud instance is allowed through as that seems like the most likely cause at the moment.
@Jon Thank you for the response I really appreciate it!
I will look into the firewall settings on the server.
You also mentioned configuration settings, is there a way to view what IP address was used on the successful runs via the execution history or some other method? I found a workflow to get the current IP address being used but am trying to get as much information as possible.
To provide an update here, we got the IP address that our n8n instance is using which is 20.79.72.36.
We went to the server’s support center who has access to see which IP addresses are blocked and which have pinged their server and this one was not listed, so it seems like the call is not being sent at all.
We are at a loss and would appreciate any tips to reconcile this.
To reiterate, the credentials are connecting on another n8n instance running version 1.59.4 (Self-hosted) and the credentials were working on this instance up until 9/19 when they suddenly broke.
The server is related to Foundation Software’s construction SQL server.
It could be that the IP for your instance changed, The error message seems to be fairly clear that the connection is failing and I have seen the same error in the past when the Cloud IPs have not been allowed to connect.
Did the team confirm that all of the Cloud IPs are allowed to connect to your SQL server?
@Jon
Are you aware of any other potential causes not related to IP addresses? Our team is at a standstill here. I want to say I appreciate the responses you’ve given.
There are no other issues I am aware of, I know we don’t block any outbound connections and we can see that n8n is working based on your other environment working.
Did they make any changes around September 19th? I am aware of the security incident raised by Huntress on September 14th with the mobile app and port 4243 so it is possible that the changes they made to resolve that issue has impacted your ability to connect?