Using TUNNEL to tunnel a firewall

Firewalls are usually placed at the connection to the internet. They shield local networks from outside attacks by screening incoming traffic and rejecting connection attempts to host inside the firewalls by outside machines. Most firewall systems allow hosts inside the firewall to connect to hosts outside it (outgoing traffic), however, incoming traffic is most often disabled entirely.

Tunnels are host protocols which encapsulate other protocols by multiplexing them at one end and demultiplexing them at the other end. Any protocol can be tunneled by a tunnel protocol.

The most restrictive setups of firewalls usually disable all incoming traffic, and only enable a few selected ports for outgoing traffic. In the solution below, it is assumed that 2 TCP ports are enabled for outgoing ports; one for the GossipServer and one for the Router.

JavaGroups has a mechanism that allows a programmer to tunnel a firewall. The solution involves a GossipServer and a Router process. Both have to be outside of the firewall, so other members (possibly also behind firewalls) can access it.

The solution works as follows. A channel inside a firewall has to use protocol TUNNEL instead of UDP as bottommost layer in the stack, plus either PING or TCPGOSSIP, as shown below (only the bottom two protocols shown):

      "TUNNEL(router_host=localhost;router_port=12001):" +
      "TCPGOSSIP(initial_hosts=localhost[12002];gossip_refresh_rate=10000;" +
                 "num_initial_members=3;up_thread=true;down_thread=true):"

TCPGOSSIP uses the GossipServer (outside the firewall) at port 12002 to register its address (periodically) and to retrieve the initial membership for its group.

TUNNEL establishes a TCP connection to a Router process (also outside the firewall) that accepts messages from members and passes them on to other members. This connection is initiated by the host inside the firewall and persists as long as the channel is connected to a group. Router will use the same connection to send incoming messages to the channel that initiated the connection. This is perfectly legal, as TCP connections are fully duplex. Note that, if Router tried to establish its own TCP connection to the channel behind the firewall, it would fail. But it is okay to reuse the existing TCP connection, established by the channel.

Note that TUNNEL has to be given the hostname and port of the Router process. This example assumes a Router is running on the local host at port 12001 and a GossipServer is running at port 12002.

Any time a message has to be sent, TUNNEL forwards the message to Router, which distributes it to its destination: if the message's destination field is null (send to all group members), then Router looks up the members that belong to that group and forwards the message to all of them via the TCP connection they established when connecting to Router. If the destination is a valid member address, then that member's TCP connection is looked up, and the message is forwarded to it^5.7.

To tunnel a firewall using JavaGroups, the following steps have to be taken:

1. Check that 2 TCP ports (e.g. 12001 and 12002) are enabled in the firewall for outgoing traffic
2. Start the GossipServer:

           start org.javagroups.stack.GossipServer -port 12002
   

3. Start Router:

           java org.javagroups.stack.Router -port 12001
   

4. Configure the TUNNEL protocol layer as instructed above.

5. Create a channel

The general setup is shown in fig. 5.1.

Figure 5.1: Tunneling a firewall

First, the GossipServer and Router processes are created on host B. Note that these should be outside the firewall, and all channels in the same group should use the same GossipServer and Router processes. When a channel on host A is created, its TCPGOSSIP protocol will register its address with the GossipServer and retrieve the initial membership (assume this is C). Now, a TCP connection with Router is established by A; this will persist until A crashes or voluntarily leaves the group. When A multicasts a message to the group, Router looks up all group members (in this case, A and C) and forwards the message to all members, using their TCP connections. In the example, A would receive its own copy of the multicast message it sent, and another copy would be sent to C.

This scheme allows for example Java applets, which are only allowed to connect back to the host from which they were downloaded, to use JavaGroups: the HTTP server would be located on host B and the gossip and Router daemons would also run on that host. An applet downloaded to either A or C would be allowed to make a TCP connection to B. Also, applications behind a firewall would be able to talk to each other, joining a group.

However, there are several drawbacks: first, the central GossipServer and Router processes constitute a single point of failure (if host B crashes)^5.8, second, having to maintain a TCP connection for the duration of the connection might use up resources in the host system (e.g. in the Router), leading to scalability problems, third, this scheme is inappropriate when only a few channels are located behind firewalls, and the vast majority can indeed use IP multicast to communicate, and finally, it is not always possible to enable outgoing traffic on 2 ports in a firewall, e.g. when a user does not 'own' the firewall.