Split Tunneling VPN

Split Tunneling

Split tunneling occurs when a remote VPN user or site is allowed to access a public network (the Internet) at the same time

that he/she accesses the private VPN network without placing the public network traffic inside the tunnel first. If split

tunneling were disabled, the remote VPN user or site would need to pass all traffic through the VPN headend, where it could

be decrypted and inspected before being sent out to the public network in the clear. For example, a remote-access user who

dials his/her local Internet service provider (ISP) and connects to corporate over an IPSec client has two options. The first has

the user passing only corporate-bound data over the VPN connection. Browsing the Web would occur directly through his/

her ISP. The second option has the user passing all traffic (including Internet traffic) to the headend first, where it is then

routed in the clear either to the corporate network or out to the Internet. Deciding between the two technologies often

depends on the amount of trust you can place in the remote sites or users. To increase the level of trust for these users,

consider using additional available security technologies, such as personal firewall or virus scanning. Remote sites that wish

to utilize split tunneling should have a stateful firewall on their premises to control the cleartext traffic allowed into and out

of the remote site. Likewise, a remote user should run a personal firewall to filter traffic and carry out virus scanning while

the VPN is connected and when the VPN is not. Even when split tunneling is disabled, a personal firewall is often necessary

because the user is not always connected over the VPN. A traveling user may connect in through high-speed Internet access

in a hotel and elect to browse the Web while not connected to the corporation. Without a personal firewall, that system is

open to attack whenever it is not connected to the VPN.

Similarly, many hardware VPN devices utilize NAT and market it as a form of firewalling. In the authors' opinion, NAT is

not a security feature and should not be deployed as such. Even though addresses are hidden, no packet filtering or

sequence-number checking is occurring, leaving systems protected by NAT open to brute-force attacks against them. A

security perimeter that relies solely on NAT is indeed not a security perimeter. When utilizing these devices, it is important

that you provide a personal firewall for the PCs residing behind the device. Even if split tunneling were disabled, a personal

firewall will be necessary if that host is mobile (as in the case of a laptop).

When considering the security risks of enabling split tunneling, it is too easy to conclude that it should never be considered.

Actually, disallowing split tunneling creates an enormous load on the VPN headend because all Internet-bound traffic needs

to travel across the WAN bandwidth of the headend twice. This use of WAN resources is not an optimal one, and it often

leads to the decision to implement the appropriate security technologies at the remote sites to allow split tunneling to occur.

In SAFE VPN, remote sites were assumed to have split tunneling enabled unless otherwise specified. If split tunneling were

disabled, the designs would not change, but the performance and scaling considerations might change slightly because of the

increased traffic load on the headend.