On Thu, 19 Jun 2003, Ryan Grove wrote:
> On Thu, 19 Jun 2003, Fred Wright wrote:
> 
> > The latter.  It's not possible with NAT.  The problem is that it's not
> > really LAN->WAN->LAN at all, it's just LAN->router.  Traffic destined
> > for the router doesn't get routed through the WAN interface in some
> > sort of driver-level loopback just because you specify the WAN IP.
> > Since it doesn't go through the WAN interface, it doesn't go through
> > NAT processing, and gets delivered to the router itself.  And since
> > the router's webserver is bound specifically to the LAN IP, there's no
> > port 80 listener for the WAN IP.
> 
> Ouch. Oh well. I guess my Linksys must have handled it differently
> somehow. Is it naive of me to think that it would be a fairly
> straightforward matter to add code to the firewall that catches outbound
> traffic destined for the WAN IP and reroutes it appropriately? Or would
> this be the job of the TCP forwarder, which you mentioned in your next
> paragraph?

Well, it never *is* "outbound" traffic (see above), and adding NAT-related
processing to LAN interfaces would increase overhead.

The "TCP forwarding" approach could potentially be used *instead of* NAT
redirection, but in the interests of efficiency it's better to have
both.  NAT just needs to rewrite a few header fields in the packets, and
runs entirely within the kernel, while TCP forwarding involves converting
the data from packets to a stream and back to packets, with a userland
program in the middle.  So letting NAT redirection handle the majority of
cases where it does work, and just using TCP forwarding for the stuff that
"falls through the cracks", is faster.

A couple of possible candidates for the forwarder are:

	http://www.kyne.com.au/~mark/software/ncat.php
	http://www.zoran.net/wm_resources/netcat_hobbit.asp

Both of these seem to be overkill for the simple case, but perhaps usable.
If the stuff about netcat causing "massive collisions" is really tru, it
must be due to a weird bug, since (at least in the TCP case), the
application doesn't have much direct control over packet
transmission.  And if it was under Linux, that might just be a
Linuxism. :-)

On Thu, 19 Jun 2003, Christiaens Joachim wrote:
> 
> A workaround can consist in adding a local DNS entry in the m0n0wall's DNS
> server that points to your INTERNAL ip.
> 
> Go to 'Services' and open 'DNS Forwarder'
> click on the + sign to add an 'exception'
> host: wonko
> domain: com
> ip: your web server's internal IP
> description: xxxxxx

I don't think it's a very good idea to have different servers returning
different mappings for the same address - lots of possibilities for
inconsistencies and general flakiness.  The intended purpose of
"exceptions" is to provide mappings that simply can't exist on the outside
servers.

> Mind you that windows clients mess around with the priority of DNS servers
> (based on performance/response-time), so if the ISP's DNS gets on top,
> wonko.com won't work anymore. I guess this will be no problem since the
> m0n0wall is on your lan.

If the client is really able to see both direct and forwarded DNS IPs,
then I expect that *would* be a problem, since the forwarder can't
possibly be faster than the server it's forwarding to. :-) Yes, it might
be if it happens to hit the cache, but you can't count on that, and
frankly I think it's better *not* to do any cacheing in the forwarder.

The reason for the latter is that resolvers normally have cacehing anyway,
so the only benefit from cacheing in the forwarder occurs when different
clients are accessing the same sites (and even then only a small benefit).  
Meanwhile cacheing adds more opportunities for inconsistencies leading to
nonrepeatable bugs.  So anything short of a full-blown named should just
stick to answering local requests and forwarding the rest.

The way to handle multiple servers is to set up at least as many LAN IPs
on the router as there are outside DNS servers, and then map one LAN IP to
each DNS server in the forwarding setup, passing the multiple LAN IPs to
clients as DNS IPs via DHCP as required.  Then, all the existing logic in
the resolvers to try different servers continues to work through the
forwarder, without the need for any long-term statefulness in the
forwarder.

					Fred Wright