I still don't understand what you're trying to do. You were saying that you set a VIP from the public-facing IP (say x.x.x.x) to a private IP, which inside of your network. But, isn't that x.x.x.x the IP those dial-up VPNs are connecting to? Which would never come through the tunnel from the client side. Always comes outside of the tunnel over the internet and hit the physical (maybe a vlan) interface that has x.x.x.x.
This particular firewall cluster has traffic arriving from several interfaces servicing different physical locations and/or department VLANs, all of which have users who interact with what we'll say is public IP 192.0.2.100 that lives on a DMZ VLAN and is a web app firewall software appliance. If the traffic is allowed through the WAF, it is proxied to the real application server that lives on an internal VLAN interface with private IP 10.0.0.100.
So, all the rules allow traffic from all these random interfaces through to 192.0.2.100, no problem.
The same firewall is the termination point for client to site IPSec FortiClient VPN users, and for that user population specifically, we do not want them talking to the WAF, I want to 1:1 map their traffic to 10.0.0.100 even if they were trying to get to the 192.0.2.100, so they don't have to deal with hosts files, custom DNS overrides on their side, etc. I was thinking a VIP to do that mapping, that only applies to the VPN interface, would solve the problem, but it instead broke all traffic. lobstercreed's reply pointing out srcintf-filter sounded like the entire purpose of that command was to solve this problem, where the VIP mapping would only affect traffic from the one single interface, but even with that in place the VIP config still broke all the traffic. So even if you restrict a VIP, it appears to affect traffic from all interfaces either way.