adimcev
Posts: 356
Joined: 19.Oct.2008
Status: offline
|
The trick is within the routing table, at least from Windows VPN clients' point of view.
What you want to do falls into the category of "controlled" split tunneling. Ideally, you want this level of control on the server side per user/group.
Users need admin rights to mangle the routing table, that's why you should not use CMAK to solve the routing issues, as an issue is not solved at the expense of the creation of a security issue(maybe that's why Jason asked you about CMAK).
There is a limitation in respect with the options passed by the VPN server through IPCP, and from here the fun begins. You can pass routes through DHCP Option 249, which works great(although there is an unless here too), without the need of admin rights, solving even the same subnet problem without the expense of the security issue introduced by CMAK.
But this do not fit your scenario.
Note that when you uncheck the "Use the default..." box, you will get a route through the VPN tunnel only for the subnet on which the IP address received by the VPN client belongs(I suppose you know the "cases" of 10.0.0.0/8 or 172.16.0.0/16).
The "pure" split-tunneling occurs when the VPN client is "willing" by a form of "routing" to pass the packets receive on its physical interface over the VPN tunnel to the corpnet behind the VPN server. You do not have to uncheck the "Use the default..." for this to happen. Read this and this. A host firewall on the client, properly configured may help in this case.
The "normal" split-tunneling occurs when the VPN client access the corpnet over the VPN tunnel, and other destinations directly through its physical adapter, and it is discarding the "incoming" traffic received through its physical adapter "destined" to the corpnet(no form or routing whatsoever is enabled on the client). For this you uncheck the "Use the default..." option. The danger is that(other than the user escaping your content filtering and restrictions), for example the VPN user to connect to a malicious external web site, where an attacker can exploit, say a browser vulnerability that allows him "to remotely execute code" on the VPN client's computer while the user is still connected to the corpnet, resulting in some packets "unwillingly" reaching the corpnet. An ambiguous situation which may have been prevented by blocking split-tunneling.
You may want to control the "level" of split tunneling, that is, to still send all the traffic over the VPN tunnel, except the traffic destined to the local subnet to which the VPN client is directly connected, the default Windows VPN clients behaviour.
Or a deeper level of control, that is, to send over the VPN tunnel the traffic destined to corpnet, while specifying which destination are allowed to be accessed directly by the VPN user through the physical interface.
The most secure configuration is when all traffic is sent over the VPN tunnel, and the traffic sent to the local subnet directly connected to the client's physical interface is blocked. Additionally there is a host firewall installed on the VPN client.
For the moment, the only Microsoft VPN server that gives you some server side control over some of these settings is this. ISA can force with the help of VPN-Q 2006/2008 certain checks over the VPN client's configuration.
......................................................
Coming back to your case, and to your original question, we must say that you do have a certain of "controlled" split tunneling, because you own the local subnets and firewalls, the client is not connecting from a public wireless net.
So in the end, by unchecking the "Use the default gateway..." option, the client will still access what you want to access.
Actually, you even inspect the client's encrypted traffic, as you control the remote VPN server, which happens to be an ISA firewall.
As a matter of fact, if you would have not controlled the remote VPN server, would have been *more* secure for you and your network to enable split-tunneling by unchecking the "Use default gw ....", because the VPN traffic is passing encrypted through your local network firewall, creating the posibility of a tunneling issue, in case the folks on the other end deployed a "relaxed" policy for the VPN clients traffic destined to the Internet, because their VPN server does not allow them granular access per users/groups. A host firewall might have been your only solution to get some control on that client.
Funny, isn't it ?
I've mentioned the route adding possibility because I thought that may be a longer time solution, without the need of creating an s2s for a single user.
The s2s solution would have been the most secure, as you would inspected the traffic on your local network firewall, although at the expense of some additional overhead on the local VPN gateway.
Adrian
_____________________________
Blog: http://www.carbonwind.net/blog
Get Our ISA 2006 Book!: http://tinyurl.com/2gpoo8
|
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
Using split tunneling safely? - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread
