[Summary of responses below, with my replies.  Thanks, everyone.
Hopefully I'll have some more useful debugging info next time - or else
it will be working  :-) ]


||||||||========-------->>>>>>>>
On Mon, 9 Aug 1999, Dave Huang wrote:

> Do the other machines on the 192.168.1 network have 192.168.1.1 as their
> default gateway?

Yes, they do.  The machine I use for testing is a PowerMac running OT,
version 1.3 I think.  The nameserver and search domains are set to the
ones that the Quadra is using - but of course I can't reach them from any
machine in the 192.168.1 group.  I don't have access to it from here, but
I'm sure that the NAT clients are setup as they should be.


||||||||========-------->>>>>>>>
On Mon, 9 Aug 1999, Bill Studenmund wrote:

> That sounds wrong. Were you abole to get the machines talking to the ae0
> at all with that setup?  

Yes, I was.  Of course, I needed a crossover cable between the ae0 and the
uplink port of the hub, but it wasn't any worse. 

> Usually the "uplink" port is intended to connect to another hub. Even if
> it's acting as a router, the ae0 interface should be connected to a 
> normal hub port.

Really?  Even if all traffic leaving my network has to pass through one
particular port?  I figure that that would define 'uplink'.  In any case,
it doesn't work any better now that it's on a 'normal' port.

> I know you mentioned some appletalk services on ae0 - did they work with   
> ae0 on the uplink port?

Yes, they did.


||||||||========-------->>>>>>>>
On Mon, 9 Aug 1999, Nathan Raymond wrote:

> Right.  What the uplink port does is swap the send and recieve lines
> in the cable.  There is no difference between using a crossover cable
> on a regular port and an regular cable on an uplink port.  And, if
> you use a crossover cable on an uplink port, you make it behave like
> a regular port (you've swapped them twice, which is the same as not
> swapping them at all).  Sorry if this sounds confusing, this is the
> best way I can think of explaining without resorting to ASCII art.

Understood.  But it made sense to put it there, since I was going to need
all the other ports anyway, and that port would in essence be my 'uplink'.
It makes it easier too when scanning the activity/status lights on the
hub.  Anyway, there was no real reason to have the crossover cable sit
around gathering dust.

> Unless you have other hubs or switches you are cascading to/from,
> don't use that uplink port.  And remember a hub is just a multiport
> repeater (i.e. a packet coming in from one port is simply echoed to
> every other port, no processing or intelligence about it at all).

Well, it sounds like I've no reason *not* to use the uplink port.  Like I
said above, it's not set up that way (uplink out -> ae0) now, and it still
doesn't work.  I know the cheap hub is a dumb device, but I think that the
hub manual (if you can call it that) said something about basic jabber
filtering or something, in some way differentiating the uplink port from
the others.  I'll have to look at it again.


||||||||========-------->>>>>>>>
On Mon, 9 Aug 1999, Keith Fischer wrote:

> Are you using IP addresses or names for telnet testing.  If you use 
> names then make sure that you /etc/resolv.conf file lists your
> nameservers.

IP addresses from my NAT client(s), but names from my Quadra.  And my
/etc/resolv.conf is set up.

> Also, I assume you have a static IP address from the ADSL folks,
> otherwise the ipnat.conf file needs to contain 0.0.0.0/32 internet
> address.

Yes, it's a static IP address.

> My configuration "sorta" works (really frustrating, 'cuz the ip-nat
> how-to sucks for info).  I've got the router pluggeg into the uplink
> port of the hub and my ae0 and sn0 cards plugged into normal ports on
> the hub.  Everything else is the same as you mention.  What happens on
> mine is that packets inbound from the internet to the LAN's fake IP's
> get lost somewhere.  Not all of the packets, just some, so big WWW pages
> with images wont load completely but simple text pages will.  I just
> started reading the mapping rules pages so hopefully i can figure it out
> within a few days... 

Hmmm.  I'll be on the lookout for that - if I ever get that far.

> do a tcpdump on sn0 to see what is going by when you request an nslookup
> or something from a 198.....  machine. 

Good idea.  I'll try that when I get back home.


||||||||========-------->>>>>>>>
On Mon, 9 Aug 1999, Chris Brown wrote:

> The second map line might be confusing things. You only need one.

Well, I'd added that second line because it wasn't working.  It doesn't
work any better now, but I'll comment it out and make my attempts with the
simpler configuration.

> As to cabling: the outbound interface should be hooked directly to the
> adsl modem/cable modem (using a crossover cable if necessary -- most are
> built so that it's not necessary, however).  The inbound interface
> should be hooked directly to a normal port on the hub (not the uplink
> port, that's only for connecting to another hub).  All machines on the
> internal net should be set to use (in your case)  192.168.1.1 as the
> default gateway. 

Well, I've addressed the gateway IP and the port issue above.  It seems
that if IPNAT were working, it would work with either of the physical
configurations that I've described.  However, I'll go back and try it in
the ways suggested above, just in case.

> You should be able to ping both a machine on the inside network, and one
> on the outside, from the NetBSD machine. From an inside machine, you
> should be able to do a traceroute to show it going through the NetBSD
> box and out onto the internet. 

With the outbound port on the NetBSD machine hooked directly to the ADSL
box, I could ping both outside and inside machines from the NetBSD
machine, and ping the NetBSD box from outside and inside.  IPNAT still
didn't work.  I'll try the traceroute from one of the MacOS clients.


/*======================================================================
"Don't die wondering..."                http://www.cldc.howard.edu/~cpg
                                              email: cpg@scs.howard.edu
chris out-              Christopher P. Gill
  peace.        C.L.D.C. Senior System Operator (Ret.)
======================================================================*/