I was recently contracted on a VPN project that consisted mainly of mayhem and confusion. Let me explain. A local company wanted to connect several small offices to the main office, where the application servers resided. It had previously been on a completely private network with the main office as the hub in a multipoint WAN scheme. The private ISDN links between the remote offices and the home office had already been cancelled. Therefore, there was no overlap time to implement the new VPN-based WAN. I came into the picture at the last minute, after the supposed design phase, and after all equipment had been ordered. So the die was cast.

The client wasn’t about to pay for any further equipment or software, because the sales representative had sold this as a complete solution. In short, I had to make things work with what I had, which wasn’t exactly the optimum configuration.

Customer requirements
Let’s look briefly at the customer requirements, materials, and resources with which I was constrained. The home office at the hub of the WAN had a Cisco 3620 router (with minimal memory) that I would connect to the new ISP via a new T1 line. All but one of the small, remote offices were being set up with DSL connections to the same ISP via new Netopia R910 access routers and DSL modems. One office would maintain the ISDN connection directly from small office to home office, as DSL was not yet available in the area. The client stipulated that the small offices didn’t require general Internet access and that only a few users at the home office would be allowed to surf. The primary purpose of the new WAN connections would be interoffice connectivity. It was never clearly defined how the initial design would have been deployed using the aforementioned equipment and links. A question looming large was on which device to terminate all of these tunnels at the home office. Since I wasn’t able to glean much from the proposal, I had to be creative. Figure A shows how the setup was being handled before I took over.

Figure A
Each of the remote offices had to connect through the ISP. Once the ISP pulled the plug, no one had access.

VPN options
In talking with the client, I discovered that they had used the ISDN links as persistent, rather than demand, connections. In the past, they had used a completely private addressing scheme. I determined to do the same across the Internet links. My focus was to get each location routed back to the main office across an intermediary network (Internet) using tunneling technology. I didn’t even want to look at encryption at this point. I barely had time to turn up all of the physical connections, much less deal with security. That issue was saved for last, as it often is in time-compressed implementations.

Once all physical links were up and connected to the ISP, I turned my attention to routing between the private networks across the public Internet.

GRE tunneling
One way to do so is tunneling using Generic Routing Encapsulation (GRE). When setting up such tunnels, the endpoint devices at either end must support the same method. The Cisco router at the main office supported GRE, but the Netopia routers at the small offices didn’t. Rather than use the routers as endpoints for the tunnels, I could use the Windows NT 4 servers configured with RRAS. However, most of the servers were ancient and slow. There was no way they could handle the additional routing load, much less potential encryption overhead.

Server/router combo
The best-looking option at this point appeared to be a combination of servers and routers. Since the Netopias did offer VPN options using PPTP and IPSec, they were the most logical option for a tunnel endpoint at the remote office end. At the home office, my preference would have been to use the Cisco router as endpoint. But this would have required an IOS feature license upgrade for IPSec, which in turn required a memory upgrade. It was doubtful the client would have opted for this choice, considering the cost.

Another option was using one of the faster NT servers at the home office with RRAS as the tunnel endpoint. The last option I considered was scrapping the thought of a LAN-LAN VPN altogether and switching to a remote access VPN model. With this option, I would need to configure PPTP on each workstation at the remote offices and a RAS server at the home office. This would also require me to open holes in all of the Netopia firewall routers to pass the PPTP traffic. The new Netopia access routers provided basic firewall functions, but the main office was not protected at all. I created an ad hoc access list on the main office Cisco 3620 router to filter unwanted incoming traffic but allow PPTP traffic from the remote offices.

These access list entries allowed protocols 50 and 51 and UDP port 1793 from all the remote networks to the T1 outside interface of the router at the main office.

IP addresses

These examples assume that is the IP address assigned to the T1 WAN interface at the main office. The address space is used for the WAN links at all remote offices.


After I opened the path for tunneling, I needed to redirect all VPN traffic arriving at the main office on these PPTP ports when it reached the external interface. This traffic from all remote office tunnels would be redirected to the internal Windows NT RRAS server serving as the tunnel endpoint(s) at the home office. I did so with static NAT mappings.

This Windows NT router/server would have to have its default gateway configured to look at the inside interface of the 3620 router performing this redirection. I also set up static routes on the NT RRAS server to direct traffic down the tunnels to the remote offices. This could be accomplished in the Routing and RAS admin utility. These static routes work in conjunction with the connection objects I had to configure for each remote office VPN tunnel.

Since the router at the main office was configured for Internet access via outbound NAT, I needed to find a way to separately handle tunnel-bound traffic (bound for the Internet), which had to be NATed. I could do this by using an extended access list in the dynamic NAT configuration.

The first line performed the dynamic NAT mapping, referencing access list 102. Then, the second excluded all traffic from the local LAN going to the other private LANs. The third allowed all other traffic from the home office LAN to be NATed. As all workstations at the main office were to be configured to use the NT RRAS server as their default gateway, this was not a problem. Traffic headed outside the local LAN reaches the RRAS server, which then either sends the private traffic bound for a remote office down the tunnel without being translated or directs Internet-bound traffic to the Cisco router for NATing and forwarding to the Internet.

I decided on PPTP because of its lower encryption overhead. And since I was terminating six remote tunnels at the main office NT VPN server, processing capacity was an issue. I also had to face the issue of routing the different traffic types once they reached the home office. All incoming PPTP traffic could be assumed to be coming from remote offices. So this required me to perform a PPTP port redirect at the Cisco router to the NT VPN server. Other incoming traffic would be incoming mail to the Exchange server, which would also need a redirect to the mail server. The Cisco router using static NAT commands could provide both of these needs. The only remaining traffic that should have been allowed was the return traffic from sessions started internally from the main office out to the Internet. This could be accomplished with an access list statement allowing traffic to internally established connections. Restricting outbound traffic from the remote offices to go only to the main office (and not the Internet) could easily be achieved by not configuring NAT on the Netopia routers. In this way, all outbound traffic would exit through the tunnel to the main office, as the remote office workstations wouldn’t be able to NAT to a valid address.

For the NT box, I needed to install the PPTP protocol and RRAS, which I downloaded from the Microsoft site.

I needed to create a connection object in RRAS admin for each tunnel terminating at the NT server. Then I created static routes that worked in conjunction with these connection objects to route traffic to the remote offices. PPTP authentication information needed to be specified with the connection objects and I had to create a RAS-enabled dial-in account so that the remote devices could connect and authenticate with the NT VPN server. At this point, I configured the same authentication information properties on the remote Netopia routers. The Netopia interface was so simple and menu-driven that there was little need to elaborate.

More information

For more information on creating a dial-in (or dial-out) connection in the RRAS server, take a look at Jim Boyce’s ”Configuring Routing and Remote Access on your Windows 2000 server” Daily Drill Down.

Challenges along the way
One of the most unusual problems I ran into was finding a Cisco IOS version to load on the main office 3620 router. Since the proposal specified an internal T1 WIC card, I needed an IOS revision that supported it. Also, I needed support for static NAT mappings for port redirection of tunnel traffic from the outside interface of the router to the tunnel endpoint, the Windows NT server. I would also need a static NAT mapping to redirect SMTP traffic to the internal e-mail server.

Another thing I had to consider was the ISDN connection to the one remote office. The 3620 router also had installed a multiport ISDN adapter used for demand-dial routing. Finding an IOS version that supported all of these needs (without bugs) was a bit dicey. 11.38T was originally installed, and, as the T designates, it supported the T1 WIC. However, it didn’t support static NAT mapping. So, I upgraded the IOS to 11.39T, which did support the static NAT mapping but, as it turns out, had a bug with regard to ISDN and the dialer interface. I tried several versions in two different feature sets until I was able to accommodate all requirements.

Never assume

Never assume anything with Cisco IOS versions. Instead, you can use the IOS feature navigator on the Cisco CCO Web site to determine which features are available in which versions and feature packs.

Another issue I ran into was a lack of good support information for the NT RRAS configuration. Microsoft appears to be pruning this information off of its TechNet Knowledge base and supplanting it with information mostly relevant to Win2K. (When will Microsoft learn that the world does not upgrade at Microsoft pace?) Fortunately, the Netopia support site contained information about just such an NT-to-Netopia tunnel setup, which helped with the minute details. Remember one important detail: The VPN adapter properties can’t be set using the Routing and RAS Admin utility. As things often are with NT, you don’t always find things where they should be. When changing VPN props, use the Network control panel applet. Set it up to dial out and receive calls using demand-dial routing.


Figure B
Now the remote offices connect directly to the home office through the Cisco 3620 router.

Regardless of the foibles, this new setup appeared to respond with very little latency. Check out Figure B to see how the new design came out.

Of course, this may have been because I configured it with the least taxing form of encryption. After I finally got all the tunnels up, they appeared stable. However, after restarting the RRAS server, it was sometimes necessary to manually reinitiate some tunnel connections. This was also a more viable alternative in the given situation because of budgetary constraints. One advantage to this configuration is that the RRAS server can be remotely administered. Another is that the tunnel endpoint at the home office is hidden behind the router, thereby improving security somewhat. Although I generally prefer to terminate the tunnels at the actual access device, this implementation scenario worked well to solve the problem at hand.