For an IPX workstation to communicate with a NetWare server via an IP network, the workstation IP Tunnel program encapsulate s IPX packets within an IP datagram for transport over the IP network. When the packet arrives at the destination server, the IP Tunnel NLM strips off the IP headers and trailers, and the packet is sent out on the network or to the server processes expecting to see an IPX packet.

If you decide to use the IP Tunnel software, be aware that it requires some configuration of both the workstation and server. First, the workstation needs to know the destination IP address of the remote NetWare server. This address is defined as a gateway in the net.cfg or Virtual Loadable Module (VLM) setup files. Second, the server needs to know the IP address of the next hop router so it can reach the remote workstation. This information is usually gleaned from Routing Information Protocol (RIP) packets. It also can be coded in the sys:\etc\gateways file. This will place the appropriate entries in the NetWare server IP rou ting table every time the server is rebooted.

Encapsulating IPX traffic within IP datagrams provides several advantages for a wide-area operation of IPX-based applications. First, you do not have to route IPX across your WAN, and, therefore, you do not need multiprotocol routing. But, more important, IPX and its routing updates can consume a lot of bandwidth on WAN connections. This can be eliminated by using the tunnel software. IPX over the WAN is also undesirable because of the traffic consumed by IPX-specific protocols, such as the Service Advertising Protocol (SAP), IPXRIP and NetWare Core Protocol (NCP) packets generated by the NetWare shell and server processes. By using IP relay, all of this dynamic advertisement is replaced with a static configuration. This makes for much more efficient use of the WAN bandwidth, even though the packets transmitted may be a bit larger because of the encapsulation of data within both IP and IPX headers.

The downside to static configuration is that it is static and does not adapt to link failures.

Q: I've heard about new Internet protocols, such as IIOP, that "tunnel" through HTTP. Can you explain this technique and what it is used for?

A: Depending on your firewall, you may be limited in the number and type of applications you can use on the Internet. In many cases, most traffic is limited in some way, except for HTTP traffic. Application developers who want to use Object Request Broker (ORB) technology across the Internet have been frustrated by these firewalls. As a means to get around them, vendors have developed a method for encapsulating Internet Inter-ORB Protocol (IIOP) calls in HTTP Get and Put calls. By doing this, they can make their applications function across almost any firewall.

The first product that used this technique was IONA Technologies' Wonderwall. Since then, we have seen Visigenic VisiBroker (IIOP), WebLogic's JDBC Driver and Vosaic's TV Station for Java offer the same capability.

Although it works now, we question using this approach. After all, the entire purpose of a firewall is to control access from the rest of the world at the boundary of the enterprise. As these tunneling techniques become more widespread, they effectively negate the firewall because attacks to the ORB behind the firewall could be made over the HTTP protocol. On the other hand, it's an easy way of providing "public" IIOP-based applications over the Web securely.

For real enterprise applications, it makes more sense to choose an unused (and therefore obscure) port and make it accessible on your firewall specifically for IIOP use. While security through obscurity is rarely a defensible strategy, it is more dependable than relying on the very well-known HTTP port and protocol to secure your network. Also note that you are in the position of relying on the security and authentication mechanisms built into the ORB products. Implementations of the standard CORBA security service have been slow to reach the market, but whether you use the security built into the ORB or a standardized mechanism, it can hardly be worse than the anemic security mechanisms inherent to most Web servers.

Anthony Frey can be reached at afrey@nwc.com. Chris Lewis is working in Europe and can be reached at chrisl@netcomuk.co.uk.