[Firehol-support] appropriate way to do transparent proxy to a node on the LAN

[Spike]

Phil,

thank you for your message, very much appreciate the help. I had completely
forgotten about the issue of client ip, I definitely need that to apply
some rules based on the client so it seems I'll have to go the routing way,
which I actually don't mind and in a sense prefer to NAT'ing. With that in
mind tho, and this may be OT and more fo a networking question, how is the
routing scenario solve the return path issue? once the filtering box
receives the request, won't the source ip still be the one of the client?
(which is the whole point). And that being the case, won't the filter then
try to route it back to the client which is one the same LAN? it seems for
the above to work the content filter and the lan would have to be on their
own network separate from the client.

thanks,

Spike

On Sat, Jul 22, 2017 at 12:17 AM Phil Whineray <phil at firehol.org> wrote:

> Hi Spike
>
> On Sat, Jul 22, 2017 at 12:24:14AM +0000, Spike wrote:
> > I current have transparent proxy set up on the gateway on which firehol
> is
> > also running and a simple "transparent_proxy4..." nicely did the job.
> >
> > However I now need to move the proxy functionalities to another box and
> it
> > seems the only way out is to NAT since REDIRECT is to localhost (I guess
> > under the hood that's also NAT).
>
> It was a while since I had to set this sort of thing up. Hopefully I
> won't present too much misinformation below.
>
> > Should this do it?
> >
> > nat4 to-destination $content_filter_lan:8080 proto tcp dport 80
>
> I think you might run into this [1] problem with up to date versions
> of squid.
>
> The squid wiki still has this though [2] which is is the same ballpark
> It mentions a vulnerability in vague terms...
>
> > any gotchas I should be aware of? will this also alter the source ip?
> > otherwise requests will be sent back to the original box and fail afaik.
>
> DNAT (to-destination in firehol) does not alter the source address,
> you need to do so explicilty with an snat rule (preferred if you have
> a static ip) or masquerade. The MASQUERADE rule in the wiki example is
> to take care of this.
>
> Note that this means your squid sees only traffic from the firewall,
> so if you wanted to examine the logs or have rules per-client, you
> are out of luck.
>
> To resole that you would use intercept with policy based routing but
> that is considerably more effort to set up:
>
> * on firewall, mark the HTTP traffic in firehol
> * on firewall, use `ip` to set up a routing table with squid proxy as
> gateway
> * on firewall, use `ip` to set rule sending marked traffic to that table
> * on squid proxy, create a REDIRECT rule similar to your existing one
>
> This stackexchange post [2] looks about right, albeit with plain
> iptables commands.
>
> Hope that helps
> Phil
>
> [1]: https://squidproxy.wordpress.com/category/interception/
> [2]: http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat
> [3]:
> https://unix.stackexchange.com/questions/138013/routing-internet-on-nat-server-thru-squid-proxy
>