If I get you right, the web client somewhere in the world is sending a connection request to port 443 at the public IP of the CHR, and the CHR port-forwards that request to 10.100.124.207, so the request goes through the OpenVPN tunnel and reaches the server connected to your 3011.
Now think about the response: the server sends the response to the source IP of the request, which is a public one (if I got you right, see above). But on the 3011, the route via the OpenVPN tunnel is used only for destinations in the 172.x.. range in your Azure subnet, so the response is routed out via the WAN of the 3011, and doesn’t even get src-nated (because the response is not the first packet of a session as seen by 3011’s connection tracking, so it is not handled by the rules in NAT table), hence even if your ISP doesn’t drop it and it makes it to the client, the client ignores it because it doesn’t come from the public IP of the CHR to which the request has been sent.
So you have to engage policy routing with connection-mark at the 3011 to make sure that responses to requests that arrived via the OpenVPN tunnel will be sent via the OpenVPN tunnel as well; as such response reaches the CHR, it will get “un-dst-nated” and forwarded to the client from the address the client expects.
The details are here. Read the last paragraph of that post first to understand the relationship to your case. Think about the OpenVPN tunnel as about another WAN of the 3011.
Another approach would be to src-nat the request at the CHR as forwarding it to the tunnel, so the server next to the 3011 would see it as coming from one of your private subnets on Azure, but you would lose the information about the actual address of the client. If you don’t need that address, it is way simpler that to implement policy routing for the first time in your life.