CU-SeeMe and Linux IP-Masquerade Teeny How-To

By Michael Owings

Last Updated Oct 15, 1999

Introduction

This document will explain the necessary steps to get CU-SeeMe (both the Cornell and White Pine versions) working together with Linux's IP-Masquerade.

CU-SeeMe is a desktop video conferencing package available for both Windows and Macintosh clients. A free version is available from Cornell University. A significantly enhanced commercial version can be obtained from White Pine Software.

IP Masquerading allows one or more workstations on a LAN to "masquerade" behind a single Linux machine connected to the Internet. The workstations on the LAN can access the Internet almost transparently even without valid IP addresses. The Linux box rewrites outgoing packets from the LAN to the Internet in such a way that they they appear to originate from the Linux machine. Response packets coming back in are re-written and routed back to the correct workstations on the LAN. This arrangement allows many Internet applications to run transparently from the lan workstations. For some other applications (such as CU-SeeMe), however, the Linux masquerade code needs a little help to route packets properly. This help usually comes in the form of special kernel loadable modules. For more information on IP-Masquerading, see The Linux IP Masquerading Website.

Getting It Running

First you will need a properly configured kernel. You should have full support compiled in for both IP-Masquerading and IP AutoForwarding. IP Autoforwarding is available as a config option on kernels 2.0.30 and later -- you will need to patch earlier kernels. See The Linux IP Masquerade Resource for pointers to the IP-Autoforwarding material. The ipautofw client can be had here.

Next, you will need to get the latest version of ip_masq_cuseeme.c. The latest version is available here. Some browsers may require you to right-click on the link to download it. This new module will also be rolled up into the kernel 2.0.31 distribution. You should replace the version in your kernel distribution with this new version. ip_masq_cuseeme.c normally resides in net/ipv4 off of the Linux source tree. You should compile and install this module.

Now, you should set up ip autoforwarding for udp ports 7648-7649 as follows:

ipautofw -A -r udp 7648 7649 -c udp 7648 -u

OR

ipautofw -A -r udp 7648 7649 -h www.xxx.yyy.zzz

The first form will allow calls to/from the last workstation to use port 7648 (the primary cu-seeme port) . The second invocation of ipautofw will allow cu-seeme calls only to/from www.xxx.yyy.zzz. I prefer the former invocation, as it is more flexible because there is no need to specify a fixed workstation IP. However, this invocation also requires a workstation to have previously placed an outgoing call in order to receive incoming calls.

Note that both invocations leave UDP ports 7648-7649 on the client machines open to the outside world -- and while this does not pose an enormous security hazard, you should use appropriate caution.

White Pine 4.0 Users: I have been told that White Pine 4.0 uses a new port in addition to 7648; thus 4.0 users may have to set up forwarding for port 24032. I have not tested this personally, but am told the following line works (thanx to Jim Frost):

ipautofw -A -r udp 24032 24032 -h www.xxx.yyy.zzz

Finally, load up the new ip_masq_cuseeme module as follows:

modprobe ip_masq_cuseeme

You should now be able to fire up CU-SeeMe from a masqueraded machine on your lan and connect to a remote reflector, or another CU-Seeme user. You should also be able to get incoming calls. Note that outside callers should call using the ip of your linux gateway, NOT the masqueraded workstation.

Linux 2.2 and ipchains

I don't currently use this configuration (I'm still at 2.0) but some CU users have allegedly gotten this to work. Here is an email I received from one such user -- I hope it helps! 

From: "Moses Kamai" 
Date: Sun, 25 Jul 1999 17:52:32 -0400

Mikey,
I've got it!

Just follow the ipchains HOW-TO to configure the firewall/NAT/router part of
Linux.

Then use ipmasqadm autofw in a similar configuration as you have in your
docs.  There is one addition to lock in the ports.  Also, had to lock each
port to itself instead of a range.  When I specified a range it did not
work.  Here is an example.

# To forward incoming CUSeeMe ports
ipmasqadm autofw -A -r udp 7648 7648 -h 192.168.x.x
ipmasqadm autofw -A -r udp 7649 7649 -h 192.168.x.x
ipmasqadm autofw -A -r tcp 7648 7648 -h 192.168.x.x
ipmasqadm autofw -A -r tcp 7649 7649 -h 192.168.x.x
ipmasqadm autofw -A -r udp 23042 23042 -h 192.168.x.x

# To lock in the incoming or outgoing ports to the right port
ipmasqadm autofw -A -d udp 7648 7648
ipmasqadm autofw -A -d udp 7649 7649
ipmasqadm autofw -A -d tcp 7648 7648
ipmasqadm autofw -A -d tcp 7649 7649

The only problem I ran into was port 23042 caused a segmentation fault for
some reason; haven't figured out why.

Restrictions/Caveats

Password Protected Reflectors No way, no how. Uh-uh. Negatory. White Pine uses the source IP (as computed by the client program) to encrypt the password prior to transmission. Since we have to rewrite this address, the reflector ends up using the wrong source IP to decrypt it, which yields an invalid password. This will only be fixed if White Pine changes their password encryption scheme (which I have suggested), or if they would be willing to make their password encryption routines public so I could add in a fix to ip_masq_cuseeme. While chances for the latter solution are vanishingly small, I would encourage anyone reading this to contact White Pine and suggest the former approach. As the traffic on this page is relatively high, I suspect we could generate enough email to get this problem moved up on White Pine's list of priorities.

Thanx to Thomas Griwenka for bringing this to my attention.
Running a Reflector You should not attempt to run a reflector on the same machine where you have ip_masq_cuseeme and ipautoforwarding for port 7648 loaded. It simply won't work, as both setups require port 7648. Either run the reflector on another Internet-reachable host, or unload CU-SeeMe client support prior to running the reflector.
Multiple CU-SeeMe Users You cannnot have multiple simultaneous CU-SeeMe users on the LAN at this time. This is due largely to CU-SeeMe's stubborn insistence on always sending to port 7648, which can only be redirected (easily) to one LAN workstation at a time.

Using the -c (control port) invocation of ipautofw above, you can avoid to having to specify a fixed workstation address allowed to use CU-SeeMe -- the first workstation to send anything out on control port 7648 will be designated to receive traffic on 7648-7649. 5 minutes or so after this workstation has been inactive on port 7648, another workstation can come along and use CU-SeeMe.

Contacting Me

Feel free to email any comments or questions to mikey@swampgas.com. Or if you wish, you can call me up via CU-SeeMe.