L2TP & Split Tunneling

Unanswered Question
Sep 13th, 2007
User Badges:


This is more of a conversation, looking for input on some issues that have come up while trying to get L2TP in place.

The PIX in question (Pix 515 ver 6.3) has been running a VPN in tunnel mode that allowed cisco VPN clients to connect. However, a change in the network layout has the PIX outside interface IP address change to a private address. A Load balancer now sits infront of the PIX. From my reading, i had to change my VPN from tunnel to transport mode. Since the VPN call would be made to the Load balancer interface, which would then NAT to the Outside PIX interface. This NAT process would break IPSEC Transport, and tunnel is what i went with. In so far could someone please tell me if this decision was correct? As the direction i took led me to the next question:

L2TP Transport mode is what i have now deployed in my test environment. Works fine. Except for Split tunneling. L2TP does not support split tunneling. This is what i have read so far and i could be wrong. But so far it does not suport split tunneling. I thus have 2 questions as regards split tunneling:

What are the thoughts on split tunneling and the dangers it poses to a network when enabled, And are there any work arounds to allowing clients connected to the VPN via L2TP access to the Internet?

many thanks for your time.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
didyap Wed, 09/19/2007 - 13:23
User Badges:
  • Silver, 250 points or more

L2TP and split tunneling can work in your case. On the client side uncheck the box for "Use default gateway on remote system". This is in the General tab of the Advanced TCP/IP settings. On PIX configure following group policy parameters

split-tunnel-policy tunnelspecified

split-tunnel-network-list value split_tunnel

split-dns value cisco.com

intercept-dhcp enable

Also configure access lists with the split tunnel network as source network

fembsen Thu, 09/20/2007 - 02:48
User Badges:


Split tunneling opens a backdoor to your protected network via the VPN client so care must be taken.

I had a similar configuration problem with 3000 series VPN concentrators. The concentrators now work as dhcprelay to an DHCP server on the inside network. The DHCP scope has, among others, option 249 enabled (classless static routes). When clients receive an IP address also the routes are set (in the client VPN config the option 'use desfault gateway on the remote network' has to be unchecked).

You might be able to do something similar.

Regards, Frank


This Discussion