Finally found some time to check this; apparently we have this problem (with split tunnel at least) only if we include the IP pool ranges in the intranet applications (if the network is not included in the split tunnel, the client tries to route the packet from it's default gateway rather than to the tunnel.
I think we'll just configure the intranet apps so that the pool range is not included and this should circumvent the issue.