Re: Problems with Transparent Proxy using IPTables, Squid and 2.6 kernel

[Arthur Meyer <arthur.meyer@tbz.ch>]

Have you compiled netfilter with the option --with linux netfilter and set the 
transparent proxy instructions in squid?
Arthur


On Monday 12 January 2004 23:45, Peter Schobel wrote:
> yes all policies are set to ACCEPT and I assume that squid is working
> fine since it works well by using the proxyhost on port 80 and 3128 or
> by manually configuring the proxy in the browser
>
> On Monday, January 12, 2004, at 04:31  PM, John A. Sullivan III wrote:
> > Hmmm . . . your rules do indeed look wide open.  Have you double
> > checked
> > silly things like making sure all the policies are ACCEPT and squid can
> > resolve names using DNS? Is there any chance that squid does not like
> > 2.6?
> >
> > On Mon, 2004-01-12 at 15:57, Peter Schobel wrote:
> >> If i access the proxyhost directly on port 80 i can see the request to
> >> the local host on 3128 and then i see a request from the local host to
> >> the remote proxy site and everything works fine - the squid log shows
> >> the access.  I'm not really sure what to do at this point i've been
> >> trying any rule i can think of and i have a bunch of logging rules in
> >> now to try to figure out what's going wrong but i'm not getting any
> >> more information than what you see below.
> >>
> >> If i can't get this working by the end of the night, i'll probably
> >> have
> >> no choice but to format reinstall and try to get back to a working
> >> configuration which i really don't want to do because i have a lot of
> >> software installed and configured on that machine that i will have to
> >> rebuild.
> >>
> >> Peter Schobel
> >> ~
> >>
> >> On Monday, January 12, 2004, at 03:04  PM, Peter Schobel wrote:
> >>> it appears to me as if it's redirecting to port 3128 but its not
> >>> getting a reply from squid - the squid access log does not show the
> >>> access at all as if it never received the packet
> >>>
> >>>
> >>> Jan 12 14:52:21 proxyhost IN=eth0 OUT=
> >>> MAC=00:04:75:fb:a6:e1:00:d0:52:04:43:5a:08:00 SRC=64.187.35.163
> >>> DST=216.239.37.104 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=47715 DF
> >>> PROTO=TCP SPT=53036 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
> >>> Jan 12 14:52:21 proxyhost IN=eth0 OUT=
> >>> MAC=00:04:75:fb:a6:e1:00:d0:52:04:43:5a:08:00 SRC=64.187.35.163
> >>> DST=10.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=47715 DF PROTO=TCP
> >>> SPT=53036 DPT=3128 WINDOW=8192 RES=0x00 SYN URGP=0
> >>> Jan 12 14:52:24 proxyhost IN=eth0 OUT=
> >>> MAC=00:04:75:fb:a6:e1:00:d0:52:04:43:5a:08:00 SRC=64.187.35.163 DST=
> >>> 10.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=47717 DF PROTO=TCP
> >>> SPT=53036 DPT=3128 WINDOW=8192 RES=0x00 SYN URGP=0
> >>> Jan 12 14:52:27 proxyhost IN=eth0 OUT=
> >>> MAC=00:04:75:fb:a6:e1:00:d0:52:04:43:5a:08:00 SRC=64.187.35.163 DST=
> >>> 10.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=47719 DF PROTO=TCP
> >>> SPT=53036 DPT=3128 WINDOW=8192 RES=0x00 SYN URGP=0
> >>> Jan 12 14:52:30 proxyhost IN=eth0 OUT=
> >>> MAC=00:04:75:fb:a6:e1:00:d0:52:04:43:5a:08:00 SRC=64.187.35.163 DST=
> >>> 10.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=47721 DF PROTO=TCP
> >>> SPT=53036 DPT=3128 WINDOW=8192 RES=0x00 SYN URGP=0
> >>> Jan 12 14:52:33 proxyhost IN=eth0 OUT=
> >>> MAC=00:04:75:fb:a6:e1:00:d0:52:04:43:5a:08:00 SRC=64.187.35.163 DST=
> >>> 10.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=47724 DF PROTO=TCP
> >>> SPT=53036 DPT=3128 WINDOW=8192 RES=0x00 SYN URGP=0
> >>> Jan 12 14:52:36 proxyhost IN=eth0 OUT=
> >>> MAC=00:04:75:fb:a6:e1:00:d0:52:04:43:5a:08:00 SRC=64.187.35.163 DST=
> >>> 10.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=47726 DF PROTO=TCP
> >>> SPT=53036 DPT=3128 WINDOW=8192 RES=0x00 SYN URGP=0
> >>> Jan 12 14:52:42 proxyhost IN=eth0 OUT=
> >>> MAC=00:04:75:fb:a6:e1:00:d0:52:04:43:5a:08:00 SRC=64.187.35.163 DST=
> >>> 10.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=47739 DF PROTO=TCP
> >>> SPT=53036 DPT=3128 WINDOW=8192 RES=0x00 SYN URGP=0
> >>> Jan 12 14:52:54 proxyhost IN=eth0 OUT=
> >>> MAC=00:04:75:fb:a6:e1:00:d0:52:04:43:5a:08:00 SRC=64.187.35.163 DST=
> >>> 10.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=47743 DF PROTO=TCP
> >>> SPT=53036 DPT=3128 WINDOW=8192 RES=0x00 SYN URGP=0
> >>>
> >>> On Saturday, January 10, 2004, at 12:26  AM, Alistair Tonner wrote:
> >>>> 	Have you tried LOGging the INPUT chain for both 80 and 3128?
> >>>> 	Or, perhaps more thorough, put a LOG rule in PREROUTING
> >>>> 	before the REDIRECT/DNAT rule to log what you will change,
> >>>> 	and since your destination is local, a LOG rule at the top of INPUT
> >>>> 	to catch *everything* for the interim? -- then see at what point
> >>>> 	the packets are actually disappearing.
> >>
> >> *****************************
> >> Peter Schobel
> >> Network Administrator
> >> Porchlight.ca
> >> Unlimited Internet
> >> *****************************
> >> In a world without walls or fences
> >> We will have no need for gates or windows
> >> *****************************
> >
> > --
> > John A. Sullivan III
> > Chief Technology Officer
> > Nexus Management
> > +1 207-985-7880
> > john.sullivan@nexusmgmt.com
>
> *****************************
> Peter Schobel
> Network Administrator
> Porchlight.ca
> Unlimited Internet
> *****************************
> In a world without walls or fences
> We will have no need for gates or windows
> *****************************