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?
Best answer by KajEmergo
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.
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?
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.
The last line in this article is the most confusing of all:
“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.” That is not something anybody can use to define clear firewall rules!
Also in our case the Ingest Server(application) is on an Azure VM surrounded by a Vnet that is firewalled by a Palo Alto(also Azure resource...but). I’m told that Palo Alto does not understand Azure Tags..😢. So in that case it actually is not Azure native communication(between different tenants(TimeXtender-Client) anymore, but actually ‘on-prem’. So in that case you have to go to port 1433. I’m not sure if this means we will pay for ingress/egress now, but it sounds pretty plausible.
Dear, we are still in a blocked situation rolling out the new TimeXtender with repository in TimeXtender cloud. If the Ingest server is on a VM in Azure(our tenant), what are the required outbound firewall rule(s) for the SQL repository if we can not use Azure Service tagging?
if your customer has chosen a firewall application that cannot easily differentiate Azure service tags or use DNS to define rules, you will have to use the list of IP addresses for services in regions to define the IPs you should open up. See here for the list. If your network architecture is such that Azure sees the traffic as to be routed on the Azure backbone, it will do so (over IPv6 usually) and use dynamic ports. If your VM is seen as outside the Azure boundary, it will use port 1433 for the outbound connection (return connections are also in dynamic ports).
If your networking architecture differs from Microsoft's standards, then those differences need to be taken into account.
HI @rory.smith , thank you for your confirmation. That was my thought as well, but I just wanted it to be confirmed.
I think no matter what you do in Azure, if it is Azure2Azure, Microsoft will always route it over backbone, which inquires the dynamic port ranges(for SQL) and the worker nodes.
I wonder if the IPs in the link you shared are really that actual and for the worker nodes FQDN’s as well!?
Also we did a quick test on the 2 SQL FQDN of the TimeXtender respositories, and that IP address is not even in the list; sql-instances-prod.database.windows.net > 20.61.99.193 sql-instances-prod-002.database.windows.net > 20.61.99.193
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
