The following excerpt is from Chapter 7 of the free e-book "The tips and tricks guide to securing Windows Server...
2003" written by Roberta Bragg and available at Realtimepublishers.com. Click for the complete book excerpt series.
VPN design issues for L2TP/IPSec
VPNs are good choices for secure communications because data is tunneled from one network to another across one or more other networks. Logically, it's as if a single tunnel connected the client directly to the server with no other devices between. Physically, such is not true, although all packets are encapsulated within the tunneling protocol, which affords some protection. Security, however, is ensured because of the data encryption and other characteristics of the tunneling protocols. Computer authentication, data integrity and protection from replay attacks are common benefits. In addition, user authentication and access control can be enforced. Microsoft Windows .NET VPNs can exist as client-to-server VPNs and as endpoint-to-endpoint (server to server) demand-dial VPN connections. Figure 7.22 illustrates the client-to-server VPN that you have indicated is your design. Communications are tunneled and encrypted between the client and the server. Subsequent access by the client to resources on the network, although it is tunneled and encrypted between the client and the VPN server, is not tunneled or encrypted between the VPN server and the internal resource.
Figure 7.22: Client-to-server VPN.
Figure 7.23 shows the endpoint-to-endpoint configuration. All communications that originate in one network with a destination of another network are tunneled and encrypted between the Routing and Remote Access Service (RRAS) servers on the network boundaries. Communications between the client and the VPN server on one network -- or between the VPN server on the other network and other resources -- is not tunneled or encrypted.
Figure 7.23: Endpoint-to-endpoint VPN.
Either configuration can work with L2TP/IPSec, but the use of the client-to-server model is more likely to produce unexpected results as the user might move and his or her connection might be unhampered at some locations and be blocked at others. In the endpoint-to-endpoint configuration, it should be easier to determine whether NAT is the problem.
A standalone Windows .NET RRAS server can be used as a VPN tunnel endpoint, as can a Windows .NET server that has been joined in a domain. Question 7.4 described a standalone RRAS server and available authentication methods. The advantage of using a domain member is that domain user accounts can be used for authentication and the user database does not lie on the RRAS server. One advantage to this setup is that, should the server be compromised, no useful account database information can be gained. In addition, as company needs grow, more servers can be added and user accounts do not have to change. Client computer domain membership and user accounts can also be used to push security settings to users and client machines, something unattainable with a standalone server.
You don't say whether your situation involves domain membership for the VPN server, and this information might have a bearing on your problem. Using certificates for authentication is also easier in a domain environment. Because an Enterprise Certification Authority (CA) can be used, certificates can be published to Active Directory (AD) and are then automatically available for user authentication. Computer certificates, which are required for the default implementation of L2TP/IPSec, can also be automatically published, and thus are readily available. However, there are numerous issues here. The CA must be correctly configured and protected. If it is compromised, all the certificates it has issued are compromised, and thus the identity of any client or server using these certificates is in doubt.
Click for the next excerpt in this series: VPN protocol choices.
Click for the book excerpt series or visit Realtimepublishers.com to obtain the complete book.