[Firehol-support] transparent proxy with UNROUTABLE_IPS

[Costa Tsaousis]

Hi,

Which kernel version are you using?
It seems there is an error on how your kernel interprets the traffic: 
DST=127.0.0.1 cannot go out via OUT=world.

Anyway, you can allow this to happen if you define an interface that 
matches this traffic.

Costa


Max Kutny wrote:

> Gents,
>
> one of interfaces of my computer looks into the outside world. I 
> protect it with
> 'src not "${UNROUTEABLE_IPS}"' clause.
>
> Transparent proxy configured with "transparent_squid 3128 proxy" helper.
>
> When I "telnet sf.net <http://sf.net> 80" from the firewall I've got 
> the following in firewall's syslog:
> Jan 14 12:15:42 blues kernel: 'OUT-unknown:'IN= OUT=world 
> SRC=85.202.141.172 <http://85.202.141.172> DST=127.0.0.1 
> <http://127.0.0.1> LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=17371 DF 
> PROTO=TCP SPT=52401 DPT=3128 WINDOW=5840 RES=0x00 SYN URGP=0
>
> Why does it happen?
>
> When locally generated packet originates to sf.net <http://sf.net> it 
> gets redirected by the following
> rule in NAT table (produced by transparent proxy helper):
> 0 0 REDIRECT tcp  --  any any anywhere anywhere redir ports 3128
>
> Redirection means that destination is simply changed to 127.0.0.1 
> <http://127.0.0.1> so the
> packet gets the following attributes: OUT=world SRC='world address' 
> DST=127.0.0.1 <http://127.0.0.1> .
>
> After NAT table processing packet is ruled to the OUTGOING chain.
>
> OUTGOING chain has a jump to user-defined chain for world interface.
> And world interface chain itself has "0 0 RETURN all -- any any 
> anywhere 96.0.0.0/3 <http://96.0.0.0/3>"
> rule (remember unroutable ips protection?).
>
> Thus, every packet outgoing to world interface with DST=127.0.0.1 
> <http://127.0.0.1> gets returned
> to the OUTPUT chain and gets dropped at the end of it.
>
> If I remove unrouteable ips protection everything gets processed fine.
>
> How could I use transparent proxy with unrouteable ips protection on?
>
> It would help if REDIRECT changed interface to 'lo' as well as DST 
> address.
> Unfortunately this is not the case here.
>
> -- Max
>