Continuing my dialogue with myself, ... > The problem seems to be that redirection with rdr does not > work in true transparent bridge mode, when the target of the > rdr is on the localhost interface of the bridge. Although > reading all the docs (I've got through a pile of printouts > about an inch thick) generally gives the impression that > this ought to work, no-where does it ever say so explicitly. > > All the examples I have found anywhere of redirection have > either been for machines configured with IP addresses on > the interfaces and running single-IP NAT, or they have been > redirecting to IP addresses on the internal interface network.
I found this in the transparent squid doc on benzedrine: "Troubleshooting Make sure processes running on the firewall can connect to local clients and external servers. Try ping and telnet to internal and external hosts. Note that when running a bridge(4), the internal and external interface both need an IP address, otherwise the firewall's userland (where squid is running) is isolated from both networks. You can block unwanted connections to the firewall itself using pf." I think I may be getting to the bottom of a misunderstanding. I was under the impression that a transparent bridge *could not* have IP addresses on its bridge interfaces. This seems to be saying that it is allowed, and indeed necessary if any traffic internal to the machine is ever going to be routed to anything on either side of the bridge interfaces. (This would explain why pf.conf files that apparently work elsewhere didn't work for me - the binding of the IP address isn't visible in the pf.conf file ...) If this is the case it might explain why I have not been able to redirect traffic to 127.0.0.1 on the bridge machine itself (the traffic going out $int_if but addressed to 127.0.0.1, which is clearly wrong) So... what are the consequences of putting IP addresses on the bridge interfaces? Are there any unexpected surprised waiting for me? G
