To homepage To homepage
Firewall

Configure your Firewall

  • 27 December 2022
  • 9 replies
  • 3183 views
Configure your Firewall
S
Rank
Userlevel 3
Badge +3

Relates to TimeXtender 6024.1 and later versions

The following list of servers and ports used by TimeXtender and ODX Server should be opened in your firewall settings.

TimeXtender Desktop

To use the new version of TimeXtender, the desktop software needs to be able to reach these URLs:

  • Instance databases:
    • sql-instances-prod.database.windows.net
    • Server is outside Azure (On-Prem): Port 1433 standard for SQL Server
    • Server is Inside Azure: Port range 11000-11999
  • Client secret authentication, data sources provider download and updates:
    • traws.timextender.com
    • Port 443
  • Sign-in to Desktop, ODX configuration
    • timextender-saas.eu.auth0.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

ODX Server

  • 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 ODX 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. 

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 Desktop may still be unable to access the TimeXtender 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 - [Pre-Login] initialization=6; handshake=10; [Login] initialization=0; authentication=0; [Post-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 ODX Server from our Cloud repository.

9 replies

H
Rank

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.

S
Rank
Userlevel 3
Badge +3

Thank you Hans. The article has been updated.

K
Rank
Userlevel 2
Badge +1

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:

 

rogier.helmus
Rank
Badge +1

@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. 

 

rogier.helmus
Rank
Badge +1

@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. 

wouter.goslinga
Rank
Userlevel 2
Badge +1

@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.

Thomas Lind
Rank
Userlevel 5
Badge +5

Hi @wouter.goslinga 

Do you mean that these manual rules are the issue.

 

wouter.goslinga
Rank
Userlevel 2
Badge +1

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

P
Rank
Userlevel 3
Badge +1

@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

Reply


Terms and ConditionsCookie settings