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. :-)
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