[squid-users] Re:[squid-users] transparent proxy

From: Jan Humme <humme@dont-contact.us>
Date: Wed, 21 Aug 2002 13:19:24 +0200

On Wednesday 21 August 2002 05:36, PayalR wrote:
> Hello all,
> I will briefly explain my senario. I have a simple setup. Mdk Linux 8.2 on
> a single box. Squid 2.4.STABLE1. I am using the rules given below by a
> squid user. How I test is I run 2 instances of links (diff. users), one
> with proxy settings on and one without.
> My rules are,
> iptables -P INPUT ACCEPT
> iptables -P FORWARD ACCEPT
> iptables -P OUTPUT ACCEPT
>
> iptables -t nat -P PREROUTING ACCEPT
> iptables -t nat -P OUTPUT ACCEPT
> iptables -t nat -P POSTROUTING ACCEPT
>
> iptables -t mangle -P PREROUTING ACCEPT
> iptables -t mangle -P OUTPUT ACCEPT
>
> iptables -F
> iptables -X
> iptables -t nat -F
> iptables -t nat -X
> iptables -t mangle -F
> iptables -t mangle -X
>
> iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
>
> iptables -t nat -N PROXY
> iptables -t nat -A PROXY -j LOG --log-prefix "redirected to proxy"
> iptables -t nat -A PROXY -p tcp --dport 80 -j REDIRECT --to-port 3128
>
> iptables -t nat -A PREROUTING -j LOG --log-prefix "prerouting"
> iptables -t nat -A PREROUTING -p tcp --dport 80 -j PROXY
>
> iptables -t nat -A OUTPUT -j LOG --log-prefix "output"
> iptables -t nat -A OUTPUT -p tcp --dport 80 -j PROXY

The reason why I gave you these rules is so you can see what is going on
inside your machine by checking the log files.

For the record, and in particular for anyone else browsing these archives in
the future, I like to point out that these rules (PROXY, PREROUTING, OUTPUT)
should ultimately look like:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-port 3128

where the last rule is only needed to make it possible to redirect local
browser requests to squid as well, instead of only requests coming from other
machines on a LAN.

> Now in my /var/log/messages I see these kind of of messages,

But what do they mean??? And what is the context?

> Aug 21 09:04:35 localhost kernel: outputIN= OUT=lo SRC=127.0.0.1
> DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=620
> DPT=111 LEN=64

A local rpc request?..... has nothing to do with it.

> Aug 21 09:04:48 localhost kernel: preroutingIN=ppp0 OUT= MAC=
> SRC=64.242.248.7 DST=203.199.158.95 LEN=40 TOS=0x00 PREC=0x00 TTL=55
> ID=47749 DF PROTO=TCP SPT=80 DPT=1068 WINDOW=32696 RES=0x00 ACK FIN URGP=0

A reply from some webserver at 64.242.248.7 to: your browser? to squid?

It all depends on what you were exactly testing at that moment. Try to do one
thing at the time and understand what is going on.

> Aug 21 09:04:58 localhost kernel: outputIN= OUT=lo SRC=127.0.0.1
> DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1025
> DPT=111 LEN=64

Some other local rpc request?..... has nothing to do with it.

> Aug 21 09:04:58 localhost kernel: outputIN= OUT=lo SRC=127.0.0.1
> DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40449 PROTO=TCP SPT=1055
> DPT=3128 WINDOW=32767 RES=0x00 SYN URGP=0

An attempt to establish a connection to port 3128 from some local process,
but what exactly was your test setup at that moment??

Test ONE thing at the time and try to understand what is going on. My
recommendation is still to get squid running as a normal proxy first, so you
can browse the web with a browser configured to use the proxy. Once that is
100% working, you can try and get the iptables stuff to work.

> Now I am unable to broswe from either with or without cache. What is wrong?

Great! You probably can no longer browse without cache because all your
www-packets (DPT=80) are finally being routed to the squid-port now
(DPT=3128), which is what you wanted. Unfortunately, from there something
goes wrong. I think that it is time to check the squid log files for any
activity (back to the subject of this mailing list!).

For the record, the reason that it didn't work before is that you are running
squid and your browser at the same machine; the netfilter/iptables package
will then route the browser packets to the OUTPUT-queue, so they never end up
in the PREROUTING-queue, which is where you put your REDIRECT-instruction.
This is why now you have a rule in your OUTPUT-queue as well.

For a better understanding please DO check:
http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES

I want to remind you that we are there to HELP YOU to fix your problem; NOT
to fix your problem FOR YOU. What it means is that you must investigate
things step-by-step, and (most important) make a real effort to understand
the bounty of information that comes to you via the log files etc etc; not
just type in some stuff and then come back 5 minutes later and say "system
not working: help!".

JH.
Received on Wed Aug 21 2002 - 05:19:26 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:09:46 MST