Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
Hi Nick, I already tried your example above, with exception I'm using bridge with 2 ethernet not wccp. but i don't see something in access_log, when I tried to browse some sites. But i still could open the sites. 2009/07/07 21:44:17| Reconfiguring Squid Cache (version 3.1.0.9)... 2009/07/07 21:44:17| FD 10 Closing HTTP connection 2009/07/07 21:44:17| FD 13 Closing HTTP connection 2009/07/07 21:44:17| Processing Configuration File: /usr/local/squid/etc/squid.conf (depth 0) 2009/07/07 21:44:17| Starting IP Spoofing on port [::]:3129 2009/07/07 21:44:17| Disabling Authentication on port [::]:3129 (Ip spoofing enabled) 2009/07/07 21:44:17| Disabling IPv6 on port [::]:3129 (interception enabled) 2009/07/07 21:44:17| Initializing https proxy context 2009/07/07 21:44:17| DNS Socket created at [::], FD 10 2009/07/07 21:44:17| Adding domain edgestream.com from /etc/resolv.conf 2009/07/07 21:44:17| Adding nameserver 202.169.224.44 from /etc/resolv.conf 2009/07/07 21:44:17| Accepting HTTP connections at [::]:3128, FD 11. 2009/07/07 21:44:17| Accepting spoofing HTTP connections at 0.0.0.0:3129, FD 13. 2009/07/07 21:44:17| HTCP Disabled. 2009/07/07 21:44:17| Loaded Icons. 2009/07/07 21:44:17| Ready to serve requests. iptables -t mangle -L -xvn Chain PREROUTING (policy ACCEPT 9535 packets, 4088554 bytes) pkts bytes target prot opt in out source destination 7326 946003 DIVERT tcp -- * * 0.0.0.0/0 0.0.0.0/0 socket 3661 949270 TPROXY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 TPROXY redirect 192.168.1.205:3129 mark 0x1/0x1 Chain INPUT (policy ACCEPT 10693 packets, 1269475 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 13049 packets, 5011079 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 6481 packets, 2011014 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 19530 packets, 7022093 bytes) pkts bytes target prot opt in out source destination Chain DIVERT (1 references) pkts bytes target prot opt in out source destination 7326 946003 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK xset 0x1/0x 7326 946003 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ip rule 0: from all lookup 255 32764: from all fwmark 0x1 lookup tproxy 32765: from all fwmark 0x1 lookup tproxy 32766: from all lookup main 32767: from all lookup default ip route show table 100 local default dev lo scope host On Thu, Jul 2, 2009 at 11:31 AM, Ritter, Nicholasnicholas.rit...@americantv.com wrote: I have not finished updating the wiki article for the CentOS example, BTW. I will do this by tomorrow or possibly tonight yet. Nick -Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Wednesday, July 01, 2009 11:10 PM To: Alexandre DeAraujo Cc: Ritter, Nicholas; squid-users Subject: Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps. This won't work. You're only redirecting half of the traffic flow with the wccp web-cache service group. The tproxy code is probably correctly trying to originate packets -from- the client IP address to the upstream server but because you're only redirecting half of the packets (ie, packets from original client to upstream, and not also the packets from the upstream to the client - and this is the flow that needs to be hijacked!) things will hang. You need to read the TPROXY2 examples and look at the Cisco/Squid WCCP setup. There are two service groups configured - 80 and 90 - which redirect client - server and server-client respectively. They have the right bits set in the service group definitions to redirect the traffic correctly. The WCCPv2/TPROXY4 pages are hilariously unclear. I ended up having to find the TPROXY2 pages to extract the right WCCPv2 setup to use, then combine that with the TPROXY4 rules. That is fine for me (I know a thing or two about this) but it should all be made much, much clearer for people trying to set this up. As I suggested earlier, you may wish to consider fleshing out an interception section in the Wiki complete with explanations about how all of the various parts of the puzzle hold together. 2c, adrian 2009/7/2 Alexandre DeAraujo al...@cal.net: I am giving this one more try, but have been unsuccessful. Any help is always greatly appreciated. Here is the setup: Router: Cisco 7200 IOS 12.4(25) ip wccp web-cache redirect-list 11 access-list 11 permits only selective ip addresses to use wccp Wan interface (Serial) ip wccp web-cache redirect out Global WCCP information: Router information: Router Identifier: 192.168.20.1
RE: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
Bridging is a completely different beast...I have not done a bridging solution, so I can't help as much...with bridging I think you don't use iptables, but the bridging netfilter tables. That is probably the issue. -Original Message- From: johan firdianto [mailto:johanfi...@gmail.com] Sent: Tuesday, July 07, 2009 1:50 AM To: Ritter, Nicholas Cc: Adrian Chadd; Alexandre DeAraujo; squid-users Subject: Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps. Hi Nick, I already tried your example above, with exception I'm using bridge with 2 ethernet not wccp. but i don't see something in access_log, when I tried to browse some sites. But i still could open the sites. 2009/07/07 21:44:17| Reconfiguring Squid Cache (version 3.1.0.9)... 2009/07/07 21:44:17| FD 10 Closing HTTP connection 2009/07/07 21:44:17| FD 13 Closing HTTP connection 2009/07/07 21:44:17| Processing Configuration File: /usr/local/squid/etc/squid.conf (depth 0) 2009/07/07 21:44:17| Starting IP Spoofing on port [::]:3129 2009/07/07 21:44:17| Disabling Authentication on port [::]:3129 (Ip spoofing enabled) 2009/07/07 21:44:17| Disabling IPv6 on port [::]:3129 (interception enabled) 2009/07/07 21:44:17| Initializing https proxy context 2009/07/07 21:44:17| DNS Socket created at [::], FD 10 2009/07/07 21:44:17| Adding domain edgestream.com from /etc/resolv.conf 2009/07/07 21:44:17| Adding nameserver 202.169.224.44 from /etc/resolv.conf 2009/07/07 21:44:17| Accepting HTTP connections at [::]:3128, FD 11. 2009/07/07 21:44:17| Accepting spoofing HTTP connections at 0.0.0.0:3129, FD 13. 2009/07/07 21:44:17| HTCP Disabled. 2009/07/07 21:44:17| Loaded Icons. 2009/07/07 21:44:17| Ready to serve requests. iptables -t mangle -L -xvn Chain PREROUTING (policy ACCEPT 9535 packets, 4088554 bytes) pkts bytes target prot opt in out source destination 7326 946003 DIVERT tcp -- * * 0.0.0.0/0 0.0.0.0/0 socket 3661 949270 TPROXY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 TPROXY redirect 192.168.1.205:3129 mark 0x1/0x1 Chain INPUT (policy ACCEPT 10693 packets, 1269475 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 13049 packets, 5011079 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 6481 packets, 2011014 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 19530 packets, 7022093 bytes) pkts bytes target prot opt in out source destination Chain DIVERT (1 references) pkts bytes target prot opt in out source destination 7326 946003 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK xset 0x1/0x 7326 946003 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ip rule 0: from all lookup 255 32764: from all fwmark 0x1 lookup tproxy 32765: from all fwmark 0x1 lookup tproxy 32766: from all lookup main 32767: from all lookup default ip route show table 100 local default dev lo scope host On Thu, Jul 2, 2009 at 11:31 AM, Ritter, Nicholasnicholas.rit...@americantv.com wrote: I have not finished updating the wiki article for the CentOS example, BTW. I will do this by tomorrow or possibly tonight yet. Nick -Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Wednesday, July 01, 2009 11:10 PM To: Alexandre DeAraujo Cc: Ritter, Nicholas; squid-users Subject: Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps. This won't work. You're only redirecting half of the traffic flow with the wccp web-cache service group. The tproxy code is probably correctly trying to originate packets -from- the client IP address to the upstream server but because you're only redirecting half of the packets (ie, packets from original client to upstream, and not also the packets from the upstream to the client - and this is the flow that needs to be hijacked!) things will hang. You need to read the TPROXY2 examples and look at the Cisco/Squid WCCP setup. There are two service groups configured - 80 and 90 - which redirect client - server and server-client respectively. They have the right bits set in the service group definitions to redirect the traffic correctly. The WCCPv2/TPROXY4 pages are hilariously unclear. I ended up having to find the TPROXY2 pages to extract the right WCCPv2 setup to use, then combine that with the TPROXY4 rules. That is fine for me (I know a thing or two about this) but it should all be made much, much clearer for people trying to set this up. As I suggested earlier, you may wish to consider fleshing out an interception section in the Wiki complete with explanations about how all of the various parts of the puzzle hold together
Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
Hold on, I lack compile option connection tracking NAT. let me compile first. On Tue, Jul 7, 2009 at 9:15 PM, Ritter, Nicholasnicholas.rit...@americantv.com wrote: Bridging is a completely different beast...I have not done a bridging solution, so I can't help as much...with bridging I think you don't use iptables, but the bridging netfilter tables. That is probably the issue. -Original Message- From: johan firdianto [mailto:johanfi...@gmail.com] Sent: Tuesday, July 07, 2009 1:50 AM To: Ritter, Nicholas Cc: Adrian Chadd; Alexandre DeAraujo; squid-users Subject: Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps. Hi Nick, I already tried your example above, with exception I'm using bridge with 2 ethernet not wccp. but i don't see something in access_log, when I tried to browse some sites. But i still could open the sites. 2009/07/07 21:44:17| Reconfiguring Squid Cache (version 3.1.0.9)... 2009/07/07 21:44:17| FD 10 Closing HTTP connection 2009/07/07 21:44:17| FD 13 Closing HTTP connection 2009/07/07 21:44:17| Processing Configuration File: /usr/local/squid/etc/squid.conf (depth 0) 2009/07/07 21:44:17| Starting IP Spoofing on port [::]:3129 2009/07/07 21:44:17| Disabling Authentication on port [::]:3129 (Ip spoofing enabled) 2009/07/07 21:44:17| Disabling IPv6 on port [::]:3129 (interception enabled) 2009/07/07 21:44:17| Initializing https proxy context 2009/07/07 21:44:17| DNS Socket created at [::], FD 10 2009/07/07 21:44:17| Adding domain edgestream.com from /etc/resolv.conf 2009/07/07 21:44:17| Adding nameserver 202.169.224.44 from /etc/resolv.conf 2009/07/07 21:44:17| Accepting HTTP connections at [::]:3128, FD 11. 2009/07/07 21:44:17| Accepting spoofing HTTP connections at 0.0.0.0:3129, FD 13. 2009/07/07 21:44:17| HTCP Disabled. 2009/07/07 21:44:17| Loaded Icons. 2009/07/07 21:44:17| Ready to serve requests. iptables -t mangle -L -xvn Chain PREROUTING (policy ACCEPT 9535 packets, 4088554 bytes) pkts bytes target prot opt in out source destination 7326 946003 DIVERT tcp -- * * 0.0.0.0/0 0.0.0.0/0 socket 3661 949270 TPROXY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 TPROXY redirect 192.168.1.205:3129 mark 0x1/0x1 Chain INPUT (policy ACCEPT 10693 packets, 1269475 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 13049 packets, 5011079 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 6481 packets, 2011014 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 19530 packets, 7022093 bytes) pkts bytes target prot opt in out source destination Chain DIVERT (1 references) pkts bytes target prot opt in out source destination 7326 946003 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK xset 0x1/0x 7326 946003 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ip rule 0: from all lookup 255 32764: from all fwmark 0x1 lookup tproxy 32765: from all fwmark 0x1 lookup tproxy 32766: from all lookup main 32767: from all lookup default ip route show table 100 local default dev lo scope host On Thu, Jul 2, 2009 at 11:31 AM, Ritter, Nicholasnicholas.rit...@americantv.com wrote: I have not finished updating the wiki article for the CentOS example, BTW. I will do this by tomorrow or possibly tonight yet. Nick -Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Wednesday, July 01, 2009 11:10 PM To: Alexandre DeAraujo Cc: Ritter, Nicholas; squid-users Subject: Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps. This won't work. You're only redirecting half of the traffic flow with the wccp web-cache service group. The tproxy code is probably correctly trying to originate packets -from- the client IP address to the upstream server but because you're only redirecting half of the packets (ie, packets from original client to upstream, and not also the packets from the upstream to the client - and this is the flow that needs to be hijacked!) things will hang. You need to read the TPROXY2 examples and look at the Cisco/Squid WCCP setup. There are two service groups configured - 80 and 90 - which redirect client - server and server-client respectively. They have the right bits set in the service group definitions to redirect the traffic correctly. The WCCPv2/TPROXY4 pages are hilariously unclear. I ended up having to find the TPROXY2 pages to extract the right WCCPv2 setup to use, then combine that with the TPROXY4 rules. That is fine for me (I know a thing or two about this) but it should all be made much, much clearer
Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
johan firdianto wrote: Hold on, I lack compile option connection tracking NAT. let me compile first. TPROXY was designed to be usable without NAT. If you can confirm a dependency please report it to the netfilter and balabit people. Amos On Tue, Jul 7, 2009 at 9:15 PM, Ritter, Nicholasnicholas.rit...@americantv.com wrote: Bridging is a completely different beast...I have not done a bridging solution, so I can't help as much...with bridging I think you don't use iptables, but the bridging netfilter tables. That is probably the issue. -Original Message- From: johan firdianto [mailto:johanfi...@gmail.com] Sent: Tuesday, July 07, 2009 1:50 AM To: Ritter, Nicholas Cc: Adrian Chadd; Alexandre DeAraujo; squid-users Subject: Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps. Hi Nick, I already tried your example above, with exception I'm using bridge with 2 ethernet not wccp. but i don't see something in access_log, when I tried to browse some sites. But i still could open the sites. 2009/07/07 21:44:17| Reconfiguring Squid Cache (version 3.1.0.9)... 2009/07/07 21:44:17| FD 10 Closing HTTP connection 2009/07/07 21:44:17| FD 13 Closing HTTP connection 2009/07/07 21:44:17| Processing Configuration File: /usr/local/squid/etc/squid.conf (depth 0) 2009/07/07 21:44:17| Starting IP Spoofing on port [::]:3129 2009/07/07 21:44:17| Disabling Authentication on port [::]:3129 (Ip spoofing enabled) 2009/07/07 21:44:17| Disabling IPv6 on port [::]:3129 (interception enabled) 2009/07/07 21:44:17| Initializing https proxy context 2009/07/07 21:44:17| DNS Socket created at [::], FD 10 2009/07/07 21:44:17| Adding domain edgestream.com from /etc/resolv.conf 2009/07/07 21:44:17| Adding nameserver 202.169.224.44 from /etc/resolv.conf 2009/07/07 21:44:17| Accepting HTTP connections at [::]:3128, FD 11. 2009/07/07 21:44:17| Accepting spoofing HTTP connections at 0.0.0.0:3129, FD 13. 2009/07/07 21:44:17| HTCP Disabled. 2009/07/07 21:44:17| Loaded Icons. 2009/07/07 21:44:17| Ready to serve requests. iptables -t mangle -L -xvn Chain PREROUTING (policy ACCEPT 9535 packets, 4088554 bytes) pkts bytes target prot opt in out source destination 7326 946003 DIVERT tcp -- * * 0.0.0.0/0 0.0.0.0/0 socket 3661 949270 TPROXY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 TPROXY redirect 192.168.1.205:3129 mark 0x1/0x1 Chain INPUT (policy ACCEPT 10693 packets, 1269475 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 13049 packets, 5011079 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 6481 packets, 2011014 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 19530 packets, 7022093 bytes) pkts bytes target prot opt in out source destination Chain DIVERT (1 references) pkts bytes target prot opt in out source destination 7326 946003 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK xset 0x1/0x 7326 946003 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ip rule 0: from all lookup 255 32764: from all fwmark 0x1 lookup tproxy 32765: from all fwmark 0x1 lookup tproxy 32766: from all lookup main 32767: from all lookup default ip route show table 100 local default dev lo scope host On Thu, Jul 2, 2009 at 11:31 AM, Ritter, Nicholasnicholas.rit...@americantv.com wrote: I have not finished updating the wiki article for the CentOS example, BTW. I will do this by tomorrow or possibly tonight yet. Nick -Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Wednesday, July 01, 2009 11:10 PM To: Alexandre DeAraujo Cc: Ritter, Nicholas; squid-users Subject: Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps. This won't work. You're only redirecting half of the traffic flow with the wccp web-cache service group. The tproxy code is probably correctly trying to originate packets -from- the client IP address to the upstream server but because you're only redirecting half of the packets (ie, packets from original client to upstream, and not also the packets from the upstream to the client - and this is the flow that needs to be hijacked!) things will hang. You need to read the TPROXY2 examples and look at the Cisco/Squid WCCP setup. There are two service groups configured - 80 and 90 - which redirect client - server and server-client respectively. They have the right bits set in the service group definitions to redirect the traffic correctly. The WCCPv2/TPROXY4 pages are hilariously unclear. I ended up having to find the TPROXY2 pages to extract the right WCCPv2 setup to use, then combine that with the TPROXY4 rules. That is fine for me (I know
Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
You're right Jefrries, after compiling connection tracking NAT, it doesn't make sense. I mean, i can't see my browsing log in access.log no error in cache.log counter iptables is incrementing. But I still can browse. When i dump the packet, no header squid appended at response, so the response didn't come from squid. how to check that packet from iptables hits squid ?. or in bridging environment need different solution ? Thanks. Johan On Tue, Jul 7, 2009 at 9:53 PM, Amos Jeffriessqu...@treenet.co.nz wrote: johan firdianto wrote: Hold on, I lack compile option connection tracking NAT. let me compile first. TPROXY was designed to be usable without NAT. If you can confirm a dependency please report it to the netfilter and balabit people. Amos On Tue, Jul 7, 2009 at 9:15 PM, Ritter, Nicholasnicholas.rit...@americantv.com wrote: Bridging is a completely different beast...I have not done a bridging solution, so I can't help as much...with bridging I think you don't use iptables, but the bridging netfilter tables. That is probably the issue. -Original Message- From: johan firdianto [mailto:johanfi...@gmail.com] Sent: Tuesday, July 07, 2009 1:50 AM To: Ritter, Nicholas Cc: Adrian Chadd; Alexandre DeAraujo; squid-users Subject: Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps. Hi Nick, I already tried your example above, with exception I'm using bridge with 2 ethernet not wccp. but i don't see something in access_log, when I tried to browse some sites. But i still could open the sites. 2009/07/07 21:44:17| Reconfiguring Squid Cache (version 3.1.0.9)... 2009/07/07 21:44:17| FD 10 Closing HTTP connection 2009/07/07 21:44:17| FD 13 Closing HTTP connection 2009/07/07 21:44:17| Processing Configuration File: /usr/local/squid/etc/squid.conf (depth 0) 2009/07/07 21:44:17| Starting IP Spoofing on port [::]:3129 2009/07/07 21:44:17| Disabling Authentication on port [::]:3129 (Ip spoofing enabled) 2009/07/07 21:44:17| Disabling IPv6 on port [::]:3129 (interception enabled) 2009/07/07 21:44:17| Initializing https proxy context 2009/07/07 21:44:17| DNS Socket created at [::], FD 10 2009/07/07 21:44:17| Adding domain edgestream.com from /etc/resolv.conf 2009/07/07 21:44:17| Adding nameserver 202.169.224.44 from /etc/resolv.conf 2009/07/07 21:44:17| Accepting HTTP connections at [::]:3128, FD 11. 2009/07/07 21:44:17| Accepting spoofing HTTP connections at 0.0.0.0:3129, FD 13. 2009/07/07 21:44:17| HTCP Disabled. 2009/07/07 21:44:17| Loaded Icons. 2009/07/07 21:44:17| Ready to serve requests. iptables -t mangle -L -xvn Chain PREROUTING (policy ACCEPT 9535 packets, 4088554 bytes) pkts bytes target prot opt in out source destination 7326 946003 DIVERT tcp -- * * 0.0.0.0/0 0.0.0.0/0 socket 3661 949270 TPROXY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 TPROXY redirect 192.168.1.205:3129 mark 0x1/0x1 Chain INPUT (policy ACCEPT 10693 packets, 1269475 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 13049 packets, 5011079 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 6481 packets, 2011014 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 19530 packets, 7022093 bytes) pkts bytes target prot opt in out source destination Chain DIVERT (1 references) pkts bytes target prot opt in out source destination 7326 946003 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK xset 0x1/0x 7326 946003 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ip rule 0: from all lookup 255 32764: from all fwmark 0x1 lookup tproxy 32765: from all fwmark 0x1 lookup tproxy 32766: from all lookup main 32767: from all lookup default ip route show table 100 local default dev lo scope host On Thu, Jul 2, 2009 at 11:31 AM, Ritter, Nicholasnicholas.rit...@americantv.com wrote: I have not finished updating the wiki article for the CentOS example, BTW. I will do this by tomorrow or possibly tonight yet. Nick -Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Wednesday, July 01, 2009 11:10 PM To: Alexandre DeAraujo Cc: Ritter, Nicholas; squid-users Subject: Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps. This won't work. You're only redirecting half of the traffic flow with the wccp web-cache service group. The tproxy code is probably correctly trying to originate packets -from- the client IP address to the upstream server but because you're only redirecting half of the packets (ie, packets from original client to upstream, and not also the packets from
RE: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
I am giving this one more try, but have been unsuccessful. Any help is always greatly appreciated. Here is the setup: Router: Cisco 7200 IOS 12.4(25) ip wccp web-cache redirect-list 11 access-list 11 permits only selective ip addresses to use wccp Wan interface (Serial) ip wccp web-cache redirect out Global WCCP information: Router information: Router Identifier: 192.168.20.1 Protocol Version: 2.0 Service Identifier: web-cache Number of Service Group Clients:1 Number of Service Group Routers:1 Total Packets s/w Redirected: 8797 Process:4723 Fast: 0 CEF:4074 Redirect access-list: 11 Total Packets Denied Redirect: 124925546 Total Packets Unassigned: 924514 Group access-list: -none- Total Messages Denied to Group: 0 Total Authentication failures: 0 Total Bypassed Packets Received:0 WCCP Client information: WCCP Client ID: 192.168.20.2 Protocol Version: 2.0 State: Usable Initial Hash Info: Assigned Hash Info: Hash Allotment: 256 (100.00%) Packets s/w Redirected: 306 Connect Time: 00:21:33 Bypassed Packets Process:0 Fast: 0 CEF:0 Errors: 0 Clients are on FEthernet0/1 Squid server is the only device on FEthernet0/3 Squid Server: eth0 Link encap:Ethernet HWaddr 00:14:22:21:A1:7D inet addr:192.168.20.2 Bcast:192.168.20.7 Mask:255.255.255.248 inet6 addr: fe80::214:22ff:fe21:a17d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3325 errors:0 dropped:0 overruns:0 frame:0 TX packets:2606 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:335149 (327.2 KiB) TX bytes:394943 (385.6 KiB) gre0 Link encap:UNSPEC HWaddr 00-00-00-00-CB-BF-F4-FF-00-00-00-00-00-00-00-00 inet addr:192.168.20.2 Mask:255.255.255.248 UP RUNNING NOARP MTU:1476 Metric:1 RX packets:400 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:31760 (31.0 KiB) TX bytes:0 (0.0 b) /etc/rc.d/rc.local file: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 modprobe ip_gre ifconfig gre0 192.168.20.2 netmask 255.255.255.248 up echo 1 /proc/sys/net/ipv4/ip_nonlocal_bind /etc/sysconfig/iptables file: # Generated by iptables-save v1.4.4 on Wed Jul 1 03:32:55 2009 *mangle :PREROUTING ACCEPT [166:11172] :INPUT ACCEPT [164:8718] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [130:12272] :POSTROUTING ACCEPT [130:12272] :DIVERT - [0:0] -A DIVERT -j MARK --set-xmark 0x1/0x -A DIVERT -j ACCEPT -A PREROUTING -p tcp -m socket -j DIVERT -A PREROUTING -p tcp -m tcp --dport 80 -j TPROXY --on-port 3128 --on-ip 192.168.20.2 --tproxy-mark 0x1/0x1 COMMIT # Completed on Wed Jul 1 03:32:55 2009 # Generated by iptables-save v1.4.4 on Wed Jul 1 03:32:55 2009 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [160:15168] :RH-Firewall-1-INPUT - [0:0] -A INPUT -i gre0 -j ACCEPT -A INPUT -p gre -j ACCEPT -A INPUT -i eth0 -p gre -j ACCEPT -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -s 192.168.20.1/32 -p udp -m udp --dport 2048 -j ACCEPT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p esp -j ACCEPT -A RH-Firewall-1-INPUT -p ah -j ACCEPT -A RH-Firewall-1-INPUT -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT # Completed on Wed Jul 1 03:32:55 2009 -squid.conf acl manager proto cache_object acl localhost src 127.0.0.1/32 acl to_localhost dst 127.0.0.0/8 acl localnet src 10.0.0.0/8 # RFC1918 possible internal network acl localnet src 172.16.0.0/12 # RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network acl testing src 10.10.10.0/24 acl SSL_ports port
RE: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
On Wed, 1 Jul 2009 16:59:03 -0700, Alexandre DeAraujo al...@cal.net wrote: I am giving this one more try, but have been unsuccessful. Any help is always greatly appreciated. I've had the opportunity to work through at a very low level with someone recently and found the major issue with WCCP and TPROXY. It seems the claimed auto-detection and bypass of proxy outbound traffic depends on IP address in the outbound packet (under TPROXYv4 this is the wrong address). Check that you can identify the outbound proxy traffic using something other than the IP and add a bypass rule manually. Good things to test for are source interface (ethX, MAC, EUI-64), or apparently service group. Maybe TOS as well if you also have Squid set that. The Features/Tproxy4 wiki page is updated with this and some details on what to look for and some other general options that may solve it. Amos Here is the setup: Router: Cisco 7200 IOS 12.4(25) ip wccp web-cache redirect-list 11 access-list 11 permits only selective ip addresses to use wccp Wan interface (Serial) ip wccp web-cache redirect out Global WCCP information: Router information: Router Identifier:192.168.20.1 Protocol Version: 2.0 Service Identifier: web-cache Number of Service Group Clients: 1 Number of Service Group Routers: 1 Total Packets s/w Redirected: 8797 Process: 4723 Fast: 0 CEF: 4074 Redirect access-list: 11 Total Packets Denied Redirect:124925546 Total Packets Unassigned: 924514 Group access-list:-none- Total Messages Denied to Group: 0 Total Authentication failures:0 Total Bypassed Packets Received: 0 WCCP Client information: WCCP Client ID: 192.168.20.2 Protocol Version: 2.0 State:Usable Initial Hash Info: Assigned Hash Info: Hash Allotment: 256 (100.00%) Packets s/w Redirected: 306 Connect Time: 00:21:33 Bypassed Packets Process: 0 Fast: 0 CEF: 0 Errors: 0 Clients are on FEthernet0/1 Squid server is the only device on FEthernet0/3 Squid Server: eth0 Link encap:Ethernet HWaddr 00:14:22:21:A1:7D inet addr:192.168.20.2 Bcast:192.168.20.7 Mask:255.255.255.248 inet6 addr: fe80::214:22ff:fe21:a17d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3325 errors:0 dropped:0 overruns:0 frame:0 TX packets:2606 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:335149 (327.2 KiB) TX bytes:394943 (385.6 KiB) gre0 Link encap:UNSPEC HWaddr 00-00-00-00-CB-BF-F4-FF-00-00-00-00-00-00-00-00 inet addr:192.168.20.2 Mask:255.255.255.248 UP RUNNING NOARP MTU:1476 Metric:1 RX packets:400 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:31760 (31.0 KiB) TX bytes:0 (0.0 b) /etc/rc.d/rc.local file: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 modprobe ip_gre ifconfig gre0 192.168.20.2 netmask 255.255.255.248 up echo 1 /proc/sys/net/ipv4/ip_nonlocal_bind /etc/sysconfig/iptables file: # Generated by iptables-save v1.4.4 on Wed Jul 1 03:32:55 2009 *mangle :PREROUTING ACCEPT [166:11172] :INPUT ACCEPT [164:8718] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [130:12272] :POSTROUTING ACCEPT [130:12272] :DIVERT - [0:0] -A DIVERT -j MARK --set-xmark 0x1/0x -A DIVERT -j ACCEPT -A PREROUTING -p tcp -m socket -j DIVERT -A PREROUTING -p tcp -m tcp --dport 80 -j TPROXY --on-port 3128 --on-ip 192.168.20.2 --tproxy-mark 0x1/0x1 COMMIT # Completed on Wed Jul 1 03:32:55 2009 # Generated by iptables-save v1.4.4 on Wed Jul 1 03:32:55 2009 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [160:15168] :RH-Firewall-1-INPUT - [0:0] -A INPUT -i gre0 -j ACCEPT -A INPUT -p gre -j ACCEPT -A INPUT -i eth0 -p gre -j ACCEPT -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -s 192.168.20.1/32 -p udp -m udp --dport 2048 -j ACCEPT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p esp -j ACCEPT -A RH-Firewall-1-INPUT -p
Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
This won't work. You're only redirecting half of the traffic flow with the wccp web-cache service group. The tproxy code is probably correctly trying to originate packets -from- the client IP address to the upstream server but because you're only redirecting half of the packets (ie, packets from original client to upstream, and not also the packets from the upstream to the client - and this is the flow that needs to be hijacked!) things will hang. You need to read the TPROXY2 examples and look at the Cisco/Squid WCCP setup. There are two service groups configured - 80 and 90 - which redirect client - server and server-client respectively. They have the right bits set in the service group definitions to redirect the traffic correctly. The WCCPv2/TPROXY4 pages are hilariously unclear. I ended up having to find the TPROXY2 pages to extract the right WCCPv2 setup to use, then combine that with the TPROXY4 rules. That is fine for me (I know a thing or two about this) but it should all be made much, much clearer for people trying to set this up. As I suggested earlier, you may wish to consider fleshing out an interception section in the Wiki complete with explanations about how all of the various parts of the puzzle hold together. 2c, adrian 2009/7/2 Alexandre DeAraujo al...@cal.net: I am giving this one more try, but have been unsuccessful. Any help is always greatly appreciated. Here is the setup: Router: Cisco 7200 IOS 12.4(25) ip wccp web-cache redirect-list 11 access-list 11 permits only selective ip addresses to use wccp Wan interface (Serial) ip wccp web-cache redirect out Global WCCP information: Router information: Router Identifier: 192.168.20.1 Protocol Version: 2.0 Service Identifier: web-cache Number of Service Group Clients: 1 Number of Service Group Routers: 1 Total Packets s/w Redirected: 8797 Process: 4723 Fast: 0 CEF: 4074 Redirect access-list: 11 Total Packets Denied Redirect: 124925546 Total Packets Unassigned: 924514 Group access-list: -none- Total Messages Denied to Group: 0 Total Authentication failures: 0 Total Bypassed Packets Received: 0 WCCP Client information: WCCP Client ID: 192.168.20.2 Protocol Version: 2.0 State: Usable Initial Hash Info: Assigned Hash Info: Hash Allotment: 256 (100.00%) Packets s/w Redirected: 306 Connect Time: 00:21:33 Bypassed Packets Process: 0 Fast: 0 CEF: 0 Errors: 0 Clients are on FEthernet0/1 Squid server is the only device on FEthernet0/3 Squid Server: eth0 Link encap:Ethernet HWaddr 00:14:22:21:A1:7D inet addr:192.168.20.2 Bcast:192.168.20.7 Mask:255.255.255.248 inet6 addr: fe80::214:22ff:fe21:a17d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3325 errors:0 dropped:0 overruns:0 frame:0 TX packets:2606 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:335149 (327.2 KiB) TX bytes:394943 (385.6 KiB) gre0 Link encap:UNSPEC HWaddr 00-00-00-00-CB-BF-F4-FF-00-00-00-00-00-00-00-00 inet addr:192.168.20.2 Mask:255.255.255.248 UP RUNNING NOARP MTU:1476 Metric:1 RX packets:400 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:31760 (31.0 KiB) TX bytes:0 (0.0 b) /etc/rc.d/rc.local file: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 modprobe ip_gre ifconfig gre0 192.168.20.2 netmask 255.255.255.248 up echo 1 /proc/sys/net/ipv4/ip_nonlocal_bind /etc/sysconfig/iptables file: # Generated by iptables-save v1.4.4 on Wed Jul 1 03:32:55 2009 *mangle :PREROUTING ACCEPT [166:11172] :INPUT ACCEPT [164:8718] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [130:12272] :POSTROUTING ACCEPT [130:12272] :DIVERT - [0:0] -A DIVERT -j MARK --set-xmark 0x1/0x -A DIVERT -j ACCEPT -A PREROUTING -p tcp -m socket -j DIVERT -A PREROUTING -p tcp -m tcp --dport 80 -j TPROXY --on-port 3128 --on-ip 192.168.20.2 --tproxy-mark 0x1/0x1 COMMIT # Completed on Wed Jul 1 03:32:55 2009 # Generated by iptables-save v1.4.4 on Wed Jul 1 03:32:55 2009 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT
RE: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
I have not finished updating the wiki article for the CentOS example, BTW. I will do this by tomorrow or possibly tonight yet. Nick -Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Wednesday, July 01, 2009 11:10 PM To: Alexandre DeAraujo Cc: Ritter, Nicholas; squid-users Subject: Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps. This won't work. You're only redirecting half of the traffic flow with the wccp web-cache service group. The tproxy code is probably correctly trying to originate packets -from- the client IP address to the upstream server but because you're only redirecting half of the packets (ie, packets from original client to upstream, and not also the packets from the upstream to the client - and this is the flow that needs to be hijacked!) things will hang. You need to read the TPROXY2 examples and look at the Cisco/Squid WCCP setup. There are two service groups configured - 80 and 90 - which redirect client - server and server-client respectively. They have the right bits set in the service group definitions to redirect the traffic correctly. The WCCPv2/TPROXY4 pages are hilariously unclear. I ended up having to find the TPROXY2 pages to extract the right WCCPv2 setup to use, then combine that with the TPROXY4 rules. That is fine for me (I know a thing or two about this) but it should all be made much, much clearer for people trying to set this up. As I suggested earlier, you may wish to consider fleshing out an interception section in the Wiki complete with explanations about how all of the various parts of the puzzle hold together. 2c, adrian 2009/7/2 Alexandre DeAraujo al...@cal.net: I am giving this one more try, but have been unsuccessful. Any help is always greatly appreciated. Here is the setup: Router: Cisco 7200 IOS 12.4(25) ip wccp web-cache redirect-list 11 access-list 11 permits only selective ip addresses to use wccp Wan interface (Serial) ip wccp web-cache redirect out Global WCCP information: Router information: Router Identifier: 192.168.20.1 Protocol Version: 2.0 Service Identifier: web-cache Number of Service Group Clients: 1 Number of Service Group Routers: 1 Total Packets s/w Redirected: 8797 Process: 4723 Fast: 0 CEF: 4074 Redirect access-list: 11 Total Packets Denied Redirect: 124925546 Total Packets Unassigned: 924514 Group access-list: -none- Total Messages Denied to Group: 0 Total Authentication failures: 0 Total Bypassed Packets Received: 0 WCCP Client information: WCCP Client ID: 192.168.20.2 Protocol Version: 2.0 State: Usable Initial Hash Info: Assigned Hash Info: Hash Allotment: 256 (100.00%) Packets s/w Redirected: 306 Connect Time: 00:21:33 Bypassed Packets Process: 0 Fast: 0 CEF: 0 Errors: 0 Clients are on FEthernet0/1 Squid server is the only device on FEthernet0/3 Squid Server: eth0 Link encap:Ethernet HWaddr 00:14:22:21:A1:7D inet addr:192.168.20.2 Bcast:192.168.20.7 Mask:255.255.255.248 inet6 addr: fe80::214:22ff:fe21:a17d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3325 errors:0 dropped:0 overruns:0 frame:0 TX packets:2606 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:335149 (327.2 KiB) TX bytes:394943 (385.6 KiB) gre0 Link encap:UNSPEC HWaddr 00-00-00-00-CB-BF-F4-FF-00-00-00-00-00-00-00-00 inet addr:192.168.20.2 Mask:255.255.255.248 UP RUNNING NOARP MTU:1476 Metric:1 RX packets:400 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:31760 (31.0 KiB) TX bytes:0 (0.0 b) /etc/rc.d/rc.local file: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 modprobe ip_gre ifconfig gre0 192.168.20.2 netmask 255.255.255.248 up echo 1 /proc/sys/net/ipv4/ip_nonlocal_bind /etc/sysconfig/iptables file: # Generated by iptables-save v1.4.4 on Wed Jul 1 03:32:55 2009 *mangle :PREROUTING ACCEPT [166:11172] :INPUT ACCEPT [164:8718] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [130:12272
Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
Would be great if you could dump this in a wiki article to make it easier to find (and update if needed). Regards Henrik tor 2009-06-25 klockan 12:30 -0500 skrev Ritter, Nicholas: Some assumptions: 1) You are using a Cisco Router to redirect traffic to the squid box via WCCP 2) 12.4(15)T8 or higher IOS on the router 3) In my setups, the squid box is always Layer 2 adjacent to the Cisco router, either through a dedicated interface, or a sub-interface. 4) The ability to compile and install a Linux kernel. Please note that in these steps, I am NOT using a redhat kernel, nor am I using the RedHat method of building a kernel. 5) Some steps outlined here can be achieved through several different means, follow the steps exactly before emailing me or the list, as I have tested other methods, and they don't always work (case in point: GRE tunnel interface creation.) 6) This setup assumes a separate WCCP service group for each direction of the HTTP connection, this is not needed, but makes the setup more scalable. If you choose to do it a different way, then YMMV. In the kernel build specific steps, I actually include possibly to much information, as well as tell you to enable things that are not always needed for TPROXY related functionality, or never related to TPROXY functionality. I included them because they fit more environments, and thus less time wasted by people asking me questions, not that I mind but I don't have enough time to answer all the emails I get. I tried to prepare this information out without errors, if the steps don't work, email me with the details of where you had problems so that I can adjust the steps below. At the end the steps below are some common things to watch for in the steps that can cause the setup not to work. Steps 1) Install CentOS 5.3, make sure you install nothing other than the base packages, and trim even those down. I tend to install specific packages from the distro later. Note: I suggest that you make separate partition(s) for where squid will actually store its caches. Later mount these partitions with specific options (like noatime) that will help increase performance. 2) In the initial ncurses-based setup screen, turn off services that you don't need, and turn off selinux compeletely. 3) After install and initial bootup and configuration, run yum update to update the system for fixes, etc. Then reboot. 4) After step 2, issue this yum command: yum install libcap libcap-devel gcc gcc-c++ bison flex yacc autoconf automake ncurses ncurses-devel rpm-devel libpcap tcpdump Note: let it install other dependency packages. The command above installs compiles, utilities, etc. 5) Download iptables-1.4.3.2 from netfilter.org 6) Download kernel 2.6.30 from kernel.org 7) Download squid-3.1.0.8 from squid.org 8) Decompress the kernel source, I decompress it to /usr/src/, although I have read all over the place that this is a bad thing to do. The location really does not have to be /usr/src/ 9) Go into the kernel source directory, issue the following command: cp /boot/config-2.6.18-128.1.14.el5 ./RH-config-boxed.config 10) Issue this command: make menuconfig 11) When the ncurses-based kernel config screen loads, select the Load an Alternate Configuration File and type in the full path to the RH-config-boxed.config. This will load the current kernel config, and there may be some errors, all of which can be ignored. 12) Configure the kernel as you normally would, but be sure to enable the following: In Networking support - Networking options Enable (not as modules): Packet socket Packet socket: mmapped IO TCP/IP networking IP: advanced router IP: policy routing Enable (as modules): IP: tunneling Enable (not as modules): IP: GRE tunnels over IP IP: broadcast GRE over IP Network packet filtering framework (Netfilter) In Networking support - Networking options - Network packet filtering framework (Netfilter) Enable (not as modules): Advanced netfilter configuration In Networking support - Networking options - Network packet filtering framework (Netfilter) - Core Netfilter Configuration Enable (as modules): Netfilter connection tracking support Enable (not as modules): Connection tracking security mark support Connection tracking events Enable (as modules): Connection tracking netlink interface Transparent proxying support (EXPERIMENTAL) Netfilter Xtables support (required for ip_tables) CONNMARK target support MARK target support TPROXY target support (EXPERIMENTAL) connmark connection mark match support conntrack connection tracking match support mark match support socket match support (EXPERIMENTAL) state match support In Networking support - Networking options - Network packet filtering framework (Netfilter) - IP: Netfilter Configuration Enable (as modules): IPv4 connection tracking support (required
RE: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
Amos did this alreadyalthough the wiki article needs some corrections because Amos merged the older with the newer. I need to get that information to him. The steps, if followed in the wiki article may not work quite right. Nick -Original Message- From: Henrik Nordstrom [mailto:hen...@henriknordstrom.net] Sent: Monday, June 29, 2009 4:01 PM To: Ritter, Nicholas Cc: squid-users Subject: Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps. Would be great if you could dump this in a wiki article to make it easier to find (and update if needed). Regards Henrik tor 2009-06-25 klockan 12:30 -0500 skrev Ritter, Nicholas: Some assumptions: 1) You are using a Cisco Router to redirect traffic to the squid box via WCCP 2) 12.4(15)T8 or higher IOS on the router 3) In my setups, the squid box is always Layer 2 adjacent to the Cisco router, either through a dedicated interface, or a sub-interface. 4) The ability to compile and install a Linux kernel. Please note that in these steps, I am NOT using a redhat kernel, nor am I using the RedHat method of building a kernel. 5) Some steps outlined here can be achieved through several different means, follow the steps exactly before emailing me or the list, as I have tested other methods, and they don't always work (case in point: GRE tunnel interface creation.) 6) This setup assumes a separate WCCP service group for each direction of the HTTP connection, this is not needed, but makes the setup more scalable. If you choose to do it a different way, then YMMV. In the kernel build specific steps, I actually include possibly to much information, as well as tell you to enable things that are not always needed for TPROXY related functionality, or never related to TPROXY functionality. I included them because they fit more environments, and thus less time wasted by people asking me questions, not that I mind but I don't have enough time to answer all the emails I get. I tried to prepare this information out without errors, if the steps don't work, email me with the details of where you had problems so that I can adjust the steps below. At the end the steps below are some common things to watch for in the steps that can cause the setup not to work. Steps 1) Install CentOS 5.3, make sure you install nothing other than the base packages, and trim even those down. I tend to install specific packages from the distro later. Note: I suggest that you make separate partition(s) for where squid will actually store its caches. Later mount these partitions with specific options (like noatime) that will help increase performance. 2) In the initial ncurses-based setup screen, turn off services that you don't need, and turn off selinux compeletely. 3) After install and initial bootup and configuration, run yum update to update the system for fixes, etc. Then reboot. 4) After step 2, issue this yum command: yum install libcap libcap-devel gcc gcc-c++ bison flex yacc autoconf automake ncurses ncurses-devel rpm-devel libpcap tcpdump Note: let it install other dependency packages. The command above installs compiles, utilities, etc. 5) Download iptables-1.4.3.2 from netfilter.org 6) Download kernel 2.6.30 from kernel.org 7) Download squid-3.1.0.8 from squid.org 8) Decompress the kernel source, I decompress it to /usr/src/, although I have read all over the place that this is a bad thing to do. The location really does not have to be /usr/src/ 9) Go into the kernel source directory, issue the following command: cp /boot/config-2.6.18-128.1.14.el5 ./RH-config-boxed.config 10) Issue this command: make menuconfig 11) When the ncurses-based kernel config screen loads, select the Load an Alternate Configuration File and type in the full path to the RH-config-boxed.config. This will load the current kernel config, and there may be some errors, all of which can be ignored. 12) Configure the kernel as you normally would, but be sure to enable the following: In Networking support - Networking options Enable (not as modules): Packet socket Packet socket: mmapped IO TCP/IP networking IP: advanced router IP: policy routing Enable (as modules): IP: tunneling Enable (not as modules): IP: GRE tunnels over IP IP: broadcast GRE over IP Network packet filtering framework (Netfilter) In Networking support - Networking options - Network packet filtering framework (Netfilter) Enable (not as modules): Advanced netfilter configuration In Networking support - Networking options - Network packet filtering framework (Netfilter) - Core Netfilter Configuration Enable (as modules): Netfilter connection tracking support Enable (not as modules): Connection tracking security mark support Connection tracking events Enable (as modules): Connection tracking netlink interface Transparent proxying support (EXPERIMENTAL) Netfilter Xtables
RE: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
mån 2009-06-29 klockan 16:11 -0500 skrev Ritter, Nicholas: Amos did this alreadyalthough the wiki article needs some corrections because Amos merged the older with the newer. I need to get that information to him. The steps, if followed in the wiki article may not work quite right. Perhaps you should get yourself an wiki account? It's pretty simple. Instructions can be found at the top of the squid wiki main page. Regards Henrik
Re: [squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
Good writeup! I'm rapidly coming to the conclusion that the problem with transparency setups is not just a lack of documentation and examples, but a lack of clear explanation and understanding of what is actually going on. I had one user try to manually configure GRE interfaces on the Cisco side because that is how they thought WCCP worked. Another policy routed TCP to the proxy and didn't quite get why some connections where hanging (ICMP doesn't make it to the proxy, so PMTU is guaranteed to break without blackhole detection in one or more participants end-nodes/proxy.) Combined with all of the crazy IOS related bugs and crackery that is going on and I'm not really surprised the average joe doesn't have much luck. :) I reckon what would be really, really useful is a writeup of all of the related technologies involved in all parts of transparent interception, including a writeup on what WCCPv2 actually is and how it works; what the various interception options are and do (especially TPROXY4, which AFAICT is severely lacking in -actual- documentation about what it is, how it works and how to code for it) so there is at least a small chance that someone with a bit of clue can easily figure all the pieces out and debug stuff. I also see people doing TPROXY4/Linux hackery involving -bridging- proxies instead of routed/WCCPv2 proxies. That is another fun one. Finally, figuring out how to tie all of that junk into a cache hierarchy is also hilariously amusing to get right. Just for the record, the kernel and iptables binary shipping with the latest Debian unstable supports TPROXY4 fine. I didn't have to recompile my kernel or anything - I just had to tweak a few things (disable pmtu, for example) and add some iptables rules. Oh, and compile Squid right. 2c, Adrian
[squid-users] Updated CentOS/Squid/Tproxy Transparency steps.
Some assumptions: 1) You are using a Cisco Router to redirect traffic to the squid box via WCCP 2) 12.4(15)T8 or higher IOS on the router 3) In my setups, the squid box is always Layer 2 adjacent to the Cisco router, either through a dedicated interface, or a sub-interface. 4) The ability to compile and install a Linux kernel. Please note that in these steps, I am NOT using a redhat kernel, nor am I using the RedHat method of building a kernel. 5) Some steps outlined here can be achieved through several different means, follow the steps exactly before emailing me or the list, as I have tested other methods, and they don't always work (case in point: GRE tunnel interface creation.) 6) This setup assumes a separate WCCP service group for each direction of the HTTP connection, this is not needed, but makes the setup more scalable. If you choose to do it a different way, then YMMV. In the kernel build specific steps, I actually include possibly to much information, as well as tell you to enable things that are not always needed for TPROXY related functionality, or never related to TPROXY functionality. I included them because they fit more environments, and thus less time wasted by people asking me questions, not that I mind but I don't have enough time to answer all the emails I get. I tried to prepare this information out without errors, if the steps don't work, email me with the details of where you had problems so that I can adjust the steps below. At the end the steps below are some common things to watch for in the steps that can cause the setup not to work. Steps 1) Install CentOS 5.3, make sure you install nothing other than the base packages, and trim even those down. I tend to install specific packages from the distro later. Note: I suggest that you make separate partition(s) for where squid will actually store its caches. Later mount these partitions with specific options (like noatime) that will help increase performance. 2) In the initial ncurses-based setup screen, turn off services that you don't need, and turn off selinux compeletely. 3) After install and initial bootup and configuration, run yum update to update the system for fixes, etc. Then reboot. 4) After step 2, issue this yum command: yum install libcap libcap-devel gcc gcc-c++ bison flex yacc autoconf automake ncurses ncurses-devel rpm-devel libpcap tcpdump Note: let it install other dependency packages. The command above installs compiles, utilities, etc. 5) Download iptables-1.4.3.2 from netfilter.org 6) Download kernel 2.6.30 from kernel.org 7) Download squid-3.1.0.8 from squid.org 8) Decompress the kernel source, I decompress it to /usr/src/, although I have read all over the place that this is a bad thing to do. The location really does not have to be /usr/src/ 9) Go into the kernel source directory, issue the following command: cp /boot/config-2.6.18-128.1.14.el5 ./RH-config-boxed.config 10) Issue this command: make menuconfig 11) When the ncurses-based kernel config screen loads, select the Load an Alternate Configuration File and type in the full path to the RH-config-boxed.config. This will load the current kernel config, and there may be some errors, all of which can be ignored. 12) Configure the kernel as you normally would, but be sure to enable the following: In Networking support - Networking options Enable (not as modules): Packet socket Packet socket: mmapped IO TCP/IP networking IP: advanced router IP: policy routing Enable (as modules): IP: tunneling Enable (not as modules): IP: GRE tunnels over IP IP: broadcast GRE over IP Network packet filtering framework (Netfilter) In Networking support - Networking options - Network packet filtering framework (Netfilter) Enable (not as modules): Advanced netfilter configuration In Networking support - Networking options - Network packet filtering framework (Netfilter) - Core Netfilter Configuration Enable (as modules): Netfilter connection tracking support Enable (not as modules): Connection tracking security mark support Connection tracking events Enable (as modules): Connection tracking netlink interface Transparent proxying support (EXPERIMENTAL) Netfilter Xtables support (required for ip_tables) CONNMARK target support MARK target support TPROXY target support (EXPERIMENTAL) connmark connection mark match support conntrack connection tracking match support mark match support socket match support (EXPERIMENTAL) state match support In Networking support - Networking options - Network packet filtering framework (Netfilter) - IP: Netfilter Configuration Enable (as modules): IPv4 connection tracking support (required for NAT) IP tables support (required for filtering/masq/NAT) Full NAT MASQUERADE target support REDIRECT target support Packet mangling 13) After setting the above options, and any other items you want, exit out of the kernel config, saving your changes. It will save the kernel compile config to RH-config-boxed.config
