Re: Privoxy on router firmwares poses a huge security risk

On Sun, 5 Jan 2020 15:55:24 -0500
Lee <[email protected]> wrote:

> >>   -- allow traffic from privoxy back 'inside'
> 
> uhmm.. on second thought, it's already going to go 'inside' so there's
> no need to add a rule to allow what's going to happen anyway

I don't think so. The VPN (is it OpenVPN or kernel IPSEC?) normally has
an outgoing interface:

                  +---> eth0 internet
internal --> eth1 +
                  +---> tun0 internet through vpn

These eth0 and tun0 behave as if it were two different gateways. It is
different in case op IPSEC which does not provide an interface for
various reasons.

> > Wouldn't it be simpler to bind privoxy to its own ip address, e.g.
> > 192.168.1.2, and use pbr?
> >
> > ip rule add from 192.168.1.2 lookup 10
> >
> > ip route add 192.168.2.0/24 dev eth1 table 10 # internal network
> > ip route add 192.168.1.0/24 dev eth0 table 10 # external network
> > ip route add default via 192.168.1.254 dev eth0
> 
> I think "simpler" would be adding just one more iptable rule :)
> 
> Everything seems to be working for the OP except that privoxy ->
> internet traffic _doesn't_ go out via the vpn.

Use pbr to force it

[iptables]
 
> OTOH, if redirecting traffic from privoxy to the vpn doesn't work then
> maybe the next best solution would be to put privoxy on a separate ip
> address and configure a routing table just for privoxy.

That was my second proposal ;-)

There are many ways to make that router do what you want. If you bind
privoxy to a separate address then you can easily use pbr. Do not
forget to tell the new table that the internal network is behind eth1,
otherwise it will never work.

R.

-- 
richard lucassen
http://contact.xaq.nl/