Azure service bus relay connecting to unknown ip address: 40.112.124.x:9352

We deliver on-premise software that is exposed to the cloud using Azure Service bus relay, the basic code we use to expose is as follows (I have removed everything identifiable):

    ServiceHost sh = new ServiceHost(typeof(BasicHttpEntityService));
    BasicHttpRelayBinding basicHttpRelayBinding = new BasicHttpRelayBinding();

    Uri uriEndPointAddress = ServiceBusEnvironment.CreateServiceUri("https", "ourdomain", "test-url-appendage");
    m_shRelayServiceHost.AddServiceEndpoint(
      typeof(IMyService),
      basicHttpRelayBinding,
      uriEndPointAddress
    ).Behaviors.Add(
      new TransportClientEndpointBehavior
      {
        TokenProvider = TokenProvider.CreateSharedSecretTokenProvider(
          "MyUser",
          "MyPassword")
      });
    sh.Open();

This works fine at most of our customers, however, one of our customers has a strict firewall policy.

According to the SB guidelines we have found, we asked them to open ports 9351-9354 to ourdomain.servicebus.windows.net. Now we find out that when there is an incoming request, the service connects to both 'ourdomain' (we see this succeeds in Wireshark, and also in the WCF log) AND an unknown (to us) service on 40.112.124.x:9352 (the last octet changes with every request).

I have been able to reproduce the problem in my development environment by disallowing connections to any 40.x.x.x address on any port. This is what happens in the WCF log:

System.Net.Sockets.SocketException (0x80004005): An attempt was made to access a socket in a way forbidden by its access permissions 40.112.124.25:9352

Server stack trace: 
   at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
   at Microsoft.ServiceBus.RelayedConnectionSession.ConnectAsyncResult.&lt;GetAsyncSteps&gt;b__4(ConnectAsyncResult thisRef, IAsyncResult r)
   at Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult result)

Exception rethrown at [0]: 
   at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result)
   at Microsoft.ServiceBus.RelayedConnectionSession.EndConnect(IAsyncResult result)

There is no DNS-request going out during this time, so there is no host name that provides any clues to the function of this outgoing connection.

From my investigation, this appears to be a Microsoft controlled subnet, so I'm fine with the relay service connecting to it, but I would like to know:

Is this additional connection optional?
If not, should we allow the entire subnet?
Could this IP-range change in the future? Is it hardcoded somewhere?

Solution

In the end, we requested support from Microsoft. In short their answers were as follows:

Is this additional connection optional?

No it is not optional. For the relay listener, there is a control channel on port 5671, this connection is always there. Then there is a data channel on portal 9352, this connection established when there is a relay client tries to communicate with the listener.
Could this IP-range change in the future?

Currently, for relay this IP can change, so you need to allow the IP range for the entire datacenter in your region (https://www.microsoft.com/en-us/download/confirmation.aspx?id=41653). The SB product team will be working on to significantly reduce this IP range in the future, to make it much more predictable. There is no exact ETA on this future.

So the good news is they are working on it. The bad news is, that right now, we will need to add a LOT of IP addresses to the white-list to ensure smooth operation.