Who rated this post

IKEv2 tunnel narrowing most definitely caused VPN interoperability problems at one point and is a good area to investigate, but to my knowledge all those bugs were fixed long ago.  That could explain why some traffic makes it and some doesn't if the problematic traffic was outside where the tunnel was narrowed by the responder, and the initiator didn't realize it or didn't process the narrowing properly.  I assume you have tried initiating the tunnel separately from each peer as the initiator and the problematic behavior remains no matter the original initiator of the tunnel?  If the problem only happens when a certain side is the initiator, that could well be a narrowing or subnets/Proxy-IDs issue.

A bit unlikely that intervening NAT is causing the issue, as NAT-T should start automatically.  I assume there is no NAT occurring somewhere between the VPN peers?  Usually NAT either exists between the peers or it doesn't, this won't normally change over time unless there are different ISPs in use, or the network path upstream of the peers is changing without your knowledge.

Seems unlikely but as far as fragmentation issues, are you allowing Type 3 Code 4 ICMP datagrams inbound to your gateway from any source on the Internet?  If you are not, Path MTU discovery will not work correctly in the event of a sub-1500 MTU occurring in the network path.  Once again, the low MTU may be intermittently occurring if the upstream path is changing without your knowledge, or you are unexpectedly failing over between multiple ISPs, or better yet experiencing traffic asymmetry between them.  If there is more than one ISP in use for this customer, completely disable one and fully test each ISP path one at a time.  Once again really seems unlikely that frags/MTU would affect VPN connectivity to only one Azure host IP within the tunnel.

Your earlier message about seeing some of these packets being dropped for ssl inspection caught my eye, if HTTPS Inspection is in use on the gateway make sure you are not specifying "Any" in any of the Destination and Service columns of all your HTTPS Inspection policy rules.  Traffic entering a VPN is not supposed to be inspected by HTTPS Inspection anyway, even though it is leaving on the interface that matches dynamic object "Internet".  Might be interesting to add an IP-based rule at the very top of your HTTPS Inspection policy matching all destination IPs accessible through the VPN tunnel with an action of Bypass and source Any, category Any just to make sure it is finding a bypass during the first pass on the HTTPS Inspection policy, and not being improperly pulled into active streaming for the second pass.