Next Previous Contents

4. Other IP Masquerade Issues and Software Support

4.1 Problems with IP Masquerade

Some protocols will not currently work with masquerading because they either assume things about port numbers, or encode data in their data stream about addresses and ports - these latter protocols need specific proxies built into the masquerading code to make them work.

4.2 Incoming services

Masquerading cannot handle incoming services at all. There are a few ways of allowing them, but they are completely separate from masquerading, and are really part of standard firewall practice.

If you do not require high levels of security then you can simply redirect ports. There are various ways of doing this - I use a modified redir program (which I hope will be available from sunsite and mirrors soon). If you wish to have some level of authorisation on incoming connections then you can either use TCP wrappers or Xinetd on top of redir (0.7 or above) to allow only specific IP addresses through, or use some other tools. The TIS Firewall Toolkit is a good place to look for tools and information.

More details can be found at IP Masquerade Resource.

A section on more about forwarding services will be added soon.

4.3 Supported Client Software and Other Setup Note

** The following list is not being maintained anymore. Please refer to this page on applications that work thru Linux IP masquerading and IP Masquerade Resource for more detail. **

Generally, application that uses TCP and UDP should work. If you have any suggestion, hints, or questions about applications with IP Masquerade, please visit this page on applications that work thru Linux IP masquerading by Lee Nevo.

Clients that Work

General Clients

HTTP

all supported platforms, surfing the web

POP & SMTP

all supported platforms, email client

Telnet

all supported platforms, remote session

FTP

all supported platforms, with ip_masq_ftp.o module (not all sites work with certain clients; e.g. some sites cannot be reached using ws_ftp32 but works with netscape)

Archie

all supported platforms, file searching client (not all archie clients are supported)

NNTP (USENET)

all supported platforms, USENET news client

VRML

Windows(possibly all supported platforms), virtual reality surfing

traceroute

mainly UNIX based platforms, some variations may not work

ping

all platforms, with ICMP patch

anything based on IRC

all supported platforms, with ip_masq_irc.o modules

Gopher client

all supported platforms

WAIS client

all supported platforms

Multimedia Clients

Real Audio Player

Windows, network streaming audio, with ip_masq_raudio module loaded

True Speech Player 1.1b

Windows, network streaming audio

Internet Wave Player

Windows, network streaming audio

Worlds Chat 0.9a

Windows, Client-Server 3D chat program

Alpha Worlds

Windows, Client-Server 3D chat program

Internet Phone 3.2

Windows, Peer-to-peer audio communications, people can reach you only if you initiate the call, but people cannot call you

Powwow

Windows, Peer-to-peer Text audio whiteboard communications, people can reach you only if you initiate the call, but people cannot call you

CU-SeeMe

all supported platforms, with cuseeme modules loaded, please see IP Masquerade Resource for detail

VDOLive

Windows, with vdolive patch

Note: Some clients such as IPhone and Powwow may work even if you're not the one who initiate the call by using ipautofw package (refer to section 4.6)

Other Clients

NCSA Telnet 2.3.08

DOS, a suite containing telnet, ftp, ping, etc.

PC-anywhere for windows 2.0

MS-Windows, Remotely controls a PC over TCP/IP, only work if it is a client but not a host

Socket Watch

uses ntp - network time protocol

Linux net-acct package

Linux, network administration-account package

Clients that do not Work

Intel Internet Phone Beta 2

Connects but voice travels one way (out) Traffic only

Intel Streaming Media Viewer Beta 1

Cannot connect to server

Netscape CoolTalk

Cannot connect to opposite side

talk,ntalk

will not work - requires a kernel proxy to be written.

WebPhone

Cannot work at present (it makes invalid assumptions about addresses).

X

Untested, but I think it cannot work unless someone builds an X proxy, which is probably an external program to the masquerading code. One way of making this work is to use ssh as the link and use the internal X proxy of that to make things work!

Platforms/OS Tested as on OTHER machines

Basically all OS platforms support TCP/IP and give you the option to specify the gateway/router should work with IP Masquerade.

4.4 IP Firewall Administration (ipfwadm)

This section provides a more in-depth guide on using ipfwadm.

This is a setup for a firewall/masquerade system behind a PPP link with a static PPP address follows. Trusted interface is 192.168.255.1, PPP interface has been changed to protect the guilty :). I listed each incoming and outgoing interface individually to catch IP spoofing as well as stuffed routing and/or masquerading. Also anything not explicitly allowed is forbidden!

#!/bin/sh
#
# /etc/rc.d/rc.firewall, define the firewall configuration, invoked from
# rc.local.
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin

# testing, wait a bit then clear all firewall rules.
# uncomment following lines if you want the firewall to automatically
# disable after 10 minutes.
# (sleep 600; \
# ipfwadm -I -f; \
# ipfwadm -I -p accept; \
# ipfwadm -O -f; \
# ipfwadm -O -p accept; \
# ipfwadm -F -f; \
# ipfwadm -F -p accept; \
# ) &

# Incoming, flush and set default policy of deny. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
ipfwadm -I -f
ipfwadm -I -p deny
# local interface, local machines, going anywhere is valid
ipfwadm -I -a accept -V 192.168.255.1 -S 192.168.0.0/16 -D 0.0.0.0/0
# remote interface, claiming to be local machines, IP spoofing, get lost
ipfwadm -I -a deny -V your.static.PPP.address -S 192.168.0.0/16 -D 0.0.0.0/0 -o
# remote interface, any source, going to permanent PPP address is valid
ipfwadm -I -a accept -V your.static.PPP.address -S 0.0.0.0/0 -D
your.static.PPP.address/32
# loopback interface is valid.
ipfwadm -I -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# catch all rule, all other incoming is denied and logged. pity there is no
# log option on the policy but this does the job instead.
ipfwadm -I -a deny -S 0.0.0.0/0 -D 0.0.0.0/0 -o

# Outgoing, flush and set default policy of deny. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
ipfwadm -O -f
ipfwadm -O -p deny
# local interface, any source going to local net is valid
ipfwadm -O -a accept -V 192.168.255.1 -S 0.0.0.0/0 -D 192.168.0.0/16
# outgoing to local net on remote interface, stuffed routing, deny
ipfwadm -O -a deny -V your.static.PPP.address -S 0.0.0.0/0 -D 192.168.0.0/16 -o
# outgoing from local net on remote interface, stuffed masquerading, deny
ipfwadm -O -a deny -V your.static.PPP.address -S 192.168.0.0/16 -D 0.0.0.0/0 -o
# outgoing from local net on remote interface, stuffed masquerading, deny
ipfwadm -O -a deny -V your.static.PPP.address -S 0.0.0.0/0 -D 192.168.0.0/16 -o
# anything else outgoing on remote interface is valid
ipfwadm -O -a accept -V your.static.PPP.address -S your.static.PPP.address/32 -D
0.0.0.0/0
# loopback interface is valid.
ipfwadm -O -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# catch all rule, all other outgoing is denied and logged. pity there is no
# log option on the policy but this does the job instead.
ipfwadm -O -a deny -S 0.0.0.0/0 -D 0.0.0.0/0 -o

# Forwarding, flush and set default policy of deny. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
ipfwadm -F -f
ipfwadm -F -p deny
# Masquerade from local net on local interface to anywhere.
ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/16 -D 0.0.0.0/0
# catch all rule, all other forwarding is denied and logged. pity there is no
# log option on the policy but this does the job instead.
ipfwadm -F -a deny -S 0.0.0.0/0 -D 0.0.0.0/0 -o

You can block traffic to a particular site using the -I, -O or -F. Remember that the set of rules are scanned top to bottom and -a means "append" to the existing set of rules so any restrictions need to come before global rules. For example (and untested) :-

Using -I rules. Probably the fastest but it only stops the local machines, the firewall itself can still access the "forbidden" site. Of course you might want to allow that combination.

... start of -I rules ...
# reject and log local interface, local machines going to 204.50.10.13
ipfwadm -I -a reject -V 192.168.255.1 -S 192.168.0.0/16 -D 204.50.10.13/32 -o
# local interface, local machines, going anywhere is valid
ipfwadm -I -a accept -V 192.168.255.1 -S 192.168.0.0/16 -D 0.0.0.0/0
... end of -I rules ...

Using -O rules. Slowest because the packets go through masquerading first but this rule even stops the firewall accessing the forbidden site.

... start of -O rules ...
# reject and log outgoing to 204.50.10.13
ipfwadm -O -a reject -V your.static.PPP.address -S your.static.PPP.address/32 -D
204.50.10.13/32 -o
# anything else outgoing on remote interface is valid
ipfwadm -O -a accept -V your.static.PPP.address -S your.static.PPP.address/32 -D
0.0.0.0/0
... end of -O rules ...

Using -F rules. Probably slower than -I and this still only stops masqueraded machines (i.e. internal), firewall can still get to forbidden site.

... start of -F rules ...
# Reject and log from local net on PPP interface to 204.50.10.13.
ipfwadm -F -a reject -W ppp0 -S 192.168.0.0/16 -D 204.50.10.13/32 -o
# Masquerade from local net on local interface to anywhere.
ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/16 -D 0.0.0.0/0
... end of -F rules ...

No need for a special rule to allow 192.168.0.0/16 to go to 204.50.11.0, it is covered by the global rules.

There is more than one way of coding the interfaces in the above rules. For example instead of -V 192.168.255.1 you can code -W eth0, instead of -V your.static.PPP.address you can use -W ppp0. Personal choice and documentation more than anything.

4.5 IP Firewalling Chains (ipchains)

This is the firewall ruleset manipulation tool primarily intended for 2.2.x kernels (there is a patch for this to work on 2.0.x).

We will update this section to give several examples on ipchains usage soon.

See the Linux IP Firewalling Chains page and Linux IPCHAINS HOWTO for detail.

4.6 IP Masquerade and Demand-Dial-Up

  1. If you would like to setup your network to automatically dial up the Internet, the diald demand dial-up package will be of great utility.
  2. To setup the diald, please check out the Setting Up Diald for Linux Page
  3. Once diald and IP masq have been setup, you can go to any of the client machines and initiate a web, telnet or ftp session.
  4. Diald will detect the incoming request, then dial up your ISP and establish the connection.
  5. There is a timeout that will occur with the first connection. This is inevitable if you are using analog modems. The time taken to establish the modem link and the PPP connections will cause your client program to timeout. This can be avoided if you are using an ISDN connection. All you need to do is to terminate the current process on the client and restart it.

4.7 IPautofw Packet Fowarder

IPautofw is a generic forwarder of TCP and UDP for Linux masquerading. Generally to utilize a package which requires UDP, a specific ip_masq module needs to be loaded; ip_masq_raudio, ip_masq_cuseeme, ... Ipautofw acts in a more generic manner, it will forward any type of traffic including those which the application specific modules will not forward. This may create a security hole if not administered correctly.

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

Provided by Michael Owings.

Introduction

This section 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.

Next, you will need to get the latest version of ip_masq_cuseeme.c. The latest version is available via anon ftp from ftp://ftp.swampgas.com/pub/cuseeme/ip_masq_cuseeme.c. 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.

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.

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.

Help on Setting up CU-SeeMe

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

4.9 Other Related Tools

We will be updating this section soon to cover more ipmasq related tools such as ipportfw and masqadmin.


Next Previous Contents