Hardware

Fourth time is the charm for this member's DSL effort

Establishing a DSL connection to a UNIX server became a nightmare for this IT manager. Find out how a seemingly simple project took three wrong turns before a solid solution was found.


By Warren Seetahal

Establishing a DSL connection to a UNIX server to facilitate remote access for employees may sound simple, but my company found that it can easily turn into a nightmare. Our UNIX VPN project didn’t go as smoothly as we had hoped, but it was ultimately successful, and we learned a great deal from the hurdles we encountered. Hopefully, by reading through our failed attempts, you’ll be able to avoid similar mistakes.

Examining the tech project
A while back, our organization had to upgrade its dial-in Telnet connection to the UNIX server to a connection over the Internet. This was simple—the existing modem connected to a serial port on the server, and then we configured it to dial up to the Internet.

As the UNIX server did the dialing, it had an IP address assigned to it—this made it easy for a client to access the UNIX box. However, due to the limitations of SCO 5.0.5, internal personnel were always required to update the routing table of the UNIX server and pass the IP address to the requesting client whenever the Internet connection was dropped and subsequently reconnected. In that scenario, we found ourselves dealing with the following issues:
  • A fixed IP that cost us thousands of dollars
  • A dial-up connection that failed every three to four hours
  • Each dial up resulting in a different IP assignment to the UNIX box

As technology progressed, we were once again required to upgrade our connection speed to DSL. This, in contrast to the earlier project, wasn’t as easy as it sounded, but it was necessary to facilitate updates and new projects. Our goal was to have a more permanent connection—or at least a way to inform personnel of our IP address—along with better speeds for downloads and uploads to and from our UNIX system.

Off to a bad start
First, we checked with our local ISP for available options and this is what we found:
  • Satellite: no license available to non-ISPs
  • Fixed IP with leased line (64K available): too costly and too slow
  • Fiber optic: not yet tested; deploying company still testing—no release date available
  • ADSL using PPPoA: 1.44 Mbps transfer rates; it provided a dynamically assigned IP address, but the connection time would be fairly long—at least eight hours
  • Cable modem: provider was having many issues and uncertainties with its product; as the number of subscribers had increased, the performance had slowed down at the subscriber level

After testing and considering all options, we decided to go with the ADSL option. This approach, however, would mean that we wouldn’t hit two initial objectives:
  • A dynamic IP address assignment
  • Support for PPPoE, which is the more recognized standard

Attempt #1
Because the ADSL modem had four separate Ethernet ports to connect to the internal Ethernet network, we decided to connect two senior employees’ PCs directly to the modem for testing. The PCs had personal firewalls (ZoneAlarm) installed and the ADSL setup was straightforward.

We connected an NT server to the ADSL, and it too had a straightforward installation. The server was to act as a proxy server to the Internet for the rest of our main office.

Now came the real challenge: How were we to devise a means to allow remote logons to the UNIX box?

We tried setting it up in the same manner that we did with the dial-up modem—but it didn’t work. Next, we tried allowing the DSL to dial to the Internet itself. We then set the default gateway of the UNIX server to the internal IP address of the ADSL, but that too failed (see Figure A).

The ADSL port connected, but when we tried to telnet to that port, the ADSL answered instead of the UNIX server. Our next move was to try to enable port forwarding. But that was not a characteristic feature of our Alcatel modem.

Figure A


Attempt #2
We needed to try another approach and decided to get a simple Linksys router to act as the mediator between the UNIX and the ADSL boxes (see Figure B). The router was used to dial up the modem, and the default gateway on the UNIX box was now set to the router’s IP address, 192.168.0.10.

Figure B


This didn’t work either. While the router did the dialing for the UNIX box, port forwarding was still required between the Alcatel modem, the router, and the UNIX system. As we discovered earlier, this was not possible. If this was to work, we needed to get the UNIX system to dial to the DSL itself.

Attempt #3
The ideas to solve the issue started rolling in again from tech team members. We learned that we could actually get the UNIX system to dial up to the Internet through the ADSL. We decided to forget the newly purchased router. We tried downloading some script files from a Web site that claimed to allow a UNIX system to dial through the ADSL and allow a telnet login. We had to edit some of the files in the /etc/ppp directory and usr/bin directory. Again, we were unsuccessful.

Finally, the right approach
It turned out that the solution was right under our noses the entire time. We realized we could configure the NT proxy server as the router to our UNIX server and set the default gateway on the UNIX server as the IP address for the NT server (see Figure C).

Figure C


We then carried out the following procedures:
  1. At the UNIX server, we typed > route change default 200.10.10.10.
  2. The UNIX server only needed one NIC, so we removed the additional one and eliminated the direct connection to the ADSL.
  3. We enabled IP forwarding on the NT server.
  4. We installed PPTP on the server.
  5. RAS was already installed and was configured to start automatically, so we simply added a few VPN connections.
  6. We configured the VPN connections to allow dial-in and to provide a range of allowed IP addresses to connecting clients.

Clients only required a VPN dial-up configuration setup. They would use the same telnet connection that they used internally because when they connected to the NT server through the VPN, they became part of the internal network.

Since we didn’t have a permanent IP, we downloaded a program called follow-me-ip. This is a small piece of code that “sits” on the NT server, which uploads the IP address of our NT server to a Web site every 15 minutes.

We went through a testing process and found that it worked. We had discovered a simple and cost-effective solution to a problem that gave us headaches for weeks.

Warren Seetahal is the IT manager for a group of 21 companies and is also completing his MBA in Operations and Information Systems.


 

Editor's Picks