Re: [squid-users] Tproxy4+squid: ebtables wiki

To throw in my 2 cents. I have tried to using both ubuntu server 9.04
and 9.10 neither of them I could get to work. I experienced the same
problem. So to make sure it wasn't me making a mistake somewhere I tried
the same config and setup on Fedora and that worked fine. So being lazy
I just went with that. I am very interested in getting TPROXY to work
with ubuntu server as I prefer it as my server OS.

Roth, Joe wrote:
> So it sounds like this is a problem with ubuntu 9.10 in general? I am
> running the server version as well, everything looks to be compiled
> properly, dmesg shows TPROXY starting, squid shoq IP spoofing to be
> starting as well.
>
> -----Original Message-----
> From: Irvan Adrian K [mailto:irvan_at_grahamedia.net.id]
> Sent: Monday, November 09, 2009 8:46 AM
> To: Amos Jeffries
> Cc: squid-users_at_squid-cache.org
> Subject: Re: [squid-users] Tproxy4+squid: ebtables wiki
>
> Dear Mr Amos, thanks for your respond, very helpfull..
>
> Amos Jeffries wrote:
>
>> Irvan Adrian K wrote:
>>
>>> So, What the solution for these threads ? because i'm in the same
>>> trouble to make TPROXY4 work in UBUNTU 9.10 Server
>>>
>>>
>> Explicit "Server" release or normal? I have recently found that the
>> kernel for normal Ubuntu is missing some routing features needed on a
>> end box pretending to be a server.
>>
> Server release distribution of UBUNTU 9.10, not desktop one.. as you
> know that UBUNTU have several type of distribution : server, desktop,
> etc.., and as we analyze that UBUNTU Server
> not differ than Debian, and have complete support for TPROXY built in,
> without recompile :
>
> xt_tcpudp 2780 2
> nf_nat 17808 2 iptable_nat,ipt_REDIRECT
> nf_conntrack_ipv4 13352 3 iptable_nat,nf_nat
> xt_MARK 1884 2
> xt_socket 2556 2
> nf_conntrack 67608 4
> iptable_nat,nf_nat,nf_conntrack_ipv4,xt_socket
> xt_TPROXY 1948 2
> nf_defrag_ipv4 1756 3 nf_conntrack_ipv4,xt_socket,xt_TPROXY
> nf_tproxy_core 2428 2 xt_socket,xt_TPROXY,[permanent]
> x_tables 16544 10
> ebt_redirect,ebt_ip,ebtables,xt_tcpudp,iptable_nat,ip_tables,ipt_REDIREC
> T,xt_MARK,xt_socket,xt_TPROXY
>
>
>>> I'm using Kernel 2.6.31, Squid 3.1.0.15, iptables 1.4.5, ebtables
>>> 2.0.9, and until now, following the manual in
>>> http://wiki.squid-cache.org, like this :
>>>
>>> ebtables -t broute -I BROUTING -p ipv4 --ip-proto tcp --ip-dport 80
>>> -j redirect --redirect-target DROP
>>> ebtables -t broute -I BROUTING -p ipv4 --ip-proto tcp --ip-sport 80
>>>
> -j
>
>>> redirect --redirect-target DROP
>>>
>>> cd /proc/sys/net/bridge/
>>> for i in *
>>> do
>>> echo 0 > $i
>>> done
>>> unset i
>>>
>>> echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter
>>> echo 1 > /proc/sys/net/ipv4/ip_forward
>>>
>>> iptables are:
>>> iptables -t mangle -N DIVERT
>>> iptables -t mangle -A DIVERT -j MARK --set-mark 1
>>> iptables -t mangle -A DIVERT -j ACCEPT
>>> iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
>>> iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY
>>> --tproxy-mark 0x1/0x1 --on-port 3129
>>>
>>> squid configuration is default, except
>>> acl allow all
>>>
>>> After following like above, the iptables counter was increasing
>>> redirecting to TPROXY, but there was nothing
>>> in the squid, i can't open anything..
>>>
>>> But if i change the ebtables --redirect-target ACCEPT, the connection
>>>
>
>
>>> running, but the packet just bridged nothing came to Squid, just like
>>>
>
>
>>> nothing on there..
>>>
>> Yes. That is why they are "DROP". In BROUTING it means something like;
>>
>
>
>> DROP off the bridge into the routing code, vs ACCEPT over the bridge.
>>
> Yes, we look that, after adding --redirect-target DROP at ebtables,
> counter at iptables -j TPROXY increase, like this one :
>
> 12830 3896K DIVERT tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 socket
> 1451 69360 TPROXY tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:80 TPROXY redirect 0.0.0.0:3129 mark 0x1/0x1
>
> before DROP at ebtables, there was none packet come to iptables -j
> TPROXY
>
>>> There some one can give the clue, thanks in advance..
>>>
>>> R
>>>
>>>
>> Did you build Squid with libcap2-dev installed on the system?
>>
> UBUNTU prefer libcap-dev rather than libcap2-dev,
>
> apt-get install libcap2-dev
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Note, selecting libcap-dev instead of libcap2-dev
> libcap-dev is already the newest version.
>
>> If you start Squid with the -X option is there anything about spoofing
>>
>
>
>> or transparent mentioned?
>>
>
> 2009/11/09 08:43:17.338| Processing: 'http_port 3128 '
> 2009/11/09 08:43:17.338| http(s)_port: found Listen on Port: 3128
> 2009/11/09 08:43:17.338| http(s)_port: found Listen on wildcard address:
>
> [::]:3128
> 2009/11/09 08:43:17.338| Processing: 'http_port 3129 tproxy'
> 2009/11/09 08:43:17.338| http(s)_port: found Listen on Port: 3129
> 2009/11/09 08:43:17.338| http(s)_port: found Listen on wildcard address:
>
> [::]:3129
> 2009/11/09 08:43:17.338| Starting IP Spoofing on port [::]:3129
> 2009/11/09 08:43:17.338| Disabling Authentication on port [::]:3129 (IP
> spoofing enabled)
> 2009/11/09 08:43:17.338| Detect TPROXY support on port [::]:3129
> 2009/11/09 08:43:17.338| ...Probing for IPv6 TPROXY support.
> 2009/11/09 08:43:17.339| ...Probing for IPv4 TPROXY support.
> 2009/11/09 08:43:17.339| IPv4 TPROXY support detected. Using.
>
>
> Thanks,
>
> Irvan Adrian
>
>> Amos
>>
>>
>>> Kernel 2.6.30.8, Squid 3.1.0.14, iptables 1.4.3.1, ebtables 2.0.9
>>>
>>> Marko Kotar wrote:
>>>
>>> Just curious which kernel version are u using?
>>>
>>>
>>>
>>> --- On Thu, 10/29/09, Dan <d..._at_jisp.net> wrote:
>>>
>>>
>>> From: Dan <d..._at_jisp.net>
>>> Subject: Re: [squid-users] Tproxy4+squid: ebtables wiki
>>> To: "Marko Kotar" <kotarma..._at_yahoo.com>
>>> Cc: squid-users_at_squid-cache.org
>>> Date: Thursday, October 29, 2009, 5:24 PM
>>> Those are the same ebtable and
>>>
>>> iptable rules that I am using except that I use DROP. If it is
>>> working for you then that is great. :) As for why
>>>
>>> it works that way I don't know. When I use ACCEPT the
>>> traffic is bridged through and not redirected to squid.
>>>
>>> Thanks,
>>>
>>> Irvan Adrian
>>>
>>> Marko Kotar wrote:
>>>
>>> Ok
>>> My ebtable rules are(without -i option):
>>> ebtables -t broute -A BROUTING -p ipv4 --ip-proto tcp
>>> --ip-dport 80 -j redirect --redirect-target ACCEPT
>>>
>>> ebtables -t broute -A BROUTING -p ipv4
>>> --ip-proto tcp --ip-sport 80 -j redirect --redirect-target
>>> ACCEPT
>>>
>>> This might be the different:
>>> Bridge is up and it is having an ip address. Ethernet
>>> interfaces are up but not having any ip address asigned.
>>>
>>> ifconfig eth0 up promisc
>>> ...
>>> bridge interface is configured with dhclient:
>>> dhclient3 br0
>>>
>>> This rules are for the routing;
>>> ip rule add fwmark 1 lookup 100
>>> ip route add local 0.0.0.0/0 dev lo table 100
>>> And:
>>> echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter
>>> echo 1 > /proc/sys/net/ipv4/ip_forward
>>>
>>> iptables are:
>>> iptables -t mangle -N DIVERT
>>> iptables -t mangle -A DIVERT -j MARK --set-mark 1
>>> iptables -t mangle -A DIVERT -j ACCEPT
>>> iptables -t mangle -A PREROUTING -p tcp -m socket -j
>>> DIVERT
>>>
>>> iptables -t mangle -A PREROUTING -p tcp --dport 80 -j
>>> TPROXY --tproxy-mark 0x1/0x1 --on-port 3129
>>>
>>> squid configuration is default, except
>>> acl allow all
>>> and port is set to the same address as in iptables,
>>> and having TPROXY set.
>>>
>>> I am using: 2.6.28-16-server x86_64 ubuntu, default or
>>> compiled ebtables v2.0.9-1 (June 2009), compiled iptables
>>> v1.4.5,
>>>
>>> Squid Cache: Version 3.1.0.14
>>> configure options: '--enable-linux-netfilter'
>>> --with-squid=/home/marko/src/squid-3.1.0.14
>>> --enable-ltdl-convenience
>>>
>>> configured ony with additional linux-netfilter flag
>>>
>>> I've used various network configurations:
>>> -virtual computer using VmBox with virtual interface
>>> in the linux bridge on guest pc.
>>>
>>> -computer with two interfaces.
>>> -double bridged vmbox: two virtual machines: first
>>> having 2 virtual interfaces. birdged and having sqiud.
>>> second virtual pc being client with one virtual interface.
>>> one interface of first was bridged on guest computer to
>>> external interface, other two were bridged together.
>>>
>>> Drop didn't work in any of them, accept was tested
>>> only in first.
>>>
>>> i think thats all the settings i have.
>>>
>>>
>>> --- On Wed, 10/28/09, Dan <d..._at_jisp.net>
>>> wrote:
>>>
>>> From: Dan <d..._at_jisp.net>
>>> Subject: Re: [squid-users] Tproxy4+squid: ebtables
>>> wiki
>>>
>>> To: "Marko Kotar" <kotarma..._at_yahoo.com>,
>>> squid-users_at_squid-cache.org
>>>
>>> Date: Wednesday, October 28, 2009, 9:21 PM
>>> Marko Kotar wrote:
>>> Thanks.
>>>
>>> "redirect
>>>
>>> The redirect target will change the MAC target
>>> address
>>>
>>> to that of the bridge device the frame arrived on.
>>> This
>>>
>>> target can only be used in the BROUTING chain of
>>> the broute
>>>
>>> table and the PREROUTING chain of the nat table.
>>> In the
>>>
>>> BROUTING chain, the MAC address of the bridge port
>>> is used
>>>
>>> as destination address, in the PREROUTING chain,
>>> the MAC
>>>
>>> address of the bridge is used.
>>> --redirect-target target
>>>
>>> Specifies the standard
>>> target.
>>>
>>> After doing the MAC redirect, the rule still has
>>> to give a
>>>
>>> standard target so ebtables knows what to do. The
>>> default
>>>
>>> target is ACCEPT. Making it CONTINUE could let you
>>> use
>>>
>>> multiple target extensions on the same frame.
>>> Making it DROP
>>>
>>> in the BROUTING chain will let the frames be
>>> routed. RETURN
>>>
>>> is also allowed. Note that using RETURN in a base
>>> chain is
>>>
>>> not allowed."
>>>
>>> I think: If accept is used it goes in the
>>> tproxy
>>>
>>> because dst mac is changed to bridge address. (So
>>> it goes up
>>>
>>> as it would if client had gateway configured
>>> to that
>>>
>>> machine?) But is also should drop work?
>>> I decided to test it. I changed my rule to ACCEPT
>>> and
>>>
>>> traffic passes but not through the proxy.
>>> My
>>>
>>> access.log shows no new traffic after changing
>>> the
>>>
>>> rule. DROP is what passes the frame off to
>>> iptables. Could you show all your
>>> rules? If
>>>
>>> squid is receiving the traffic the only thing I
>>> can think of
>>>
>>> is that maybe there is another rule further down
>>> the chain
>>>
>>> that cause the frame to be routed.
>>>
>>> I have tryed drop but it didn't work. I didn't
>>> get
>>>
>>> through any traffic.
>>> If i didn't use any of ebtable rules it went
>>> through.
>>>
>>> But accept works. --- On Wed, 10/28/09,
>>> Dan
>>>
>>> <d..._at_jisp.net>
>>> wrote:
>>> From: Dan <d..._at_jisp.net>
>>> Subject: Re: [squid-users] Tproxy4+squid:
>>> ebtables
>>>
>>> wiki
>>> To: "Marko Kotar" <kotarma..._at_yahoo.com>
>>> Cc: squid-users_at_squid-cache.org
>>> Date: Wednesday, October 28, 2009, 1:03
>>> AM
>>>
>>> Marko Kotar wrote:
>>> Hi,
>>> You have incorrect commands in squid
>>> wiki for
>>>
>>> tproxy4
>>> ebtables:
>>> I figure out that it is not
>>> "--redirect-target
>>>
>>> DROP"
>>> but it is "--redirect-target ACCEPT"
>>> .
>>>
>>> With ebtables using broute ACCEPT and DROP
>>> have
>>>
>>> special
>>> meanings. DROP means route the frame
>>> and
>>>
>>> ACCEPT means bridge the frame.
>>>
>>> http://ebtables.sourceforge.net/misc/ebtables-man.html
>>>
>>> There is a "-j REDIRECT"
>>> which should
>>> be in
>>>
>>> lowercase
>>> letters "-j redirect".
>>> Thanks for guide.
>>>
>>> Marko
>>>
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>
>
>
Received on Mon Nov 09 2009 - 19:22:17 MST