Resolution of a few problems related to address translation:
	$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ JMO $$ 08/98 $$$

Address translation faces serious problems with
some applications. These applications which pose such a problem
generally have something in common. From the remote part (WAN),
they open connections to the LAN. As we saw in the description
concerning NAT, for it to function correctly,
the connections must open from the inside (LAN) to the
outside (WAN)...
 NB: The connections here are logical TCP or UDP connections, they are not
 necessarily related to physical
 connections (RNIS, X25, etc...).
The workaround consists in telling the device that some ports (TCP or UDP)
need to be automatically directed to specific machines. Obviously,
for each port, only one machine can be specified, but
most of these applications accept specification of a port which can be
different from one machine to the next.
Caution, these problems are not systematic (it depends on the version
of the application and sometimes on the platform used). If the application works,
you do not need to do anything!!
On the other hand, we cannot fail to applaud the behaviour of the
support services for these applications who categorically refuse to
give us the structure of the packets which contain this data.
This data could enable us to make the orders described below
automatic, and above all, dynamic...
When working with address translation, you are advised not to
use the "connect" command. If you do, the ISDN and PPP
connections will be enabled, but address translation will not
be implemented. The result is that we use "connect fouraccs",
since if we attempt to "ping www.netline.fr", the frame
will leave for the destination without modification of its source address
and it is unlikely that any response will come back. It is preferable
to perform a "ping www.netline.fr" (if the DNS is positioned correctly)
to establish the communication.

#############################################################################
# Some applications that may pose problems and the associated workaround: #
#############################################################################

NB:
> In all the examples below, the data "@IP" represents the
  machine on your LAN towards which the frames of the specified port
  are to be oriented.
> In general, for applications not described here, you need to
  look for operational problems with firewalls
  to obtain the port numbers or
  restrictions to expect.

..............................................................................

(c)RealVideo Player (port modifiable):
	Set in view/preferences/transport
	Use specific UDP port 7070

	Add to trans.conf
	udport @IP/7070

..............................................................................

(c)VDO Live (port modifiable):
Set in view/setup/connection
	Use UDP Port 7001
	and do not check "Automatic selection"

	Add to trans.conf
	udport @IP/7001

   This application is normally automatically managed by the device
   (option "vdo" in trans.conf), but since data may change, it is
   preferable to know how to get round the problem...

..............................................................................

   Please let us know if you find any errors in this description,
your assistance will be of service to others who require this information.