Great to know that it wasn't something that I have been doing wrong. What ver of Fedora did you use? Were the netfilter/tproxy mods already compiled into the kernel? Thanks, --Joe -----Original Message----- From: Dan [mailto:dan@xxxxxxxx] Sent: Monday, November 09, 2009 2:22 PM To: Roth, Joe Cc: Irvan Adrian K; Amos Jeffries; squid-users@xxxxxxxxxxxxxxx Subject: Re: 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@xxxxxxxxxxxxxxxxx] > Sent: Monday, November 09, 2009 8:46 AM > To: Amos Jeffries > Cc: squid-users@xxxxxxxxxxxxxxx > Subject: Re: 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...@xxxxxxxx> wrote: >>> >>> >>> From: Dan <d...@xxxxxxxx> >>> Subject: Re: Tproxy4+squid: ebtables wiki >>> To: "Marko Kotar" <kotarma...@xxxxxxxxx> >>> Cc: squid-users@xxxxxxxxxxxxxxx >>> 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...@xxxxxxxx> >>> wrote: >>> >>> From: Dan <d...@xxxxxxxx> >>> Subject: Re: Tproxy4+squid: ebtables >>> wiki >>> >>> To: "Marko Kotar" <kotarma...@xxxxxxxxx>, >>> squid-users@xxxxxxxxxxxxxxx >>> >>> 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...@xxxxxxxx> >>> wrote: >>> From: Dan <d...@xxxxxxxx> >>> Subject: Re: Tproxy4+squid: >>> ebtables >>> >>> wiki >>> To: "Marko Kotar" <kotarma...@xxxxxxxxx> >>> Cc: squid-users@xxxxxxxxxxxxxxx >>> 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 >>> >>> >>> >>> >> > >
