Question about 1.3.2 and NAT.

    I'd like to use it to support a number of small offices as a backup
for their current circuits, which unfortunately fail far too often.  In
most of these locations, we already have Linux servers, and have used 
the ip_masqing capability to support them whenever exteneded outages have
occurred.

    However, our NOS is Banyan Vines, which normally relies on its own
protocol as the transport, and which ip_masqing does not support.  The
question is, Vines clients can be setup to use IP instead of Vines IP.
That however, uses UDP port 573 for communication to the server's.  In
light of that, what is it that I need to do to make NAT properly handle
those packets, or will it?

   I've tried what I believe to be the proper rules with ipfwadm using the
ip_masquerading feature of Linux (I think its proper to call it a subset 
of
NAT), and what happens is this: the packets from any client go thru the 
masq
firewall, but when the server responds, that packet never gets back thru 
the
ip_masq box to the local network.  So, the client cannot find its server.

    Will NAT do this, or what does it take if it can?  I'm lost, and have 
burned enough time with no progress, but I'd like to know the answers if 
anyone might be able to fillin what I'm missing here.  Does NAT only 
handle
well-known ports using UDP, or is it possible to configure it so that it
would properly forward and de-masq (or de-NAT) the UDP's?

    I have not actually tried this with NetBSD/mac68k, and thats because
when I bring up a ppp link, some process consumes the link, and I don't
have tcpdump to try to figure out what it is.  This also happened with 1.2
kernels, and it stopped me from using it.  The link does work in this case
but the response is horrid, because of all the traffic from whatever it is
that burns up the link bandwidth.  No, I'm not running gated or any of the
other options in rc.conf in this case, so I don't think its routing stuff,
but it seems it might be the culprit.  And, no DNS either, so its not 
that.
But I have no clue what it is.  Anyone have a suggestion on this aspect?
I plan to look closer at it when I get a chance, to see if I can identify
what is going on with this, but I can't try NAT until I solve this one.

    And, nothing of the sort occurs when using either MacOS, Win95, Linux
or NT when calling the same service.  When using Linux and ip_masq, it 
does work properly except for handling these non-well known port UDP's
such as Vines uses when setup for IP.  Can this be done with NAT or am I 
just out of luck with this?

thanks
Paul
ar..