The Origin IP can never be a Cloudflare IP address. This is what is called the orange-to-orange problem.
When a user wants to visit tmtest what do you expect to happen? What IP address do you expect Cloudflare to use when it wants to connect to the origin for tmtest? How have you configured the DNS to respond accordingly? Do you want users to connect to the Cloudflare cache for tmtest, or to the Azure web server?
Break the HTTP request into two parts: the DNS lookup, and the CDN fetch.
With tmtest the DNS lookup goes like this, client ask for tmtest and is told by Cloudflare:
tmtest.sigsys.dk. IN CNAME azurewebapptest.trafficmanager.net.
The users device then looks up azurewebapptest.trafficmanager.net, which is configured to return one of tmtesteu, tmtestusa, tmtestau, depending on how the Azure Traffic Manager is configured. So the ATM picks one, and tells the user: the result you want is available at tmtesteu (or whatever). This happens without an involvement of Cloudflares DNS.
The client then looks up tmtesteu against Cloudflares DNS, and as that is Cloudflares DNS returns two of Cloudflares anycast IP addresses.
Regardless of which one of the three is returned, they are all so will return two A records from Cloudflares anycast range.
tmtesteu.sigsys.dk. 92 IN A 22.214.171.124
tmtesteu.sigsys.dk. 92 IN A 126.96.36.199
So the Azure Traffic manager has done nothing really. The IP addresses the client is being told to connect to will always be the same, a pair of Cloudflare anycast IP addresses with no mention of the Azure region specific IP address. It does not matter where the user is, the result is always the same.
So the client now has an address to start the CDN Fetch. The client connects to one of the Cloudflare IP addresses, and makes a HTTP request for
Host: tmtest.sigsys.dk. Cloudflares cache receives the request, and Cloudflares servers are now acting as a client. The Cloudflare cache says “the origin is azurewebapptest.trafficmanager.net, what’s the IP for the origin”. Repeat the process above, and Cloudflare determines that the origin IP address is the same anycast IP address pair. The origin address cannot be a Cloudflare address, error 1000.
If you reverse the clouds, the first lookup will be:
tmtest.sigsys.dk. 92 IN A 188.8.131.52
tmtest.sigsys.dk. 92 IN A 184.108.40.206
The client will connect to a Cloudflare cache. The cache will resolve azurewebapptest.trafficmanager.net, ATM will use the Cloudflare source IP in its decision making process, return one of the three region specific CNAMES, which will in turn return the region specific Azure IP addresses. The Cloudflare cache will then connect to the Azure IP, and fetch the asset, populate the cache, and return an asset to the client. Everybody is happy? The only issue here is that I do not think the Cloudflare source IP will contain any region specific information for ATM to make a valid decision. A region specific address on the Cloudflare cache would be an attack vector to a particular cache, and I do not think that is likely. My guess is that you will always get the same Azure region in the DNS response from ATM to Cloudflare.