I just ran some download tests of the Ford Trimotor.
I tried this three times, and identified two IP addresses in the 13.107.0.0 range, the last one was 13.107.246.64. When I abort the download, that IP address ceases to pop up in Wireshark.
When I search for this in the list of Azure IP’s it does not appear there. That suggests that either MSFS is downloading content from CDN servers that are not part of the Azure range, or that list I was referencing is out of date.
According to Robtex that IP is owned by Microsoft, but is in Redmond, US.
When I was downloading it was coming in at the often seen ~2Mbps.
Another download kicked off, now coming from 40.90.65.40, now at a blistering 3Mbps. Again, this one is not present on the Azure IP list.
I’ve started to build a list of IP’s, adding them to a local firewall rule to block access to those IP’s.
With these two in place I couldn’t download anything from the MP, so I relaunched the sim. I downloaded my test package again, the Ford Trimotor, and I’m now downloading at ~80Mbps.
The current IP is 104.212.67.228.
So there are clearly some CDN’s out there that either have issues, or are overloaded. I’m starting to think I should have kept this to myself, as everyone will jump on the working ones now. 
This is what I’m looking at in Wireshark. Capture filter is looking at only TCP 443 traffic.
The windows firewall rule is very simple:
New Outbound rule:
Add the IP’s to block in the bottom window:
Action is block:
Now give the rule a name, and finish.
At one point I noticed that downloads were being blocked, but those two IP’s were not appearing anywhere. I closed the sim, and it then failed to load, so there may be some unwanted side effects of this method. It’s wide open so I could try constraining it to only 443 traffic.
I’ve had mixed results so far, and built up a list of CDN servers that are giving me slow downloads. Annoyingly though, sometimes it seems to work, and does use an IP not in the list, then others it refuses to use something else so refuses to download at all.
On a hunch I redid the rule as an incoming rule. The theory here is that the client will be able to communicate out, never get a response, assume the server is down, then pick the next. This does allow the sim to launch, but then still downloads from one of those IP’s that it is supposed to block. On time I did get a repeat of a 70-80Mbps download rate, but with incoming only 99% of the time it downloads at 3Mbps.
I’m pretty convinced that this problem is at the CDN level, and some are offering nothing more than ~3Mbps pretty consistently.
The list I have so far is:
40.90.65.161
40.90.65.164
40.90.65.128
13.107.213.57
13.107.213.64
13.107.213.67
13.107.246.57
13.107.246.64
13.107.246.67
Looking back up at this list as I add those IP’s that are giving ~2-3Mbps, It looks like these /24 networks are affected, so 40.90.65.0/24, 13.107.213.0/24, and 13.107.246.0/24.
The one IP that gave me pretty good speeds, though I have seen better in the past very rarely, was:
104.212.67.228
If I could find a reliable way to lock it to that somehow I would.
Getting ~23-30 Mbps from 40.90.65.2
Getting 3Mbps from 104.212.67.148, which is the same network as the IP where I was getting 80Mbps, so that’s that idea gone. 
With the outgoing blocks in place, if MSFS tries to use one of those blocked IP’s it will fail to load correctly, instead showing a screen that looks like it wants to perform a full re-install. Quite why it equates a loss of connectivity as the sim not being installed is beyond me.
ALT+F4 from this, then launch the sim. I had to do this three times before it chose the IP above, which is not blocked. It doesn’t look like the sim has a robust method of checking for which servers it can actually get to, and instead gives up too easily.
Actually if you leave it on on that screen long enough it does reconnect. I just wasn’t brave enough to hit Continue in case it kicked off a re-install from scratch.
