On Wed, Sep 04, 2002 at 12:03:03AM -0800, [EMAIL PROTECTED] wrote:
> One question about the above point. Is it possible to setup the
> configuration in a way that redirection WILL work from local machines
> (within the private LAN)?
The preferred solution is to use 'split-dns', where the name server
replies with the internal web server's address for local queries, and
with the firewall's for external ones. How to set that up depends on
your name server, BIND9 has 'views' to do that, with BIND4 you have to
set up a second name server where local queries go. google has more.
If you really want the local http connections to go through the firewall
(which might be superflous and will increase latency and bandwidth
usage), you can use a TCP proxy/bouncer on the firewall. Check the ports
tree.
While pf could theoretically honor such 'reflecting' redirections, they
wouldn't work:
1) local browser 10.1.1.1 wants to connect to www.domain.com
2) name server replies with external address 123.123.123.123
3) browser sends TCP SYN to 123.123.123.123
4) destination is not on local network, so the packet goes
to the default gateway, which is the pf box
5) pf redirects the packet to the internal web server 10.2.2.2,
6) the web server gets a SYN from 10.1.1.1 to 10.2.2.2 and
replies with a SYN+ACK to 10.2.2.2
7) this destination _is_ on the local network, so the packet
is sent directly to the browser, not through the pf box
8) the browser gets a SYN+ACK with source address 10.2.2.2,
but it expects a reply from 123.123.123.123, so the SYN+ACK
gets dropped and the TCP handshake never completes.
pf could theoretically replace the source addresses of packets
redirected to the web server as well (with 123.123.123.123),
so it will get the replies, but the current design doesn't
allow more than one address translation in a single state entry.
Daniel
