Virtual Private Networking

Addressing and Routing for VPNs

Reprinted with permission from the Windows 2000 Resource Kits

In This Chapter

Addressing and Routing for VPNs

To understand how VPNs work, you must understand how addressing and routing is affected by the creation of remote access VPNs and router-to-router VPNs. A VPN connection creates a virtual interface that must be assigned a proper IP address, and routes must be changed or added to ensure that the proper traffic is sent across the secure VPN connection instead of the shared or public transit internetwork.

Remote Access VPN Connections

For remote access VPN connections, a computer creates a remote access connection to a VPN server. During the connection process the VPN server assigns an IP address for the remote access VPN client and changes the default route on the remote client so that default route traffic is sent over the virtual interface.

IP Addresses and the Dial-Up VPN Client

For dial-up VPN clients who connect to the Internet before creating a VPN connection with a VPN server on the Internet, two IP addresses are allocated:

In either case, the IP address allocated to the VPN client must be reachable by hosts on the intranet and vice versa. The VPN server must have appropriate entries in its routing table to reach all the hosts on the intranet and the routers of the intranet must have the appropriate entries in their routing tables to reach the VPN clients.

The tunneled data sent through the VPN is addressed from the VPN client's VPN server-allocated address to an intranet address. The outer IP header is addressed between the ISP-allocated IP address of the VPN client and the public address of the VPN server. Because the routers on the Internet only process the outer IP header, the Internet routers forward the tunneled data to the VPN server's public IP address.

An example of dial-up client addressing is shown in Figure 9.14 where the organization uses private addresses on the intranet, and the tunneled data is an IP datagram.

Figure 9.14 Public and Private Addresses in PPTP Tunneled Data

Default Routes and Dial-Up Clients

When a typical dial-up client dials the ISP, it receives a public IP address from the ISP NAS. A default gateway address is not allocated as part of the IPCP negotiation process. Therefore, in order to reach all Internet addresses, the dial-up client adds a default route to its routing table using the dial-up interface connected to the ISP. As a result, the client can forward the IP datagrams to the ISP NAS from where they are routed to its Internet location.

For dial-up clients with no other TCP/IP interfaces, this is the wanted behavior. However, this behavior can cause confusion for dial-up clients that have an existing LAN-based connection to an intranet. In this scenario, a default route already exists pointing to the local intranet router. When the dial-up client creates a connection with their ISP, the original default route remains in the routing table but is changed to have a higher metric. A new default route is added with a lower metric using the ISP connection.

As a result, the intranet locations that are not on the dial-up client's directly attached network are not reachable for the duration of the connection to the ISP. If the new default route is not created, all intranet locations are reachable, but Internet locations are not.

A Windows 2000-based dial-up client creates the default route by default.

To prevent the default route from being created

To achieve connectivity to both intranet and Internet locations while the ISP connection is active, leave the Use default gateway on remote network option selected and add the routes of the intranet to the routing table of the dial-up client. The intranet routes can be added through static persistent routes using the route utility, or, if Routing Information Protocol (RIP) version 1 is being used as the intranet routing protocol, you can use the Route Listening Service to listen to RIP version 1 routing protocol traffic and dynamically add intranet routes. When connected to the ISP, all intranet locations are reachable using the intranet routes and all Internet locations are reachable using the default route.

Default Routes and VPNs over the Internet

When the dial-up client calls the ISP, it adds a default route using the connection to the ISP as shown in Figure 9.15. At this point, it can reach all Internet addresses through the router at the ISP NAS.

Figure 9.15 Default Route Created When Dialing an ISP

When the VPN client creates the VPN connection, another default route and a host route to the IP address of the tunnel server are added, as illustrated in Figure 9.16. The previous default route is saved but now has a higher metric. Adding the new default route means that all Internet locations except the IP address of the tunnel server are not reachable for the duration of the VPN connection.

Figure 9.16 Default Route Created When Initiating the VPN

Just as in the case of a dial-up client connecting to the Internet, when a dial-up VPN client using voluntary tunneling creates a VPN connection to a private intranet across the Internet, one of the following occurs:

For most Internet-connected VPN clients, this behavior does not represent a problem because they are typically engaged in either intranet or Internet communication, not both.

For VPN clients who want concurrent access to intranet and Internet resources when the VPN is connected, the solution depends on the nature of the IP addressing in the intranet. In all cases, configure the VPN connection object so that it does not add a default gateway. When the VPN connection is created, the default route remains pointed to the ISP NAS, allowing access to all Internet addresses.

Based on the type of intranet addressing you use, enable concurrent access to intranet and Internet resources as follows:

Public Addresses   Add static persistent routes for the public network IDs of the intranet using the IP address of the VPN server's virtual interface as the gateway IP address.

Private Addresses   Add static persistent routes for the private network IDs of the intranet using the IP address of the VPN server's virtual interface as the gateway IP address.

Overlapping or Illegal Addresses   If the intranet is using overlapping or illegal addresses (IP network IDs that are not private and have not been registered by Internet Network Information Center [InterNIC] or obtained from an ISP), those IP addresses might be duplicated by public addresses on the Internet. If static persistent routes are added on the VPN client for the overlapping network IDs of the intranet, the locations on the Internet for the overlapping addresses are not reachable.

In each of these cases, static persistent routes for the network IDs of the intranet need to be added to the VPN client. When the persistent routes are added, they are saved in the registry. With Windows NT 4.0 Service Pack 3 and later and with Windows 2000, the persistent routes are not actually added to the IP routing table (and are not visible with the route print command at the Windows 2000 command prompt) until the IP address of the gateway is reachable. The IP address of the gateway becomes reachable when the VPN connection is made.

For each route, type the following route utility syntax at a Windows 2000 command prompt:

ROUTE ADD MASK -p


The gateway IP address in the route commands for each intranet route is the IP address assigned to the VPN server's virtual interface, not the IP address of the VPN server's Internet interface.

You can determine the IP address of the VPN server's virtual interface from the IP address of the Internal interface under IP Routing - General in the Routing and Remote Access snap-in. If you use DHCP to obtain IP addresses for dial-up networking and VPN clients, the IP address of the VPN server's virtual interface is the first IP address obtained when requesting DHCP addresses. If you have configured a static IP address pool, the IP address of the VPN server's virtual interface is the first IP address in the static IP address pool. You can also determine the IP address of the VPN server's virtual interface by double-clicking the virtual private networking connection object when the VPN connection is active. In the resulting Status dialog box, click the Details tab.

caution-icon

Caution

For all of these cases, you must add the routes very carefully to ensure that the private traffic to the intranet is forwarded using the VPN connection and not the PPP connection to the ISP. If the wrong routes are added, the traffic that you intend to forward across the VPN in an encrypted form is instead sent unencrypted across the Internet. For example, if your intranet is using the public network ID 207.46.130.0/24 (subnet mask 255.255.255.0), and you mistakenly add a persistent static route for 207.46.131.0/24, all traffic to the intranet network 207.46.130.0/24 is forwarded across the Internet in plaintext, rather than being encrypted and sent across the VPN connection.

Router-to-Router VPN Connections

For router-to-router VPNs, the routing interface used to forward packets is a demand-dial interface configured as follows:

The creation of demand-dial interfaces is automated with the Demand-Dial Interface Wizard.

The names of the demand-dial interfaces and the calling router credentials may need to be properly matched to ensure a router-to-router VPN connection. For more information, see "Demand-Dial Routing" in this book.

Temporary vs. Persistent Router-to-Router VPNs

Router-to-router VPN connections can be either temporary or persistent.

To configure either a persistent or temporary connection

  1. In the Routing and Remote Access snap-in, select Routing Interfaces.
  2. Right-click the demand-dial interface object, and then select Properties.
  3. On the Options tab, under Connection Type, select either Demand dial or Persistent.

VPNs Using Dial-Up ISP Connections

When both the VPN server and the VPN client are directly connected to the Internet using a permanent WAN link such as T1 or Frame Relay, the VPN connection can be persistent and available 24 hours a day. However, when a permanent WAN link is not possible or practical, you can configure an on-demand router-to-router VPN connection using a dial-up ISP.

An on-demand router-to-router VPN connection using a dial-up ISP connection consists of two demand-dial interfaces:

An on-demand router-to-router VPN connection is automatically established when traffic to be forwarded across the VPN connection is received by the branch office router. For example, when receiving a packet to be routed to the corporate office, the branch office router first uses a dial-up link to connect to a local ISP. When the Internet connection is made, the branch office router, the VPN client, creates a router-to-router VPN connection with the corporate office router, the VPN server.

To configure an on-demand VPN connection at the branch office router

  1. Create a demand-dial interface for the Internet connection configured for the appropriate equipment (a modem or ISDN device), the phone number of the local ISP, and the user name and password used to gain Internet access.
  2. Create a demand-dial interface for the router-to-router VPN connection with the corporate office router configured for PPTP or L2TP, the IP address or host name of the corporate office VPN server's interface on the Internet, and a user name and password that can be verified by the VPN server. The user name must match the name of a demand-dial interface on the corporate office VPN server.
  3. Create a static host route for the IP address of the VPN server's Internet interface that uses the demand-dial interface used to dial the local ISP.
  4. Create a static route or routes for the IP network IDs of the corporate intranet that uses the VPN demand-dial interface.

To configure the corporate office router

  1. Create a demand-dial interface for the VPN connection with the branch office configured for a VPN device (a PPTP or L2TP port). The demand-dial interface must have the same name as the user name in the authentication credential that is used by the branch office router to create the VPN connection.
  2. Create a static route or routes for the IP network IDs of the branch office that uses the VPN demand-dial interface.

The router-to-router VPN connection is automatically initiated by the branch office router through the following process:

  1. Packets sent to a corporate hub network location from a user in the branch office are forwarded by the user to the branch office router.
  2. The branch office router checks its routing table and finds a route to the corporate intranet network ID, which uses the VPN demand-dial interface.
  3. The branch office router checks the state of the VPN demand-dial interface and finds it is in a disconnected state.
  4. The branch office router retrieves the configuration of the VPN demand-dial interface.
  5. Based on the VPN demand-dial interface configuration, the branch office router attempts to initialize a router-to-router VPN connection at the IP address of the VPN server on the Internet.
  6. To establish a VPN, either a TCP connection (by using PPTP) or an IPSec negotiation must be established with the VPN server. The VPN establishment packet is created.
  7. To forward the VPN establishment packet to the corporate office router, the branch office router checks its routing table and finds the host route using the ISP demand-dial interface.
  8. The branch office router checks the state of the ISP demand-dial interface and finds it is in a disconnected state.
  9. The branch office router retrieves the configuration of the ISP demand-dial interface.
  10. Based on the ISP demand-dial interface configuration, the branch office router uses its modem or ISDN adapter to dial and establish a connection with its local ISP.
  11. When the ISP connection is made, the VPN establishment packet is sent by the branch office router to the corporate office router.
  12. A VPN is negotiated between the branch office router and the corporate office router. As part of the negotiation, the branch office router sends authentication credentials that are verified by the corporate office router.
  13. The corporate office router checks its demand-dial interfaces and finds one that matches the user name sent during authentication and changes the interface to a connected state.
  14. The branch office router forwards the packet across the VPN and the VPN server forwards the packet to the appropriate intranet location.

Static vs. Dynamic Routing

When the demand-dial interfaces are created and the choice has been made between temporary and persistent connections, you must choose one of the following methods for adding routing information to the routing table:

  1. For temporary connections, you can manually add the appropriate static routes to reach network IDs in the other offices. Manual configuration of static routes is appropriate for small implementations with a small number of routes.
  2. For temporary connections, you can use auto-static updates to periodically update the static routes that are available across the router-to-router VPN connection. Auto-static routes work well for larger implementations with a large amount of routing information. For more information about auto-static updates, see "Demand-Dial Routing" in this book.
  3. For persistent connections, run the appropriate routing protocols over the router-to-router VPN connection treating the VPN connection as a point-to-point link.
note-icon

Note

Unlike demand-dial routing using direct physical connections, you cannot use a default IP route configured for the VPN demand-dial interface to summarize all the intranet routes available across the VPN. Because the router is connected to the Internet, you must use the default route to summarize all the routes of the Internet and configure it to use the Internet interface.

Pre-shared Key Authentication for L2TP over IPSec Router-to-Router VPN Connections

By default, both the L2TP client and L2TP server for Windows 2000 are pre-configured for certificate-based IPSec authentication. When you make an L2TP over IPSec connection, an IPSec policy is automatically created to specify that the Internet Key Exchange (IKE) will use certificate-based authentication during the negotiation of security settings for L2TP. This means that both the L2TP client and L2TP server must have a computer certificate (also known as a machine certificate) installed before a successful L2TP over IPSec connection can be established. Both computer certificates must either be from the same certificate authority (CA), or the root certificate of each computer's CA must be installed as a trusted root certificate authority in each other's trusted root certificate store. For more information about IPSec, see "Internet Protocol Security" in the TCP/IP Core Networking Guide.

In some cases, a certificate-based IPSec authentication method is not desired for L2TP-based router-to-router VPN connections. For example, if you have a small organization and do not want to deploy a certificate infrastructure, or you are connecting to routers that do not support certificate-based IPSec authentication. In these cases, you can manually configure IPSec policy to use pre-shared keys when creating router-to-router VPN connections. This pre-shared authentication key acts like a simple password in the IKE negotiation, if both sides can prove they know the same password, then they trust each other and will continue to negotiate private, symmetric encryption keys, and specific security settings for L2TP traffic.

Using an IKE pre-shared key is generally considered not as secure as using certificates because the IKE authentication (and implicit trust) is dependent on the key value only, which is stored in plain text format in the IPSec policy. Anyone who views the policy can see the pre-shared key value. If a malicious user views the pre-shared key, then they could configure their system to successfully establish IPSec security with your system. However, the L2TP connection requires user level authentication using a PPP authentication protocol. Therefore, a malicious user would have to know both the pre-shared key and the proper user credentials to successfully establish the L2TP over IPSec connection.

To perform pre-shared key authentication for L2TP over IPSec router-to-router VPN connections, you must change a registry setting and then configure IPSec policy settings.

To prevent the Routing and Remote Access service from automatically creating an IPSec policy for L2TP traffic, set the value of ProhibitIpSec to 1 (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan \Parameters). By default, ProhibitIpSec is set to 0. When ProhibitIpSec is set to 1, the encryption settings on the demand-dial interface configured on the calling router are ignored in favor of the encryption settings of the manually configured IPSec policy. The computer must be restarted for the changes to this registry setting to take effect.

Where you configure the IPSec settings depends on the following:

Before creating IPSec policy, you must decide whether all sites being connected will use the same pre-shared key or whether each connection will use a separate pre-shared key. This decision impacts how IPSec filter lists and policy are configured.

The same pre-shared key may be used when one administrator or company controls both L2TP tunnel endpoints.

Different pre-shared keys may be used when configuring L2TP tunnels between systems that are not under the same administrative or corporate security control. For example, one Windows 2000 VPN server may be configured to communicate to six different business partners, each of which need a different IKE pre-shared key for L2TP connections.

For example purposes, the following sections discuss the IPSec configuration required for a router that is using L2TP over IPSec pre-shared key authentication for router-to-router VPN connections between a corporate hub office in New York and two branch offices; one in Boston and one in London.

note-icon

Note

If you have a Windows 2000 VPN server that is communicating to other L2TP clients or servers using the default certificate-based IPSec authentication, and you want to use IPSec pre-shared key authentication for one L2TP/IPSec tunnel, then you must include rules to use certificate authentication for those systems already using it, as well as a rule for pre-shared key authentication in the same IPSec policy.

Same Pre-shared Key for All Connections

To use the same pre-shared key for all L2TP over IPSec router-to-router VPN connections, configure the following:

  1. Using the Routing and Remote Access snap-in, create the appropriate demand-dial interfaces. In our example, create a demand-dial interface for the connection to the Boston branch office and a demand-dial interface to the London branch office.
  2. Using the IP Security Policies snap-in, create an IPSec filter action that does not allow unsecured L2TP communication.
  3. Create one IPSec filter list that contains filters for all the L2TP over IPSec connections using the same IKE pre-shared authentication key value. Each filter within the filter list is for a specific location. Using our example, you would configure a filter list with two filters, one filter defining the L2TP traffic to the Boston router and one filter defining the L2TP traffic to the London router.
  4. Create a new IPSec policy that uses a single active rule; a rule that uses the filter action that does not allow unsecured L2TP communication, the filter list for all the L2TP over IPSec connections, and a pre-shared key as the authentication method.

Creating the Filter Action

To create a filter action that does not permit unsecured L2TP communication, create a filter action with the following properties:

The example discussed here use the same encryption strength for all destinations. However, you may need to create filter actions specific to a destination, depending on the IPSec security capabilities of the remote system. For example, a filter action for Boston may require only 3DES encryption, whereas a filter action for London may require only DES due to cryptography export restrictions. To handle both 3DES and DES in the same filter action, include them both in the filter action security method list, putting 3DES first to make sure it is selected first when possible.

Creating the Filter List for the Same Pre-shared Key for all Connections

To configure a filter list that contains all L2TP-based router-to-router VPN connections, create a filter list with the following properties:

Then, for each destination, create a filter within the filter list with the following configuration:

Configuring an IPSec Policy for the Same Pre-shared Key

To configure an IPSec policy that uses the same pre-shared key for all L2TP-based router-to-router VPN connections, create an IPSec policy with the following properties:

Add a rule with the following properties:

Because the filter list contains all of the destinations for L2TP-based router-to-router VPN connections, only a single rule within the IPSec policy is required.

Different Pre-shared Keys for Different Connections

To use different pre-shared keys for all L2TP over IPSec router-to-router VPN connections, configure the following:

  1. Create the appropriate demand-dial interfaces. In our example, create a demand-dial interface for the connection to the Boston branch office and a demand-dial interface to the London branch office.
  2. Create a filter action that does not allow unsecured L2TP communication.
  3. Create an IPSec filter list that contains a single filter for the L2TP over IPSec connection to a specific location. Using our example, configure a filter list with one filter defining the L2TP traffic to the Boston router. Then, configure another filter list with one filter defining the L2TP traffic to the London router.
  4. Create a new IPSec policy that uses a series of rules; each rule uses the filter action that does not allow unsecured L2TP communication, the filter list for a specific L2TP over IPSec connection, and the pre-shared key for the specific connection as the authentication method.

Creating the Filter Action

The configuration of the filter action for the different pre-shared key for different connections is the same as the filter action for the same pre-shared key for all connections.

Creating the Filter List for a Different Pre-shared Key for all Connections

To configure a filter list for a specific router-to-router VPN connection, create a filter list with the following properties (using the connection to Boston as an example):

Then, create a single filter with the following configuration:

Repeat this procedure for each L2TP over IPSec router-to-router VPN connection. Using our example, configure another IPSec filter list for the connection to the London router.

Configuring an IPSec Policy for a Different Pre-shared Key for Each Connection

To configure an IPSec policy that uses a different pre-shared key for each L2TP router-to-router VPN connection, create an IPSec policy with the following properties:

For each L2TP router-to-router VPN connection, add a rule with the following properties (using the connection to Boston as an example):

Add a separate rule for each L2TP over IPSec router-to-router VPN connection. Using our example, add another rule for the connection to the London router.

note-icon

Note

For an incoming L2TP over IPSec connection, the Routing and Remote Access service queries IPSec to discover the type of encryption that was negotiated. The query is for the encryption used for an IPSec security association (SA) for IP traffic to UDP port 1701. If an IPSec SA exists for IP traffic to UDP port 1701, the type of encryption used for the IPSec SA is returned. When ProhibitIpSec is set to 0, an IPSec SA is always found for this type of traffic because L2TP traffic filters are automatically created by the Routing and Remote Access service. The encryption type is then compared to the types of encryption allowed by the profile settings of the matching remote access policy for the L2TP connection. If the encryption type returned from the IPSec query does not match the allowed encryption strengths in the remote access policy profile, the connection attempt is rejected. If ProhibitIpSec is set to 1 and a specific filter for UDP port 1701 is not configured, the query fails to find an SA for IP traffic to UDP port 1701 and no encryption is assumed. This can cause the connection attempt to be rejected if the encryption setting on the matching remote access policy profile has the No encryption setting disabled. Therefore, the disconnection of encrypted L2TP over IPSec connections can occur when an IPSec filter exists that uses pre-shared key for all IP traffic and a specific filter for UDP port 1701 is not configured.

Using IPSecPol to Create the IPSec Policy

IPSec policy for pre-shared key L2TP over IPSec connections can also be configured using the IPSecPol Resource Kit tool. For more information, see the Windows 2000 Resource Kit Tools Help.

© 1985-2000 Microsoft Corporation. All rights reserved.