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.
