Section 2

  • Virtual Private Dial-up Network - Illustrated

  • Section 2 - Tunnel/2 Configuration

      Tunnel Master

      The Tunnel Master is a server product to be placed within your organization - behind the company firewall. One Tunnel Master within the corporate LAN would typically be enough, but if needed the network can be expanded on demand. Just plug in new Tunnel Masters as needed. There are no exact measurements on the load that one Tunnel Master can handle, but from initial tests it was reported that 160 active Tunnel Slaves (running a max of 33.3 Kbps) averaged the Tunnel Master at about 5% CPU usage (just to give an impression).

      The Tunnel Master consist of two basic modules. The Tunnel Master itself (TM.EXE) and a command line utility (SETTUN.EXE) that feeds instructions to the Master. As shown below, a very simple, low resource usage user-interface constitutes the look and feel of the Tunnel Master:


      Figure 1 The Tunnel Master (TM.EXE)

      A set of optional command line parameters are available. We will address parameters as needed throughout this guide, but for a summary check the list below:

      • Tunnel interface address (e.g. 10.2.1.1)
      • Tunnel interface netmask (e.g. 255.255.0.0)
      • Dial retries (when dialing slave)
      • Connect timeout (when dialing slave)
      • Connect test interval (when dialing slave)
      • Dial prefix (e.g. ATDT - when dialing slave)
      • TCP Port number (for the actual Tunnel)
      • Hostname lookup disable (performance option)

      The Tunnel Master functions by creating an interface on the TCP/IP stack which applications use to communicate. Packets received by this interface are then sent to the appropriate node within the VPN network.

      The routing changes on your network are accomplished by automatically inserted PROXY ARP entries, one per known Tunnel Slave. These entries will add all the necessary routing capability in order for your network to recognize, and communicate with Tunnel Slaves. Use the OS/2 command line utility 'ARP' to follow the process.

      If you find that the PROXY ARP entries don't do the job in your network, then static routing can be used to achieve the same effect. To do that, just update the company router with a static route from the LAN0 address to the the Tunnel Network address.


      SETTUN.EXE

      The Tunnel Master's other basic module (SETTUN.EXE) is the manipulative utility which provides an even simpler interface for even easier operation. Since SETTUN is designed for use from other programs (e.g. a dialer or telnet session) a simple user-interface is a must!


      Figure 2 The external manipulative utility 'SETTUN.EXE'

      As a small command line utility program, SETTUN feeds instructions to the Tunnel. When used, the executable must be located and run within the same directory as the Tunnel component being controlled.

      Both SETTUN and TM can be run with the -? option to show a list of available parameters.

      Notice, you can just run TM.EXE with default values - that will automatically put it into operation. You probably would like to change passwords and customize it a bit, so read on.

      Addressing

      Using F/X Tunnel technology, a Tunnel Master server needs to be run on a central machine which has a fixed IP address. The Tunnel Master will have an address within the VPN assigned subnet and will be given a subnet mask which will define the VPN subnet. For example:

        tm /r:10.1.1.1 /n:255.255.0.0

      This will create a VPN subnet of 254 * 254 (64516) nodes. From this address space, smaller subnets can be assigned to the remote stations, which will run the Tunnel Slave application. For example:

        ts /r:10.1.2.1 /n:255.255.255.0

      This will create a remote subnet of 254 usable addresses with 10.1.2.1 being the remote router.

      Tunnel Security

      The standard F/X Tunnel ships with a simple but reliable 3-way-handshake user-authentication security mechanism. At the Master, passwords are stored in a 'PASSWORD.TXT' file, found in the same directory as the Master. The format of this file is one password per line, empty lines are ignored, a max of 300 passwords are accepted and the minimum length of individual passwords is 3 bytes. At the remote site, a password can be passed into the Tunnel Slave from the command line with the '/s:' option. If the slave identifies itself with a password which is contained in the password file, it is granted access. For example:

        ts /r:10.1.2.1 /n:255.255.255.0 /p:123-4567 /s:snoopy

      The simple use of the 'PASSWORD.TXT' file is illustrated below (remember that the password file should be located in the same directory as the Master itself):

      master_peanut
      snoopy
      salespassw__
      Figure 3 Master Password File

      The password file is mandatory on a Tunnel Master setup. Without the password file, no slaves will be able to connect.

      The Tunnel Master offers different levels of security. Via plug-ins you can add DES encryption (extra cost option) or even write your own plug-in to apply the security that matches your organization's needs.

      Tracing

      Tunnel/2 also support the OS/2 utility 'IPTRACE' for IP packet monitoring. Additionally Tunnel/2 offers tracing to the text file 'TUNNEL.TRC'. You can enable and disable tracing directly in the user-interface of Tunnel/2.

      Tunnel Software is often used in networks where monitoring is done in one central location. Several methods exists (e.g. Syslog), but instead of binding Tunnel/2 to any of these, it will spawn a .CMD file when an error occurs (fatal as well as non-fatal).

      The .CMD file, called 'TRACE.CMD' must be located in the working directory of Tunnel/2 in order to be called. The actual error is then provided as a command line parameter for 'TRACE.CMD' - simple, yet flexible and effective!

        Tunnel Slave

        Use the Tunnel Slave to connect remote workstations to your corporate network via the normal public Internet (or other media, such as X.25 - upon request).

        The Tunnel Slave is made up of two programs (like the Master). You need the Tunnel Slave itself (TS.EXE) and the small SETTUN utility to control the Slave's activity. Both programs will display the available options if started with the parameter -?.


        Figure 3 The Tunnel Slave (TS.EXE)

        The Tunnel Slave has several command line parameters. Only three parameters are mandatory: Master Address, ISP Gateway Address and Password.

        • Tunnel Master address
        • TCP port number
        • Connect retries
        • Tunnel interface address (e.g. 10.2.2.1)
        • Netmask of the Tunnel interface
        • Gateway of the ISP (can be grabbed from the InJoy dialer)
        • Password
        • Phone number (for master triggered dial-on-demand)
        • Force immediate connect

        Tunnel Slave robustness

        The Tunnel Slave is designed to work using unstable phone lines and accordingly introduces quite a few mechanisms to keep the bunny going, and going, and . . .

        • Re-connecting
          Ah, a task of the Internet dialer you might think, and that is true. However, the Tunnel maintains a TCP/IP (socket) connection to the Tunnel Master and that connection can break too. The Slave will re-connect the socket connection as needed and if it finds itself unsuccessful, it will start pinging the gateway IP.

          Pinging the ISP gateway IP address is beneficial in the event that the dialer is not connected. A ping to the ISP gateway address should definitely go to the dialer interface and therefore trigger a Dial-On-Demand reconnect.

          The Tunnel Slave offers the /T: parameter to tell how many times the Tunnel Slave should try to re-connect the tunnel socket. If all attempts fail, the Slave will try again next time an outgoing packet is pushing.

        • Socket tuning
          You might want to use the following two commands with SETTUN in order to make the Tunnel disconnect and reconnect immediately when line conditions permits. The Tunnel Slave will get along without this, but consider the following to be a nice fine-tuning for optimal results.

          • Use SETTUN /C
            To clean disconnect the Tunnel Slave immediately at connection loss. Or, if possible, run SETTUN /C just before the connection loss (as when using InJoy's Dial-On-Demand with an idle timeout). The latter procedure is preferred, since the fact that the Slave has disconnected will reach the Master.

          • Use SETTUN /F
            To force an immediate connect to the Tunnel Master. Using InJoy's autostart feature this command can be issued as soon as there is an Internet connection. It may not save much time, but it could mean the difference of starting a telnet connection in maybe 2 seconds instead of 30. If used corporate wide, over the years this could add up to a a lot of saved manpower.

          Notice, all packets going to the Tunnel Slave while not connected, will be queued. This too will add incredible speed in the process of getting your TCP/IP applications connected immediately once the Internet connection is back.

          Download Tunnel/2 and see for yourself!

        Dialing and Dial-On-Demand

        Tunnel/2 could run over a leased line, but as that would bring back in a cost which Tunnel/2 was designed to avoid, an Internet dialer is mostly needed to establish connectivity with the Internet.

        InJoy is able to provide a robust PPP implementation with dial-on-demand capability. By configuring InJoy's 'disconnect actions' to connect when InJoy sees the string 'RING', it is possible to cause a remote site to connect by dialing the phone number of the modem and then hanging up after one ring. This provides a capability of being able to bring the remote site online when a connection is desired from an outside source.

        The tunnel master has the capability of accepting a phone number from each Tunnel Slave. If the Tunnel Master receives a packet destined to a remote slave which is not currently on line, it uses the stored phone number to dial the remote system and hang-up. This will cause the remote system to connect. Once the Tunnel Slave is connected, any packets the master is storing for this slave are forwarded. The packet buffering allows for speedy delivery once the connection is there and thereby speedy connections for the TCP/IP applications.

        In order to provide two way dial-on-demand, the Tunnel Master must have one or more modems with which to dial the remote sites. The communication ports for these modems must be listed in the 'DEVICES.TXT' file, found in the same directory as the master. These modems will be configured by sending them the contents of the 'INITSTR.TXT' file, found in the same directory as the master. The initialization string must be the same for each modem, so modems must be sufficiently similar for this to work. In practice, this is rarely a concern as simple dialing requires little more than a simple reset string such as 'AT&F'. The 'INITSTR.TXT' should NOT contain empty lines or CRLF, as TM.EXE will send out the necessary CRLF. A further point to note is that since these modems do not connect with the remote site there is little reason to use expensive, high speed modems. Almost any reliable modem will do.

        Collected in this check list are all the actions needed to successfully setup the dialing of remote Slaves:

        1. Slaves must be started with a phone number as parameter.

          The phone number is then automatically delivered to the Tunnel Master at each Slave connect.

        2. Internet Dialer at the Slave location must dial when seeing a 'RING'.

          Enable this functionally in the InJoy dialer, or make a REXX front end for any other OS/2 Internet dialer.

        3. Define available COM ports for dialing out.

          The COM ports available for dialing out will be controlled by the the Tunnel Master. All that needs to be done is to write them down in a text file, like this:

          DEVICES.TXT
          com2
          digi8
          Figure 4 Master Port Definition File

          You can define as many as 200 ports, each port consisting of a maximum length of 10 bytes.

        4. Check belonging parameters.

          You can skip this step if you are not maintaining a real big network and if you are not billed per call. Otherwise, count on the default values.

          However, if you need to tune the outside dialing you have 3 parameters at your service:

          • Tries
            This parameter simply defines how many dials TM will launch if TS is not connected. As soon TS is connected, TM will stop dialing it.
          • Interval in seconds
            The Interval parameter informs TM how often it must check for a Slave to be online. This is to make TM discover when a slave is online, so dialing can be stopped.
          • Timeout in seconds
            This is the connection timeout. If a client is not connected within this time an error message is given. The whole dial-out operation is retried at the arrival of the next packet destined for that particular Slave.

        5. Edit the modem initialization string.

          The contents of 'INITSTR.TXT' is send to the modem before each dial attempt.

          INITSTR.TXT
          AT&F
          Figure 5 Modem Initialization string definition file

        6. Put on the modems.

          The Tunnel Master obviously needs at least one modem to be able to dial out. The dial will be attempted at a low speed (9600 Kbps) and the only thing the modems need, is the ability to understand simple AT commands.

        Tunnel/2 with the InJoy Internet Dialer

        The InJoy Internet Dialer will smoothly integrate with Tunnel/2, but it is NOT required for a completely functioning F/X Tunnel system. However, InJoy must be used to have full two-way Dial-On-Demand capability, as it is simply the only OS/2 dialer supporting this.

        InJoy is the leading OS/2 dialer and in July 1997 it had risen to first place in OS/2 software sales. If you are not familiar with this program you should take a look at the fastest, most featured and reliable Internet dialer for OS/2. InJoy was highly honored when nominated as one of the Best Internet Tools (cross platform) by the Shareware Industry Foundation.

        The Dial-On-Demand (DOD) is accomplished by using the standard InJoy Dial-On-Demand in one direction - from workstation to ISP. The other way around the Tunnel Master uses a few modems to trigger the InJoy Dialer to do a call back. The setup for both types of Dial-On-Demand is shown in the following InJoy dialogue:


        Figure 6 Dial-On-Demand configuration in InJoy

        Besides the Dial-On-Demand features, InJoy offers many features which help in setting up a robust VPDN environment. Features like re-dial, re-connect, exit at failure, tracing (both built in and supporting the OS/2 utilities IPTRACE and IPFORMAT), connection logs, terminal mode, multiple phone number lists and autostarting/stopping at literally any event.


    Copyright © 1997, 1998 F/X Communications - All Rights Reserved.