New DHCP Digs
Routing and Remote Access contains several new DHCP-related features. One feature is the DHCP Allocator, which is a component of NAT. The DHCP Allocator is essentially a scaled-down version of a full DHCP server that lets a NAT-enabled Routing and Remote Access server provide IP addresses to NAT clients. Another feature is the improved DHCP Relay Agent, which you configure from the Routing and Remote Access management console's IP Routing\DHCP Relay Agent section. Like its NT 4.0 predecessor, the DHCP Relay Agent, which Figure 4, page 56, shows, lets a Routing and Remote Access server pass DHCP client requests from one LAN segment to a DHCP server on another network segment when the server is connected to each segment.
The DHCP Relay Agent also supports a new DHCP technology, DHCP Inform. This technology, which RAS clients running Win2K, Windows Me, and Win98 support, lets DHCP clients obtain additional IP configuration information from a DHCP server after the negotiation of their dial-up connection is complete.
DHCP Inform is important because RAS clients don't obtain their IP addresses from a DHCP server and thus don't benefit from some DHCP features. Even when you configure the RAS server for DHCP, the server obtains the address on the client's behalf and passes it, along with other IP configuration information, to the client through standard Point-to-Point Protocol (PPP) negotiation. However, Win2K, Windows Me, and Win98 RAS clients can send—and the Routing and Remote Access server can receive and respond to—special DHCPINFORM messages that let the RAS clients receive IP configuration information from a DHCP server. This information supersedes or augments information that the RAS clients receive from the Routing and Remote Access server.
The Routing and Remote Access server receives the DHCPINFORM message from the client and passes it on to the DHCP server, then returns the information it receives from the DHCP server back to the client. The information includes configuration data (e.g., additional or alternative WINS and DNS servers), a DNS domain name, and a default gateway. If the client receives DHCP options that supersede those originally obtained from the Routing and Remote Access server, the new information replaces the old information. This feature requires that a DHCP server exist on one of the LANs to which the Routing and Remote Access server is connected. Also, before this feature will work properly, you must add each of the network interfaces on which you want to support DHCP relaying to the management console's IP Routing/DHCP Relay Agent section. (The system automatically adds and enables a special Internal interface.)
VPNs, Win2K Style
Routing and Remote Access sports several new VPN-related improvements. One improvement is the addition of Layer 2 Tunneling Protocol (L2TP) support. L2TP, which RFC 2661 defines, acts as a successor to earlier single-vendor tunneling protocols, such as Microsoft PPTP and Cisco Systems' Layer 2 Forwarding (L2F) protocols. Unlike PPTP, Win2K's L2TP implementation uses IP Security (IPSec) rather than Microsoft Point-to-Point Encryption (MPPE) to secure and encrypt PPP datagrams that pass over a VPN connection. Therefore, a RAS client that wants to use L2TP must support both IPSec and L2TP. Currently, only one OS—Win2K—meets this requirement.
Another notable improvement is enhanced VPN administration, which includes the Routing and Remote Access Server Setup Wizard that I discussed earlier. Like the wizard's other options, the Virtual private network (VPN) server option prompts you for all the basic information necessary to complete the VPN server configuration, including the identification of your Internet-connected adapter. (This connection must occur through a NIC—not a dial-up connection—so you must have at least two NICs, or one adapter with at least two LAN ports, in any server that you intend to make a VPN server.) The wizard then automatically configures the Routing and Remote Access server with whopping 128 PPTP and 128 L2TP connections. (Other configuration choices configure 5 PPTP and 5 L2TP ports.)
If you want to manually change these default numbers after the wizard completes, simply right-click the Ports entry in the Routing and Remote Access management console's left pane and choose Properties. Doing so displays all the ports available on the Routing and Remote Access server, including the WAN miniport drivers for PPTP and L2TP (assuming both are present). To modify the number of ports available for each protocol and to determine the direction of the connection (i.e., inbound or outbound), highlight the protocol, click Configure, and use the resulting Configure Device dialog box to set the desired options, as Figure 5 shows.
The Virtual private network (VPN) server option also configures the DHCP Relay Agent so that Routing and Remote Access clients can use DHCP Inform and IGMP support to let Routing and Remote Access clients use IP multicast applications. The option also automatically configures a default remote access policy and creates filters on the Internet-connected interface so that the Routing and Remote Access server will accept only PPTP and L2TP connections and drop all other traffic. This feature is similar to NT 4.0's PPTP Filtering feature. If your configuration requires you to permit additional traffic, or if you later change your Routing and Remote Access server's configuration to handle other duties such as remote access or routing, you might need to modify or remove these filters.
Routing and Remote Access's VPN features, like those of NT 4.0 RRAS, also support VPN-based LAN-to-LAN routing over LAN or dial-up interfaces (which now include L2TP as well as PPTP). Fortunately, the process of setting up a VPN-based LAN-to-LAN router is much easier than the NT 4.0 process and involves far less guesswork. For more information about configuring VPNs with Routing and Remote Access, see "Related Articles in Previous Issues."
Prev. page
1
2
[3]
4
5
6
next page 
