Inside source NAT between two crypto map VPN tunnels on the same 'ip nat outside' interface ?

Title is basically the ;tldr... Here is the long story:

We have a VPN concentrator (Cisco ASR 1K) with over a hundred 'legacy' policy based VPNs within the same crypto map on the outside interface. These are all external/third party connections so for some of these we do plain routing, for others we do some kind of NAT due to IP overlaps (also legacy ip nat inside/outside setup).

We are now, for the first time, in a situation where two remote ends need to communicate to each other through us. One of them is normally routed (no NAT) on internal IP addressing (they got a part of our 10/8 addressing) and for the other one we do a dynamic source NAT/PAT behind one of our public IPs as they do not accept our private IP addressing.

Diagram!

The issue is that the source NAT does not work from VPN1 to VPN2 as the traffic comes in from VPN1 on the outside interface ('ip nat outside'), turns around and leaves to VPN2 over the same interface, so it doesn't follow the inside->outside logic.

In a lab (old school GNS3 Dynamips...) I got this to work by doing a policy based route on the outside interface which matches traffic from VPN1 going to VPN2, and sets the inside interface as the next hop. This forces the traffic to an inside router which will just turn it around and send it back to the VPN concentrator so it does follow inside to outside NAT logic. However, when we tried this in production it just doesn't work. I don't even get any output on "debug ip policy" and shows no matches on the PBR route-map. I've also looked into NAT NVI but our box does not support that.

Worst case I am thinking of things like 1) converting VPN1 to a route based setup so I can do ip nat inside on the tunnel interface (but the third party probably doesn't support it). 2) move VPN1 to a separate interface with ip nat inside on the same router. 3) even move VPN1 to a different router.

I've opened a Cisco ticket as well but was hoping someone has ran into the same issue before and has a potential easy fix.

Here's a heavily scrubbed version of the relevant configs.

#crypto map crypto map CRYPTO 1 ipsec-isakmp description IPSEC to VPN1 set peer x.x.x.x set transform-set xxx set isakmp-profile xxx match address VPN1 reverse-route crypto map CRYPTO 2 ipsec-isakmp description IPSEC to VPN2 set peer y.y.y.y set transform-set yyy set isakmp-profile yyy match address VPN2 reverse-route static # crypto ACLs ip access-list extended VPN1 permit ip 10.0.0.0 0.255.255.255 10.10.10.0 0.0.0.255 permit ip 1.1.1.0 0.0.0.255 10.10.10.0 0.0.0.255 ip access-list extended VPN2 permit ip 2.2.2.0 0.0.0.255 1.1.1.0 0.0.0.255 # inside source NAT/PAT ip nat pool VPN2_POOL 2.2.2.1 2.2.2.2 netmask 255.255.255.0 ip access-list extended VPN2_NAT permit ip 10.0.0.0 0.255.255.255 1.1.1.0 0.0.0.255 ip nat inside source list VPN2_NAT pool VPN2_POOL overload # interfaces interface GigabitEthernet0/0/0 ip address b.b.b.b ip nat outside negotiation auto crypto map CRYPTO interface GigabitEthernet0/0/1 ip address a.a.a.a ip nat inside # policy based routing test - works in lab but not in prod ip access-list extended MULESOFT-TO-OTM-PBR permit ip 10.184.0.0 0.0.15.255 129.155.0.0 0.0.255.255 route-map MULESOFT-TO-OTM-PBR permit 10 match ip address MULESOFT-TO-OTM-PBR set interface GigabitEthernet0/0/1 interface GigabitEthernet0/0/0 ip policy route-map PBR