IPX over VPN

Occassionally a problem like this appears: there is an office and there is a Netware fileserver inside. Another office pops up and there is a need to access files on the fileserver remotely. However, both offices have only IP-based connection to the Internet, usually DSL. The fileserver talks only IPX, and nobody around knows enough to dare to try to install the IPX-over-IP modules. Both offices also have Linux firewalls that connect them together via a VPN, and way too many Windows 2000/XP clients. The firewalls use eth0 for the LAN side, eth1 for the Net side, and tap0 for a sub-VPN managed by OpenVPN (see latter why).

Setting up a full VPN connection between the offices is usually not a problem. IPsec comes to rescue here.

There is a need for bridging the networks in a way the non-IP packets can get from one to another, encapsulated in IP. OpenVPN gets useful here. We use it to set up a tap0 interface on each side, and interconnect them across the already-existing VPN.

Then we also need to recognize the IPX packets and route them. For this, we need to set up IPX on both the firewall's internal Ethernet interface, and on the tap0 device created as the bridge.

The last step is setting up the IPX routing itself. For this, we need ipxd, a daemon from the ipxripd package, obtainable eg. here.

We will maybe also need to manually configure the network number in the IPX networking in Windows. In the local network interface in Properties we choose NWLink IPX/SPX/NetBIOS..., leave Internal network number at 00000000, pick a suitable Frame type (usually Ethernet 802.2), and specify the network number we chose for the satellite office (in our case 2, or 00000002, more later).

Network topology and addresses

The computer's address in Netware addressing scheme is composed of two values: network number and adapter number. The network number is a 32-bit arbitrary chosen number, while the adapter number is usually the MAC address of the Ethernet card. No two network interfaces in the machine can share the network number. Routing is done by moving the packets from interface to interface, according to the maps of the network numbers. This is set up by either the ipx_route command, or automatically by ipxd. We are lazy, so we chose the latter way. The network numbers have to be unique for each network.

We therefore create three segments. The first, 0x1, is the main office. The second, 0x02, is the bridge consisting of the two tap0 interfaces managed by OpenVPN. The third, 0x03, is the satellite office.

We end up with network interfaces being set this way: on the main office firewall the eth0 card gets IPX network address assigned to network 0x1, the tap0 gets assigned to 0x2. On the satellite office firewall the eth0 gets assigned to 0x03, the tap0 to 0x02.

The role of OpenVPN

We have IPsec already running between the machines, so we do not need anything to set up security nor authentication. This reduces the amount of work we have to do. The main firewall has internal IP address of 192.168.1.1, the satellite firewall is 192.168.2.1. Before starting setting up OpenVPN, we have to be able to ping between these two.

We therefore just set up the tunnel, no auth and no encryption, with IP addresses 10.254.0.1 (main) and 10.254.0.2 (satellite) for the tap0 interfaces. Then we set up IPX itself.

Setting up IPX

We use the ipx_interface command:
First fw: ipx_interface add eth0 802.2 1; ipx_interface add tap0 802.2 2
Second fw: ipx_interface add eth0 802.2 3; ipx_interface add tap0 802.2 2
We also enable the auto-primary:
Both fw: ipx_configure --auto-primary=on
We then run ipxd on both firewalls.

Set up scripts

Main firewall:

#!/bin/bash
modprobe tun
modprobe ipx
openvpn --dev tap0 --ifconfig 10.254.0.1 255.255.255.0 --proto tcp-server --persist-tun --daemon --verb 4
sleep 1
ipx_interface add eth0 802.2 1
ipx_configure --auto_primary=on
ipx_interface add tap0 802.2 2
ipxd

Satellite firewall:

#!/bin/bash
modprobe tun
modprobe ipx
openvpn --dev tap0 --ifconfig 10.254.0.2 255.255.255.0 --proto tcp-client --remote 192.168.1.1:1194 --persist-tun --daemon --verb 4
sleep 1
ipx_interface add eth0 802.2 1
ipx_configure --auto_primary=on
ipx_interface add tap0 802.2 2
ipxd

Debugging, or divide and conquer

A lot can go wrong with the setup. Here are some tips:

• Run openvpn manually from the console, with --verb 7. It will show all the packets as they go across the Net.

  This will let you show the traffic between the nodes.

• You have to be able to ping 10.254.0.1 from 10.254.0.2 and vice versa. If this does not work, debug the OpenVPN setup.
• Run ipxd manually from the console, with -d parameter. This will spit debug messages on the console, helping you see the IPX routing information updates being done.
• /proc/net/ipx* files contain a lot of useful information. The ipx_interfaces should have two lines of content, one for eth0 and one for tap0. The ipx_route should be populated after ipxd runs.
• Use slist command to see the list of available Netware servers. Its output should be the same on both main and satellite LAN. Allow a minute or maybe two for propagation of the routing info.

Options

OpenVPN can also supplement the role of IPsec if we don't already have a VPN there.

Comparison of IP and IPX addressing and routing

The IP address has two parts, defined by the netmask; the network address are the bits that are set to 1, the node address are the bits set to 0.

The gateway concept is the same in IPX and IP. For the routing purposes, the gateway to a non-local IPX network is the network:node address of the next node on one of the local networks, where the packets have to be forwarded to.