In all our discussions of remote access solutions for VPN, we will be working with connections over the Internet. This means we are reliant on the Internet, which is the intermediate network, to provide certain services and transports to the users. You need to check several items to make sure the Internet communications system will be able to connect your users to your VPN server. To create a VPN connection to a VPN server across the Internet, you need to verify the following items first before any connections can be created:
The VPN server
The VPN server must be
VPN traffic must be allowed to and from the VPN server. Configure packet filtering for PPTP traffic, L2TP/IPSec traffic, or both types of traffic on the appropriate firewall and VPN server interfaces connecting to the Internet and the perimeter network. For more information, see Appendix B, “Configuring Firewalls for VPN.”
In most cases, you want to reference the VPN server by name rather than by an IP address, as names are much easier to remember. You can use a name (for example, VPN1.example.microsoft.com) as long as the name can be resolved to an IP address. Therefore, you must ensure that whatever name you are using for your VPN servers when configuring a VPN connection can be resolved to an IP address using the Internet DNS infrastructure.
When you use names rather than addresses, you can also take advantage of DNS round-
To be reachable, the VPN server must be assigned a public IP address to which packets are forwarded by the routing infrastructure of the Internet. If you have been assigned a static public IP address from an ISP or an Internet registry, reachability is typically not an issue. In some configurations, the VPN server is actually configured with a private IP address and has a published static IP address by which it is known on the Internet. A device between the Internet and the VPN server
Previously when using L2TP/IPSec, there was an issue with going across NAT boundaries because IPSec, which maintains the encrypted tunnel for the communications, could not negotiate security associations (SAs) across NAT devices. This issue has been resolved by Microsoft with the implementation of NAT traversal (NAT-T). NAT-T allows Internet Key Exchange (IKE), the negotiation protocol of IPSec, to negotiate security associations (SAs) across NATs. NAT-T is a feature of Windows Server 2003, and you can add NAT-T to all client operating systems in one of the following ways:
When using Windows 98, Windows 98 SE, Windows Me, and Windows NT 4.0, you can apply the Microsoft L2TP/IPSec VPN Client, which has NAT-T included in the package.
When using Windows XP or Windows 2000, a new
Although the routing infrastructure might be in place, the VPN server might be unreachable because of the placement of firewalls, packet filtering routers, NATs, security gateways, or other types of devices that prevent packets from either being sent to or received from the VPN server computer.
There are two approaches to using a firewall with a VPN server:
The VPN server is attached directly to the Internet, and the firewall is between the VPN server and the intranet. In this configuration, the VPN server must be configured with packet filters that allow only VPN traffic in and out of its Internet interface. The firewall can be configured to allow specific types of remote access traffic.
The firewall is attached to the Internet and the VPN server is between the firewall and the intranet. In this configuration, both the firewall and the VPN server are attached to a network segment known as the perimeter network (also known as a demilitarized zone [DMZ] or a screened subnet). Both the firewall and the VPN server must be configured with packet filters that allow only VPN traffic to and from the Internet.
For the details of configuring packet filters for the VPN server and the firewall for both of these configurations, see Appendix B, “Configuring Firewalls for VPN.”