Skip to main content
To homepage To homepage

Relates to TimeXtender 6024.1 and later versions

The following list of servers and ports used by TimeXtender Data Integration and Ingest Service should be opened in your firewall settings.

TimeXtender Data Integration

To use TimeXtender Data Integration, the desktop software needs to be able to reach these URLs:

  • Instance databases:
    • sql-instances-prod.database.windows.net
    • sql-instances-prod-002.database.windows.net

      Note: The amount of allowed databases on sql-instances-prod.database.windows.net reached the max limit, hence why you may experience that your new instances will be created on the sql-instances-prod-002.database.windows.net SQL server instead. So this means that you may need to allow access for both in your firewall setup.

    • Server is outside Azure (On-Prem): Port 1433 standard for SQL Server
    • Server is Inside Azure: Port range 11000-11999. 

      Note: The IPs can potentially change over time and hostnames don't always resolve to the same IPs over time, or over machines. The ranges of current IPs published by Microsoft here. ​If you are configuring the Azure firewall, allow traffic for the tag "Sql.WestEurope" (so that it deals with these lists automatically). More sophisticated on-prem firewalls can also work with these lists and tags automatically. If your firewall cannot work with these lists and tags automatically, then we recommend automating this process using a PowerShell script or other means of automation (download the latest list, extract the ranges for the tags, and adjust the firewall rules accordingly).

  • Client secret authentication, data sources provider download and updates:
    • traws.timextender.com
    • Port 443
  • Sign-in to TimeXtender Data Integration, Ingest Service configuration and Execution Service configuration
    • timextender-saas.eu.auth0.com
    • gateway.timextender.com
    • Port 443

Azure service bus

We use the azure service bus to do outbound communication, read about it here https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide

  • Allow access to the outbound ports used for the service bus (Currently it is sbns-customer-prod-001.servicebus.windows.net but it will change once the limit has been hit and will likely have a higher number)
    • *.servicebus.windows.net
    • TCP port 5671
    • TCP port 5672

Ingest Service

  • Updating CData components:
    • api.timextender.com
    • Port 443
  • If using Azure Data Lake Storage
    • <storage account name>.dfs.core.windows.net
    • Port 443
  • If using Azure Data Factory Data Sources
    • management.azure.com
    • Port 443
  • Ensure that inbound rules are added for the ports used for the Ingest instances

Additional servers

  • auth0.com      Port 443
  • eu.auth0.com      Port 443
  • cdn.auth0.com      Port 443
  • app.timextender.com      Port 443
  • app-encryption-prod-001.azurewebsites.net      Port 443

Troubleshooting

Test-NetConnection

You can use the Test-NetConnection command in Windows PowerShell on the application server to test your machine's connectivity to the above servers and ports. 

As an example, you can copy and paste the following command into PowerShell then hit ENTER to execute:

Test-NetConnection sql-instances-prod.database.windows.net -Port 1433

Change the Server Name and Port (if necessary) to test any of the above-required network connections for TimeXtender Data Integration. 

This is how the command and results should appear in PowerShell:

 

Turn off services in Subnet setup

In certain Virtual Network scenarios, after enabling the above connections, TimeXtender Data Integration may still be unable to access the TimeXtender Data Integration server in the cloud.
If your App server is on an Azure Virtual Network, review the Subnet setup and check if there is any blocking setting using the Microsoft.Web service endpoint.

Connect to the Virtual Machine you use as App server -> examine the Virtual network/subnet

Click on subnet to get the following menu.

 

 

Remove the Microsoft.Web service endpoint by clicking on the Delete icon.

Save the new configuration.

This may resolve the access issue.

worker.database-windows.net issue

Error initializing server:System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. This failure occurred while attempting to connect to the routing destination. The duration spent while attempting to connect to the original server was - nPre-Login] initialization=6; handshake=10; rLogin] initialization=0; authentication=0; iPost-Login] complete=1; The duration spent while attempting to connect to this server was -  Pre-Login] initialization=2; handshake=14992; ---> System.ComponentModel.Win32Exception (0x80004005): The wait operation timed out

With this error locate the bottom part of the message it may mention a server name in the message such as this.

This is one of the things Microsoft does in routing calls. It is an internal Microsoft worker server on one of their (West Europe) clusters. We don't control this. It will likely not even be for West Europe, the best we can say is that it will be *.worker.database.windows.net,* something. It will be 11000-11999 if it is an Azure VM and 1433 outside that.

In any case, the solution is to make a rule for this in your firewall to allow for communication to the Ingest Service from our Cloud repository.

I have a customer who uses an on-premises virtual machine with no internet access. We added the above firewall rules as a preparation step.

Turns out this list is not exhaustive, you need to add more to the firewall whitelist, to make the login process work correctly:

  • auth0.com
  • eu.auth0.com
  • cdn.auth0.com
  • app.timextender.com
  • app-encryption-prod-001.azurewebsites.net

So you need to add these 5 rules to the firewall as well, besides the list above.

Thank you Hans. The article has been updated.

In a TX environment where a pretty strict inbound/outbound firewall is in place, we encountered issues when upgrading the ODX software. This particular event took place when validating the ODX client secret and is related to what is mentioned under ‘worker.database-windows.net issue’.

I would like to mention that we had to create an outbound rule to ‘any’ destination over port range 11000-11999. Might be good to underline the importance of this network routing in the article above that takes place when you server is in Azure! 

 

For more details, see my post on the Community:

 

@Syed Yousuf  I think https://xpilot.timextender.com should be added to the list of sites to whitelist. At a TX client we’ve added all mentioned URL’s to the company proxy, but the xPilot URL is still unreachable. The login popup also tries to contact upload.video.google.com, which is not whitelisted for us resulting in a certificate error. I can provide screenshots if needed. The certificate error can however be bypassed by ignoring it (proceed = no) and you’re then still able to log in. 

 

@Syed Yousuf  After whitelisting the mentioned URL’s in a proxy server for the TX VM in Azure you can still get errors in the TX login screen. The login screen has components in it that are trying to reach Google (video.google.com), so please add that this to the list. 

@Syed Yousuf we are facing the same firewall problems mentioned above at one of our customers. I have had an Azure networking expert look into this and the problem is that the sql-instances-prod.database.windows.net domain resolves to a lot of different IP addresses. See screenshot:
 

IMHO on the TimeXtender side of things, there should be a loadbalancer behind one public IP to solve this matter to prevent our customers being forced to open an entire port range to the internet just to be able to use TX. As you can imagine, customers (especially those with in this case highly sensitive medical data) are quite reluctant to do so.

Hi @wouter.goslinga 

Do you mean that these manual rules are the issue.

 

@Thomas Lind no not the firewall rules on the TX side, I mean the Azure firewall on the customer side of things.

@wouter.goslinga 

I believe we faced the same issue at a client. The Azure experts suspected that sql-instances-prod.database.windows.net redirects to “Azure SQL IP addresses in the region on ports in the range of 11000 to 11999.” as described here Azure SQL Database connectivity architecture - Azure SQL Database and Azure Synapse Analytics | Microsoft Learn
 

Instead of having to open the port range 11000-11999 to the entire internet, it was enough to include the Sql Service tag in the firewall list. https://learn.microsoft.com/en-us/azure/virtual-network/service-tags-overview

Hi @Syed Yousuf ,

Can you please add the firewall exceptions for the Exmon Data Gateway to this article as well? 


Thanks in advance. 

Hi,

Our client has a very locked down environment, for both inbound and outbound traffic, and can only whitelist based on IP address, rather than DNS name.

IP ranges have been provided in this article for the Microsoft Azure SQL connection.

Are you able to also provide the possible IP ranges for:

  • *.TimeXtender.com
  • app-encryption-prod-001.azurewebsites.net
  • *.servicebus.windows.net

In addition, I’ve found the IP Ranges for Auth0.com on their website. Are you able to advise which region of Auth0.com is used by TimeXtender.

 

Thank you
Steve

@SteveSmith

The Auth0 tenant is running in the EU region (https://auth0.com/docs/secure/security-guidance/data-security/allowlist).

  • app-encryption-prod-001.azurewebsites.net
    20.105.216.12
     
  • *.timextender.com
    • 20.50.2.26 (app.timextender.com)
    • 52.178.114.226 (api.timextender.com)
    • 20.105.216.8 (traws.timextender.com)
       
  • servicebus.windows.net
    Using the Microsoft document linked in the article (https://www.microsoft.com/en-us/download/details.aspx?id=56519), whitelist the IP addresses in the category "EventHub.WestEurope" and "ServiceBus.WestEurope". Regarding servicebus IPs, according to the following Microsoft article you can run "nslookup sbns-customer-prod-001.servicebus.windows.net" in PowerShell and get it that way. It returns 104.46.32.56 for me (https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-faq).

If your environment has a strictly regulated outbound firewall and you need to install TimXtender and related components, these FQDNs should also be opened up:

  • support.timextender.com (as mentioned in one of the comments, it is better to include *.timextender.com)
  • ftp-2.hostedftp.com (this is what the TX downloads forward you to)
  • aka.ms (for downloading SSMS)
  • go.micosoft.com (for downloading the on-premise data gateway software, if you need to use t

Please add this to the original article.

Reply


Terms and ConditionsCookie settings