Thank you, however this doesn't appear to be applicable in our scenario. The closest I can do is setting the source interface of the RADIUS connection to be from the outside interface which I gave a try just in case however that doesn't work as it then sources it from the public IP.
In the workaround the reason that works is because with the commands like http, ssh, snmp-server, etc although you specify the outside interface you are also specifying the IP from which it should work however in the case of RADIUS it's specifying the source interface to use to communicate.
In the workaround they also show that they are getting drops however in our case packet-tracer shows that things are passed. Unfortunately I couldn't get an actual packet capture to work to properly verify this though.
One other thing I did start trying as well was a route based VPN as I wondered with it properly in the routing table and the RADIUS connection set to use routes lookup instead whether that would work however once I established the VPN I could only get it to work from Azure to the Firepower and traffic from the Firepower to Azure failed. It came up with suboptimal route lookup and then resorted to using the public gateway instead. Posting this here in case that's another option that it may be worth resolving as at the moment I put it back to policy based.
Phase: 14
Type: SUBOPTIMAL-LOOKUP
Subtype: suboptimal next-hop
Result: ALLOW
Elapsed time: 465 ns
Config:
Additional Information:
Input route lookup returned ifc azure-vpn-vti is not same as existing ifc outside
Doing adjacency lookup on existing ifc outside
Phase: 15
Type: NEXTHOP-LOOKUP-FROM-OUTPUT-ROUTE-LOOKUP
Subtype: Lookup Nexthop on interface
Result: ALLOW
Elapsed time: 1860 ns
Config:
Additional Information:
Found next-hop 91.X.X.1 using egress ifc outside(vrfid:0)
