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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux