Since adopting Juniper's Network Connect as our SSL VPN offering, we have run in the mode "Split Tunnel with Route Change Monitor."
We have had issues with Bonjour Networking (via Ruckus campus music software; iTunes has been OK) and Microsoft's"Wired Autoconfig" setting, but we have been able to work around those.
However, there appears to be an inherent and unavoidable conflict between zero-config network products and Network Connect's "Split Tunnel with Route Change Monitor" setting. We have been getting more reports of products conflicting with the route change monitor, and we are staring at the beginning of 802.1x deployment. I forsee that telling our users to stop using zeroconfig stuff will not be an acceptable answer much longer, and telling users not to use 802.1x is not acceptable.
So, it appears near-certain that we will have to shut off the Route Change Monitor on split-tunnel in the next few weeks.
My question is: how real is the security risk in disabling Route Change Monitor? I really don't like the idea that our users will think traffic back to our central campus is encrypted, when something has mucked with the routing table and maybe there isn't an effective secure tunnel any more.
This is a request for "Any thoughts?" rather than a request for a specific solution.
well in my opinion if you allow split tunneling monitoring the route when they change is going to do very little for your security. So we always disable split tunnel but if you want to keep it enabled i dont think there is more protection in enabling route monitor.
thinking of it logically split tunnel says the specified networks are goign through the tunnel and everytyhing else is not. If you are worried about some one hijacking your connection than sure route change is good but no one does that any more when they can infect your computer through the split tunnel and use your tunnel to get all the data in and out while making it look like you did all the trafficing