Deploying an Intranet Infrastructure

Now that the server has its basic TCP/IP setup configured and all the AAA connections and protocol decisions are done, you need to make sure that the internal resources are accessible to the VPN server so that it can handle communications to remote access clients. Deploying the intranet network infrastructure for remote access VPN connections consists of the following:

• Configure routing on the VPN server.

• Verify name resolution and intranet reachability from the VPN server.

• Configure routing for off-subnet address pools.

• Configure quarantine resources.

Configuring Routing on the VPN Server

For your VPN servers to properly forward traffic to locations on the intranet, you must configure them with either static routes that summarize all the possible addresses used on the intranet or with routing protocols so that the VPN server can participate as a dynamic router and automatically add routes for intranet subnets to its routing table. As a best practice, you should use route summarization to get to the rest of the internal network. That way, the administration of the VPN server is eased and you don’t have to worry about supporting dynamic routing on the VPN server. If route summarization is not possible, use dynamic routing to ensure that the VPN server is aware of all network topology changes.

Verifying Name Resolution and Intranet Reachability from the VPN Server

From each VPN server, verify that the VPN server can resolve names and successfully communicate with intranet resources. You do this by using the Ping command, accessing Web pages with Internet Explorer, and making drive and printer connections to known intranet servers. This is where the previous point about making sure to use internally-based DNS and WINS settings becomes important: configure these settings only on the intranet interfaces of the VPN server. If the clients are handed externally-based DNS settings, be unable to reach the external name servers (if split-tunneling is disabled) or the external name servers will not be able to resolve the names for intranet resources (if split-tunnelig is enabled).

Configuring Routing for Off-Subnet Address Ranges

If you configured any of the VPN servers with manual address pools and any of the ranges in the pool are an off-subnet range, you must ensure that the route or routes representing the off-subnet address pool or pools are present in your intranet routing infrastructure. You can ensure this by either adding static routes representing the off-subnet address range as static routes to the neighboring routers of the VPN servers, and then using the routing protocol of your intranet to propagate the route to other routers. When you add the static routes, you must specify that the gateway or next-hop address is the intranet interface of the VPN server. When using this method, make sure to enable static route redistribution on the next-hop router to propagate the static routes into the dynamic routing protocol. Check with your router’s documentation on how to propagate static routes.

Alternatively, if you are using Routing Information Protocol (RIP) or Open Shortest Path First (OSPF), you can configure the VPN servers using off-subnet address pools as RIP or OSPF routers. For OSPF, you must configure the VPN server as an autonomous system boundary router (ASBR). This configuration allows the OSPF router (the VPN server) to advertise static routes within the OSPF autonomous system (AS).

Configuring Quarantine Resources

As discussed earlier in the chapter, if you are using Network Access Quarantine Control, you should service quarantined users by designating a DNS server, file servers and shares for updated scripts, and Web servers with Web pages containing network policy compliance instructions and components in a separate subnet.