> .. a few questions ...
> 1. Can I use the build-in firmware upgrade?
Yes, provided you are already running 1.2b7. Otherwise please read first
> 2. Where does the proxy do caching? Where? in RAM ? (would love it !!!!)
TransProxy's tproxyd is _not_ a (file-) caching proxy, but transparently
redirects client requests to a host:port which runs a caching proxy
(such as Squid). Thus it does not cache any content, but just redirect
HTTP traffic from HTTP default port 80 coming into m0n0wall, to some
configurable IP address and port number.
One application scenario for tproxyd is for example where there is a
m0n0wall between your LAN and your ISP. Further, your ISP is offering a
file caching HTTP proxy service (typically at port 3128 or 8080/tcp).
However, the Web browsers on your LAN are not aware of such a HTTP
proxy, and you do not want to go around each client on your LAN and
change their setup to force them to use the ISP's proxy. m0n0wall as
default gateway will thus get all HTTP connections at port 80/tcp.
tproxy then redirects these connections to your ISP's HTTP caching
server at the address:port you confiured, after rewriting the HTTP
payload as required.
If you do not specify neither the -p nor the -t options in tproxyd (in
m0n0wall's UI I called this mode "RedirectFailoverTransparent"), then
tproxyd will first try to redirect to the ISP's HTTP proxy after
rewriting the frames, and failback to go direct if the ISP's HTTP should
fail to respond (in this case rewriting of the frames occurs, thus
Selecting mode "RedirectOnly" sets the -p switch, which does
redirect/rewrite only, never failing back to transparent mode.
Selecting mode "TransparentOnly" simply passes on the frames without
rewriting them. This mode is actually a HTTP application layer proxy
that simply lacks file caching, but still isolates clients on the LAN
from the Internet, which reduces their exposure and therefore improves
From what I gather about the author of TransProxy is that he is/was
with an ISP and wrote tproxyd being "on the other side of the fence"
where he wanted to get / force his connecting customers to use his
caching HTTP proxy, even if they did not care or did not understand
about the use of such as caching proxy. Like this he was able to
intercept their HTTP frames and redirect them to his caching proxy,
without the customers beeing aware of it (e.g. they do not need to set
any proxy entries).
As briefly described described earlier in this thread, my application of
tproxyd is yet slightly different from the above two scenarios. Combined
with the Captive Portal of m0n0wall, I use it to facilitate the
migrations of douzens of clients from an old transparent firewall to a
new firewall that is not transparent but requires clients to configure
proxy settings. During a transition phase, the Captive Portal intercepts
clients requests, informs them about the required change, and then
tproxyd lets them proceed by rewriting their frames & redirecting them
via the caching HTTP proxy of the new firewall. Policy routing is used
in the LAN to direct all HTTP port 80/tcp traffic from clients to
m0n0wall, which is just kind of "broker" between clients and the new
firewall (and the old firewall if the fail back to transparent is also
enabled in tproxy). This enables us to dismantle the old firewall
actually before all clients have configured the required proxy
configuration. As a service from the friendly ICT department, the policy
route to m0n0wall and its Captive Portal could stay in place even beyond
this migration and inform any misconfigured clients how to properly
setup their HTTP client's proxy settings :-)
Do these three scenarios provide some clarification about tproxyd's
capabilities it adds to m0n0wall in terms of functionality and security?
I hope that you still love it, even though if it's not file caching as
m0n0wall is supposed to run on embedded plattforms that have little RAM
and no harddisk, such as WRAP.