1.9. Appendix: Firewalls, NAT, & Internet Connection Sharing
Prev  1. The X Window System  Next

1.9. Appendix: Firewalls, NAT, & Internet Connection Sharing

One serious barrier to using X on some machines is the action of other programs that deliberately block signals from the X client from reaching the local server software.

Firewalls are software security programs that many people use to protect their networks from outside hacking. One of the features of most firewalls is to block incoming communications to sockets other than the reserved socket numbers for email, http, or other services the corporation wants to support.

Similar problems arise with Network Address Translation (NAT), a scheme for allowing multiple computers on a local network to share a single Internet connection. Microsoft Windows 98 and later offers a form of NAT they call “Internet Connection Sharing”. Under this arrangement, for example, I have three computers in my home that can all access the Internet through a single cable modem connection. To the outside world, I appear to have only a single computer there, because all three are sharing the same IP address.

If you are connected to cable modem service via a router, you are probably using NAT, a firewall, or both.

Why is this a problem? To answer that, we need to talk a little bit about how machines provide different services to one another over the Internet. Machine-to-machine communication over the Internet is generally carried out by sending signals to one of several sockets, a software analogue of the hardware device that allows you to “plug in” other devices.

Sockets are identified by numbers. Some numbers are reserved for common Internet services (telnet, ftp, email, and http all have their own specific socket number).

Figure 4.5. Making a telnet connection

Making a telnet connection

For example, to make a telnet connection, your local PC sends a signal to a remote server asking for a connection on socket 23 (the socket number reserved for normal telnet connections). The server sends a signal back that acknowledges the request, and the resulting two-way communications channel is then used for your telnet session.

Figure 4.6. Telnet Connections Through a Firewall

Telnet Connections Through a Firewall

If you are behind a firewall, telnet probably still works. That's because most firewalls are designed to block connections initiated from outside, but will allow requests initiated by local machines to "tunnel through".[28]

X also communicates via sockets, using socket number 6000 + display-value. For example, if your DISPLAY is set this way: 

setenv DISPLAY localMachineAddress:0

then X uses socket 6000, but if your display is set this way: 

setenv DISPLAY localMachineAddress:2

then X uses socket 6002.

Figure 4.7. Making an X Connection via telnet

Making an X Connection via telnet

An X connection begins with an ordinary telnet session. Eventually, you issue a command to run some X program such as xterm. That program, running on the telnet server, then tries to open a connection via socket 6000[29] to your local PC. If you are running X server software on your local PC, it accepts the socket 6000 connection, and a new communications path is thereby established for X windowing information.

Figure 4.8. X Connection Blocked by a Firewall

X Connection Blocked by a Firewall

Now, throw in a firewall, and things get messy. From the viewpoint of the firewall, the socket 6000 connection is being initiated by an outside machine. Most firewalls will block any such attempt. The connection attempt fails, and you see the dreaded “could not open connection…” message.

If you are trying to use X from behind a firewall, your best bet is to connect via a Secure Shell (ssh), as described in the section called “Running X via ssh”. Alternatively, you might ask the system's administrator to permit external connections to socket 6000. If you are running a Linux system, consult your documentation on “ipchain” and/or your firewall package to see how to do this.

A similar problem arises with Network Address Translation (NAT). NAT can confound X because when an X client tries to send information to your X server software on socket 600x, the NAT software has no clue as to which of its local machines it should route that information to. Luckily, some NAT packages allow you to configure the software to route specific socket requests to specific machines. Using these instructions, for example, I set up Windows Internet Connection Sharing to route socket 6000 to one machine and 6001 to another. Then I can run X server software on either machine and, by setting my DISPLAY appropriately, have the X windows appear on the machine I'm seated at.[30]

But the simplest way around this problem is to launch your remote programs via ssh, as described in the section called “Launching via an ssh command” and the section called “Launching via PuTTY”.

Running X via ssh

When you use ordinary telnet, ftp, or X over the Internet, information to and from your PC are being sent as clear text. In theory, anyone else connected to the same local network as you (or as the machine with which you are communicating) could be reading the packets of information flowing by, writing down your passwords, etc.

Secure Shell (ssh) is an alternative set of Internet tools that provide telnet-like and ftp-like capabilities but transmit all information in encrypted form, thus foiling potential eavesdroppers.

I mention this here because ssh has another benefit -- it can be used to “tunnel” the X protocol through many firewalls and NAT systems.

Figure 4.9. making an X Connection via ssh

making an X Connection via ssh

ssh connections start off much like telnet connections, though the socket number is 22 instead of 23. But if X tunnelling has been specified, and we send a command to the ssh server to start running an X program, things get very different.

Our ssh connection on the server will run with a $DISPLAY value that maps right back to the ssh server, though usually on an unusually large display number. Therefore when the X program tries to open a connection to the X server that will display its windows, it connects to itself, on a socket number that is watched by the ssh server software. That ssh server software then sends a signal along the already-established ssh communications path indicating that an X connection was attempted. Back at your local PC, your ssh client software then opens a connection to socket 6000 on your local PC, where it gets picked up by your X server software.

All of this is invisible to the firewall, because the "new" X connections don't cross the firewall, and the actual X information is channelled along an already existing ssh communications path.

To do this, you need two things:

  1. The machine that will be running the X applications (the X client) must also be running an ssh server.

  2. The machine where the X windows graphics are to be displayed (the X server) must have an ssh client program available.

Where do you get an ssh client?

Newer versions of X-Win32 and Exceed already include ssh support. Beware, however, of the X-Win32 distribution provided by ODU to all ODU students under its contract with StarNet. Once you enter the registration code for that distribution, it is limited to connections made with machines at ODU's IP addresses (128.82.??.???). But, as the diagram above shows, when we tunnel X through an ssh connection, the connection to our local PC's server comes from that same PC itself (using a special IP address 127.0.0.1, which is reserved to mean “local machine” - not via the network). Since that address doesn't begin with 128.82, the ODU distribution of X-Win32 refuses those connections.

  • You can use X-Win32 from ODU's web site if you don't give it the ODU registration code.

  • You can use X-Win32 downloaded from StarNet's own web site.

Either way, without a registration code, it runs in “demo” mode where it must be shut down and restarted every two hours.

ssh is also available as part of the CygWin package. And the PuTTY program, recommended earlier for use as a Windows telnet client, also makes a good ssh client. Finally, check out this list from the OpenSSH project at http://www.openssh.org.


[28] An exception: companies who want to prevent their employees from web surfing, using chat, etc., during work hours may set their firewalls to block even outgoing requests on the socket numbers associated with those services.

[29] I'll assume you are using display number 0, as is usually the case.

[30] And I know I've gotten it wrong when someone screams from the other room, “Dad! What's this emacs thing popping up on my screen?”

Prev  Up  Next
1.8. Appendix: Alternative & Related Technologies   2. Editing under X