Compartir a través de

Router-to-router VPN design considerations

  • Artículo

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Router-to-router VPN design considerations

To prevent problems, you should consider the following design issues before you implement router-to-router VPN connections:

  • PPTP-based or L2TP/IPSec connections

  • Installing certificates

  • On-demand or persistent connections

  • Restricting the initiation of an on-demand connection

  • One-way or two-way initiated connections

  • Number of PPTP or L2TP ports needed

  • Configuring firewall packet filters

  • Routing

  • Single hop across VPN connection

  • Creating a remote access policy for router-to-router VPN connections

For more information, see Router-to-router VPN connection.

PPTP-based or L2TP/IPSec connections

A VPN server running Windows Server 2003 provides support for both Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP). When choosing between PPTP and L2TP/IPSec router-to-router VPN solutions, consider the following:

  • PPTP can be used for router-to-router VPN connections for routers running Windows NT Server 4.0 with the Routing and Remote Access Service (RRAS), Windows 2000 Server, or Windows Server 2003 operating systems. PPTP does not require a public key infrastructure (PKI) to issue computer certificates. By using encryption, PPTP-based VPN connections provide data confidentiality--captured packets cannot be interpreted without the encryption key. PPTP-based VPN connections, however, do not provide data integrity (proof that the data was not modified in transit) or data origin authentication (proof that the data was sent by the authorized user).

  • L2TP can be used only with routers running Windows 2000 Server or Windows Server 2003 operating systems. When both types of routers are used, a public key infrastructure (PKI) is required to issue computer certificates to all routers. Routers running Windows Server 2003 operating systems additionally support a single preshared key configured on the answering router and all calling routers. By using Internet Protocol Security (IPSec), L2TP/IPSec VPN connections provide data confidentiality, data integrity, and data origin authentication.

Installing certificates

To use certificate authentication for L2TP/IPSec router-to-router VPN connections, you must install computer certificates, also known as machine certificates, on both routers. For more information, see Computer certificates for L2TP/IPSec VPN connections and Network access authentication and certificates.

On-demand or persistent connections

You must decide whether your router-to-router VPN connections will be on-demand or persistent:

  • On-demand demand-dial connections require that the answering router is permanently connected to the Internet. The calling router connects to the Internet by using a dial-up link such as an analog phone line or ISDN. You need to configure a single demand-dial interface at the answering router. You need to configure two demand-dial interfaces at the calling router: one to connect to a local Internet service provider (ISP) and one for the router-to-router VPN connection. Demand-dial router-to-router VPN connections also require an additional host route in the IP routing table of the calling router. For more information, see A dial-up router-to-router VPN connection.

  • Persistent connections require that both routers are connected to the Internet by using permanent WAN connections. You only need to configure a single demand-dial interface at each router. Permanent connections can be initiated and left in a connected state 24 hours a day.

Restricting the initiation of an on-demand connection

To prevent the calling router from making unnecessary connections, you can restrict the calling router from making on-demand router-to-router VPN connections in two ways:

  • Demand-dial filtering

    You can use demand-dial filtering to configure either the types of IP traffic that do not cause a demand-dial connection to be made or the types of IP traffic that cause a connection to be made. For more information, see Configure demand-dial filters.

  • Dial-out hours

    You can use dial-out hours to configure the hours that a calling router is either permitted or denied to make a router-to-router VPN connection. For more information, see Configure dial-out hours.

One-way or two-way initiated connections

You must decide whether your router-to-router VPN connections will be initiated by one router or by both routers:

  • With one-way initiated connections, one router is the VPN server and one router is the VPN client. The VPN server accepts the connection and the VPN client initiates the connection. One-way initiated connections are well suited to a permanent connection spoke-and-hub topology where the branch office router is the only router that initiates the connection. One-way initiated connections require that:

    • The VPN server (the answering router) is configured as a LAN and demand-dial router.

    • A user account is added for the authentication credentials of the calling router that is accessed and validated by the answering router.

    • A demand-dial interface is configured at the answering router with the same name as the user account that is used by the calling router. This demand-dial interface is not used to dial out, therefore it is not configured with the host name or IP address of the calling router or with valid user credentials.

    For more information, see One-way initiated demand-dial connections.

  • With two-way initiated connections, either router can be the VPN server or the VPN client depending on who is initiating the connection. Both routers must be configured to initiate and accept a VPN connection. You can use two-way initiated connections when the router-to-router VPN connection is not up 24 hours a day and traffic from either router is used to create the on-demand connection. Two-way initiated router-to-router VPN connections require that:

    • Both routers are connected to the Internet by using a permanent WAN link.

    • Both routers are configured as LAN and demand-dial routers.

    • User accounts are added for both routers so that the authentication credentials for the calling router are accessed and validated by the answering router.

    • Demand-dial interfaces, with the same name as the user account that is used by the calling router, must be fully configured at both routers, including settings for the host name or IP address of the answering router and user account credentials to authenticate the calling router.

Configuring firewall packet filters

If you have a firewall, you must configure packet filters on the firewall to allow traffic between the VPN router and the routers on the Internet. For more information, see VPN servers and firewall configuration.

Routing

Both routers on a router-to-router VPN connection must have the appropriate routes in their routing tables to forward traffic across the connection. Routes can be static or dynamic. You can add static routes to the routing table either manually or through an auto-static update. You can add dynamic routes to the routing table by adding the VPN connection demand-dial interface to a routing protocol. However, enabling a routing protocol on the VPN connection demand-dial interface is only recommended when the demand-dial interface is permanently connected.

Note

  • Unlike demand-dial routing by using direct links, you cannot use a default IP route for the VPN demand-dial interface to summarize all the routes of the corporate office. Because the branch office router is connected to the Internet, the default route must be used to summarize all the routes of the Internet and configured to use the interface that connects the router to the Internet.

Single hop across VPN connection

For the purposes of designing a routed infrastructure, you can consider the router-to-router VPN connection as a single hop regardless of how many routers are crossed when the encapsulated data is sent across the Internet.

Creating a remote access policy for router-to-router VPN connections

By using remote access policies, you can create a policy that requires router-to-router VPN connections to use a specific authentication method and encryption strength.

For example, you can create an Active Directory group called VPN Routers whose members are the user accounts that are used by calling routers when a router-to-router VPN connection is created. Then, you create a policy with two conditions on the policy: the NAS-Port-Type is set to Virtual (VPN) and the Windows-Group is set to VPN Routers. Finally, you configure the profile for the policy to select a specific authentication method and encryption strength.

You can also use the Tunnel-Type condition to create separate remote access policies for PPTP and L2TP connections. For example, to require a specific authentication method and encryption strength for PPTP connections, set the Tunnel-Type condition to Point-to-Point Tunneling Protocol.