Skip to main content
To homepage To homepage

When launching the newly installed ODX Server configuration (20.10.45), we get the following error:

First, we thought this was a Firewall issue on our (Azure VM), because this test-netconnection did not work (see the second one failing):

When I try to reach that second address from my local laptop, I get the same failure. Could you explain what is going on here? When using the ‘tracert’ to timextender-api.azurewebsites.net command in the command prompt on my local machine I see that it forwards to waws-prod-am2-061.cloudapp.net. 

When we try to do the same on the TX Azure VM, it times out on the first step. Do you have any advice on how to proceed here? Could it still be a Firewall issue on our VM?

--- UPDATE ---

The tracert on our TX Azure VM is not working by design so we cannot use this to find the cause of our problem.

There is onother aspect that caught our attention. On the TX v20 Firewall configuration it is mentioned that we should be able to connect to waws-prod-am2-061.cloudapp.net but this is not possible from both our TX Azure VM and my personal laptop (as mentioned before). However, the timextender-api.azurewebsites.net address seems to forward to a slightly different address as you can see from the third screenshot in my previous comment. That address is waws-prod-am2-061.westeurope.cloudapp.azure.com (contains ‘westeurope’). This address is actually reachable over port 443 from both my personal laptop and the TX Azure VM.

Why can we still not validate our ODX Secret on the TX Azure VM? 

Per response on your support ticket, please see if creating a firewall rule to allow traffic on ports 11000-11999 will resolve this issue. This is described in the troubleshooting section at the bottom of the following KB Article related to the pre-login handshake failed error: https://legacysupport.timextender.com/hc/en-us/articles/360039888171-Configure-your-Firewall-TimeXtender-v20

It is not completely clear from the article if this concerns inbound or outbound network activity. We are currently investigating with a specialist and our first impression is that it is outbound (instead of inbound that is mentioned in my support ticket via mail). This is also confirmed by this Microsoft article: “In particular, ports in the range must be free of any other outbound blockers”.

Solution was indeed opening outbound port range 11000-11999 in our firewall. Whilst our network specialist was not really fond of this adjustment, we could not specify the address so the destination had to be ‘any’. They said that, for performance reasons, the firewall does not resolve DNS so an outbound rule to for example ‘*database.windows.net’ is not supported in our situation.

Curious about how other TX implementations are designed when using a strict firewall for both inbound and outbound network traffic. Concluding, I would like to add that the TX article could elaborate a bit more on this specific type of traffic. It is not stated that a firewall rule to ‘any’ might be required for this. Also, the TX article does not stat clearly that it concerns outbound traffic.

Have updated the KB article to clarify that the rule needed to allow traffic on ports 11000-11999 applies to outbound traffic.

Reply


Terms and ConditionsCookie settings