I'm glad the payload was usable and the author has fixed their problem, it's an interesting challenge.
However, there are other approaches. A public IP per client isn't going to be nearly as expensive as a VM per client, and lets you route your clients by target. Or you could route by source IP: either by having the client register their IPs, or with some combination with seeing where folk log in from.
Neither is necessary, though, given inspection does appear to work.
I don’t get this comment. Inspection does work but the suggested alternatives don’t.
Having the client register their IPs isn’t tenable for most folks. What’s my IP at the shop? (No idea) Will it change? (Yes) now it’s broken.
Seeing where folks log in from isn’t nearly the same as where their UniFi networks are located. (Store vs home.) Broken.
So neither of the those are robust approaches whereas the author’s solution is bulletproof and simply works in all cases.
No offense, but why suggest “other approaches” that have such major holes? Why not just cheer on the solution that works all the time?
The author framed his issue as a choice between separate VMs (with high cost) per user or decoding the messages. As he, you, and I all say: what he's got does work. I'm absolutely not saying that now he's solved the problem he should do something else. But the choice wasn't between only those two extremes.
This protocol was amenable to inspection, the next might not be.
I use NextDNS, one of the features it provides is letting you register a source IP so requests from your network "just work". It might not be a mainstream consumer feature, but neither NextDNS nor managed Unifi controllers are mainstream consumer products.