Re: [squid-users] Help! one more time on on Squid3.HEAD(20110307), TPROXY4 and Iptables 1.4.9 + ebtables

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 16 Mar 2011 12:39:25 +1300

 On Tue, 15 Mar 2011 07:41:28 -0700, Jim Binder wrote:
> If I try and add the route, both fail with file exists err
>
> [root_at_fw01 ~]# ip route add local 0.0.0.0/0 dev eth0 table 100
> RTNETLINK answers: File exists
> [root_at_fw01 ~]# ip route add local 0.0.0.0/0 dev eth2 table 100
> RTNETLINK answers: File exists
>

 Okay, I think that is a good sign. It matches what I see anyway.

 Re-checking the tproxy page I'm reminded about SELinux.

 http://wiki.squid-cache.org/Features/Tproxy4#SELINUX_Policy_tuning
 http://wiki.squid-cache.org/Features/Tproxy4#selinux_policy_denials

 If it is not that, you have the (dis)pleasure of hitting something new.

 I find it really weird that Squid is not even getting to the accept()
 stage after iptables has logged them as approved. IME tracking the
 packets have been rejected by the FW software either arriving or leaving
 Squid . Not just disappearing right at the end of the TCP stack like
 that.

 Amos

>
> On Mar 15, 2011, at 3:02 AM, Amos Jeffries wrote:
>
>> On 15/03/11 20:22, Jim Binder wrote:
>>> Trying this one more time to see if anyone might know what's wrong
>>> in getting my transparent bridging with squid to work.
>>> Config... pings work thought the box (the bridge is working
>>> however; the 3129 socket never pops with an HTTP request)
>>>
>>> Admin on Eth1, Internet on eth0 and Inside (client) interface on
>>> eth2. Br0 used as the bridge.
>>>
>>> Running Fedora core 14 (but went back as fare as 12 and couldn't
>>> get it to work)
>>>
>>> Squid Cache: Version 3.HEAD-20110307
>>> configure options: '--enable-ecap' '--enable-icap-client'
>>> '--enable-linux-netfilter' --enable-ltdl-convenience
>>>
>>> iptables-1.4.9-1.fc14.i686
>>> kernel-2.6.35.11-83.fc14.i686
>>> ebtables-2.0.9-5.fc13.i686
>>>
>>> Went as far to turn on dynamic debug logging and I don't see what's
>>> wrong but the connect never seems to get made to the 3129 socket.
>>>
>>> [ 214.914113] TRACE: mangle:PREROUTING:rule:2 IN=eth2 OUT=
>>> MAC=00:40:f4:cd:01:70:00:50:56:36:df:78:08:00 SRC=192.168.1.91
>>> DST=192.168.1.88 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3380 DF
>>> PROTO=TCP SPT=48255 DPT=80 SEQ=1363486620 ACK=0 WINDOW=5840 RES=0x00
>>> SYN URGP=0 OPT (020405B40402080A02522AA80000000001030306)
>>> [ 214.914155] xt_TPROXY: redirecting: proto 6 c0a80158:80 ->
>>> 00000000:3129, mark: 1
>>> [ 217.920783] TRACE: raw:PREROUTING:policy:3 IN=eth2 OUT=
>>> MAC=00:40:f4:cd:01:70:00:50:56:36:df:78:08:00 SRC=192.168.1.91
>>> DST=192.168.1.88 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3381 DF
>>> PROTO=TCP SPT=48255 DPT=80 SEQ=1363486620 ACK=0 WINDOW=5840 RES=0x00
>>> SYN URGP=0 OPT (020405B40402080A025236680000000001030306)
>>> [ 217.920846] TRACE: mangle:PREROUTING:rule:2 IN=eth2 OUT=
>>> MAC=00:40:f4:cd:01:70:00:50:56:36:df:78:08:00 SRC=192.168.1.91
>>> DST=192.168.1.88 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3381 DF
>>> PROTO=TCP SPT=48255 DPT=80 SEQ=1363486620 ACK=0 WINDOW=5840 RES=0x00
>>> SYN URGP=0 OPT (020405B40402080A025236680000000001030306)
>>> [ 217.920891] xt_TPROXY: redirecting: proto 6 c0a80158:80 ->
>>> 00000000:3129, mark: 1
>> <snip>
>>> [root_at_fw01 ~]#
>>> [root_at_fw01 ~]# ip route list table all
>>> local default dev lo table 100 scope host
>>
>> Tried with "table 100" created on eth0 and eth2 ?
>>
>> That seems to be needed recently.
>>
>> Everything else looks okay to me. Down to the packets hitting the
>> TPROXY and DIVERT rules.
>>
>> Amos
>> --
>> Please be using
>> Current Stable Squid 2.7.STABLE9 or 3.1.11
>> Beta testers wanted for 3.2.0.5
Received on Tue Mar 15 2011 - 23:39:30 MDT

This archive was generated by hypermail 2.2.0 : Wed Mar 16 2011 - 12:00:03 MDT