This article was previously published under Q248346
This article has been archived. It is offered "as is" and will no longer be updated.
When you are using Network Load Balancing (NLB) to load-balance a cluster of Layer 2 Tunneling Protocol (L2TP) servers, clients experience broken L2TP sessions when a server is added to the cluster.
Microsoft does not support using NLB to load-balance L2TP trafficbecause some client sessions are torn down as User Datagram Protocol (UDP) datagrams are rebalanced to the new server when you add a server to the cluster.
An L2TP session uses UDP datagrams that are assigned to port 1701. NLB is not able to track the status of the L2TP session or its termination. The same behavior occurs when you are using L2TP/IP Security (IPSec) or just IPSec because IPSec or IKE (UDP 500) control traffic is encrypted. Therefore, NLB is not able to determine when the tunnel "Delete" or the IPSec Oakley "Delete" message is sent to terminate the tunnel or the SA.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.
NLB Behavior with PPTP
This problem does not occur when NLB load-balances Point-to-Point Tunneling (PPTP) traffic because a PPTP session maps perfectly to a TCP connection using TCP port 1723. NLB is able to track TCP connections. NLB watches for TCP "FIN" packets to determine when a connection terminates.
When a cluster host is brought back online or a new cluster host is added to a PPTP cluster, NLB waits for TCP connections to end on the existing hosts before transferring some of the load to the new server.
NLB Behavior with L2TP
With UDP L2TP traffic, when a server joins the cluster, some of the L2TP sessions on the existing cluster hosts are broken and moved to the new server.
NLB Behavior with Both PPTP and L2TP
NLB can service virtual private network (VPN) clients with both PPTP and L2TP when a cluster host goes down. Sessions to the down server are lost but new sessions are directed to the surviving cluster hosts.