Hello, I''m experimenting with TPROXY, and I can''t seem to make it work right. And looking at the generated iptables (iptables-save output), I don''t understand how it could work. Basically, I have the same configuration as at http://www.shorewall.net/Shorewall_Squid_Usage.html#TPROXY except that I have TPROXY(1,3128) $IF_OFFICE:10.10.10.4 0.0.0.0/0 tcp 80 In the tcrules files (to test it from a single IP address for now). And in squid.conf http_port 3128 tproxy>From what I understandIf IP a.b.c.d wants to do an HTTP request to w.x.y.z going through our shorewall with transparent squid, we see a packet: SYN a.b.c.d:p -> w.x.y.z:80 arrives on "eth0" It is "mark"ed as "1" and sent to the local squid listening socket. packets marked with "1" are not /forwarded/ (ip rule with fwmark 1 to a table with "local" destination for everything). Now, squid sends the reply back to a.b.c.d:p SYN-ACK w.x.y.z:80 -> a.b.c.d:p on eth0 And it sends a SYN a.b.c.d:q -> w.x.y.z:80 on eth1 Which may be SNATed. When the reply goes back from w.x.y.z SYN-ACK w.x.y.z:80 -> a.b.c.d:q I can''t see anything in shorewall that makes it go to sguid and not be forwarded to a.b.c.d:q The tproxy doc in the Linux kernel sources: /usr/share/doc/linux-doc-3.2/Documentation/networking/tproxy.txt.gz have a # iptables -t mangle -N DIVERT # iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT # iptables -t mangle -A DIVERT -j MARK --set-mark 1 # iptables -t mangle -A DIVERT -j ACCEPT for that (if I understand correctly, "the -m socket" matches the reply packet and make it non-forwarded. AFAICT shorewall doesn''t do that (at least 4.4.11.6 on debian squeeze), and indeed I observe squid not getting its answer, and a.b.c.d getting an unexpected SYN ACK. Where I''m confused is that this has to have been tested, so there must be something wrong in my reasoning and/or observations. Also, in mangle PREROUTING, we have: -A tcpre -s 10.10.10.4/32 -i vlan2 -p tcp -m tcp --dport 80 -j TPROXY --on-port 3128 --on-ip 0.0.0.0 --tproxy-mark 0x1/0xffffffff Wouldn''t that apply to any packet with dport 80, even those not part of a HTTP connection? For instance a SYN-ACK 10.10.10.4:22 -> a.b.c.d:80 and cause problem in that case? Shouldn''t we use CONNMARK in this case? Thanks, Stephane ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 05/09/2012 07:21 AM, Stephane Chazelas wrote:> Hello, > > I''m experimenting with TPROXY, and I can''t seem to make it work > right. > > And looking at the generated iptables (iptables-save output), I > don''t understand how it could work. > > Basically, I have the same configuration as at > http://www.shorewall.net/Shorewall_Squid_Usage.html#TPROXY > > except that I have > TPROXY(1,3128) $IF_OFFICE:10.10.10.4 0.0.0.0/0 tcp 80 > > In the tcrules files (to test it from a single IP address for > now). > > And in squid.conf > http_port 3128 tproxy > >> From what I understand > > If IP a.b.c.d wants to do an HTTP request to w.x.y.z going > through our shorewall with transparent squid, we see a packet: > > SYN a.b.c.d:p -> w.x.y.z:80 arrives on "eth0" > > It is "mark"ed as "1" and sent to the local squid listening socket. > > packets marked with "1" are not /forwarded/ (ip rule with > fwmark 1 to a table with "local" destination for everything). > > Now, squid sends the reply back to a.b.c.d:p > > SYN-ACK w.x.y.z:80 -> a.b.c.d:p on eth0 > > And it sends a > > SYN a.b.c.d:q -> w.x.y.z:80 on eth1 > > Which may be SNATed. > > When the reply goes back from w.x.y.z > > SYN-ACK w.x.y.z:80 -> a.b.c.d:q > > I can''t see anything in shorewall that makes it go to sguid and > not be forwarded to a.b.c.d:q > > The tproxy doc in the Linux kernel sources: > /usr/share/doc/linux-doc-3.2/Documentation/networking/tproxy.txt.gz > > have a > # iptables -t mangle -N DIVERT > # iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT > # iptables -t mangle -A DIVERT -j MARK --set-mark 1 > # iptables -t mangle -A DIVERT -j ACCEPT > > for that (if I understand correctly, "the -m socket" matches the > reply packet and make it non-forwarded. > > AFAICT shorewall doesn''t do that (at least 4.4.11.6 on debian > squeeze), and indeed I observe squid not getting its answer, and > a.b.c.d getting an unexpected SYN ACK. > > Where I''m confused is that this has to have been tested, so > there must be something wrong in my reasoning and/or > observations. >At the time that TPROXY was implemented in Shorewall, the Squid TPROXY documentation did not include the advice about DIVERT. As I wasn''t running Squid3 at that time (and still don''t), the code was tested only to the extent that it generated the same rules that the Squid documentation provided The current thread on this list with the subject "Shorewall, TPROXY, Transparent Squid and Multiples ISP" just brought this problem to my attention. Shorewall 4.5.3 will support a DIVERT action in the tcrules file to create the DIVERT chain and branch to it using the "-m socket'' match. In the meantime, the DIVERT chain and jump to that chain can be created in the ''start'' extension script as shown in the other thread. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 05/09/2012 09:14 AM, Tom Eastep wrote:> At the time that TPROXY was implemented in Shorewall, the Squid TPROXY > documentation did not include the advice about DIVERT. As I wasn''t > running Squid3 at that time (and still don''t), the code was tested only > to the extent that it generated the same rules that the Squid > documentation provided > > The current thread on this list with the subject "Shorewall, TPROXY, > Transparent Squid and Multiples ISP" just brought this problem to my > attention. Shorewall 4.5.3 will support a DIVERT action in the tcrules > file to create the DIVERT chain and branch to it using the "-m socket'' > match.This is proving to require a more extensive change than I''m willing to make at this point in the 4.5.3 release cycle. So I''m going to defer the TPROXY rework until 4.5.4. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/