This one time, at band camp, Fred Wright said:

> > you can't reach an internal server from the LAN via NAT by way of the
> > WAN IP, but you can reach the m0n0wall webgui from the LAN by way of
> > the WAN IP...??!!
> >
> > does anyone else think this is strange?  i realize that it doesn't go
>
> Not if you understand how IP works. :-)

cheeky!

it's true.  i know just about enough to be dangerous.  i should pick up
that networking essentials book my brother heaved at me years ago, but it
was so DAUNTING then... :)

> NAT behavior is a function of the interface, while addressing the
> m0n0wall itself is not.  Most systems implement the "weak end system"
> model, menaing that the machine can be reached via any of its IP
> addresses, regardless of whether the address matches the interface where
> the packet arrived.

ah.  ok, i get it.

> If you don't like that, add some block rules. :-)

what i don't like is that i can't do the same thing through NAT :)

> > > this is perhaps only a minor annoyance, but when i moved to m0n0wall
> > > i lost this ability.  behind my inexq this was no problem.  can
> > > anyone explain why this is not possible to implement?  is it a
> > > limitation, or by design?
> >
> > If your ISP offers a web proxy feature you can use it to test your
> > nat'ed ports (because you then go out and come back in).
>
> Or if they have shell service with SSH you can tunnel the access through
> the shell server.  Or if they have shell service without SSH, try lynx
> (or even telnet) from the shell server.

my isp doesn't provide a shell account of any kind, but i do have another
external shell account, and i've used both techniques you suggest above
for various reasons, including the need that spawned this whole thread:
the need to verify that my homebrew dyndns solution (see previous post re:
hard work v.s. common sense) was working as expected.  truthfully, each
technique you suggest amounts to a full end-to-end test, which is best of
course.  however, the bounce functionality i've beem a cry-baby about on
the list is a much easier, quicker test, checking rules, redirects, and
nat, if not all hops of a fully external session.

now that i've been alerted to the existence of dyndns.org (yes, i feel
like the last one to know), it's no longer as important for me to get
bounce funtionality, although i'd still like it.  it can provide a better
gauge of connectivity to my services from the outside because it would go
through the NAT and rules machinery.  the DNS overrides i'm using now
amount to a redirect from one internal machine to another, bypassing the
m0n0 for all of the actual traffic after the DNS lookup.

and, no-one has been able to answer the question of why m0n0 does have not
and likely won't get bounce functionality, or how the heck i might go
about adding it myself (is it just a config issue, or are other tools
needed?).  is it a security issue?  or is that i'm the only whiner asking
for it :)

in any case, i thank you and the rest of the list for all of your
attention and patience.  maybe my next post will actually be helpful to
others :)

jj