Security Concerns behind pushing Split Tunnel routes...

[PhillyEagles_]

.... to internal resources? We are using Split Tunnel resources/routes on the Network Connect. Network Connect is only for the corporate issued Laptop's that we control. The question is how granular do you go with the resources without adversely opening yourself up to security?

1) Fist off, if I add fewer routes with larger scopes like 10.1.0.0/16; 10.50.0.0/16; 10.170.0.0/16 the I run the risk of network conflicts if one of my thousands of users visit a hotel or business that has a similar network. Now, I know I can not guarantee network conflict avoidance but I feel it is my responsibility to do my due diligence to at least reduce the possibility.

2) Now on the other hand if I push each VLAN from each office I run into A: A lot of routes being pushed to the PC. At what point with the PC start to see performance issues? B: Now I've mapped out the internal network. What security concern should I now be scared of?

My thoughts are since it is a 'directive' to allow Split Tunneling we open our selves up to the security concerns and potential network conflicts. We don't care about home network. But it becomes what is more important to the institution. If Security is a concern then you run the risk of more user calls about not being able to work. If functionality is more important then we have to open it up and ... map the network.

I have thought about creating 1 realm with reduce scopes/subnet masks and then another realm for back just in case the user does run into this issue where we map out the network on the PC. Then if we do that the user will more than likely keep using it so what is the point? :-)

Another thought was to create a single route that points to another device, (Netscreen firewall/router) that knows all the internal networks. It adds a layer of single point failure for the SA but we have the security back and the user gets all internal resources


I would appreciate your thoughts guys and gals. Thanks

[Jickfoo_]

It's a good question. You almost have to think about how your corporate network is designed more then anything. I mistakenly created DMZ subnet a while back with a 192.168.0.0/24 address. Now some users log into netconnect and are coming from a 192.168.0.0/24 network, obviously it creates a problem. This is the reason why I can't do split tunneling.

If you keep all server resources a 10. address I think you'll find that a majority of your remotes will be coming from a 192.168.0.0 range.

One thought I have is that perhaps you could create a Host Checker Policy that checks the source IP and alerts them if there was a conflict. I cringe at the thought of pushing all those routes down to users. You'll have to update that every time you make a change.

I always wondered if NAT would be a good solution. (is anyone doing this?) I'd love to get all my remotes on Virtual Machines back here. Would solve a lot of our problems.

Sorry to ramble. I look forward to other posts on this issue.