RE: squid3HEAD/TPROXY: interception log entries

> Amos-
>
> Thanks for your reply.
>
> Ok...I think I am understanding what you are saying. Now translating
> that to the situation at hand, I am not sure which route to take. I
> switched my setting for http_port to:
>
> http_port 3128 tproxy intercept disable-pmtu-discovery=always
>
> Which I understand doesn't address the issue you commented below about
> seperating intercept and tproxy traffic. If I take out the intercept, I
> get an error on the client.

What error on the client? That sounds like a bug. tproxy option AKAIK
should be independent. Maybe that is a bug that need fixing.

> I can't take tproxy out because that is what
> is being redirected via iptables rules and provides the client IP
> preservation to the remote site.

Agreed. My belief is that all you should need is the 'tproxy' option. If
thats failing, we need to find out why and fix it.

> I am confused as to how to seperate
> what with where given incoming WCCP traffic from the router.

I'll have to learn a little more about WCCP before I can answer that.

<snippet from followup>
> Ooops...I should have added the wccp2_server_info setting from
> squid.conf:
>
> wccp2_service_info 80 protocol=tcp flags=src_ip_hash priority=240
> ports=80
> wccp2_service_info 90 protocol=tcp flags=dst_ip_hash,ports_source
> priority=240 ports=80
</snippet>

>
> On the router I have wccp redirection rules as note on the squid wiki
> (note: the squid box is 10.48.33.2, clients are 10.48.1.0/24):
>
> ip wccp 80 redirect-list 121
> ip wccp 90 redirect-list 121
>
> interface FastEthernet0/1.1
> encapsulation dot1Q 1 native
> ip address 10.48.1.1 255.255.255.0
> ip helper-address 10.2.5.101
> ip wccp 80 redirect in
> ip wccp 90 redirect out
> !
> interface FastEthernet0/1.33
> encapsulation dot1Q 33
> ip address 10.48.33.1 255.255.255.0
> ip wccp redirect exclude in
>
>
> On the squid box I have TProxy and GRE related rules:
>
> TPROXY rules:
> -A PREROUTING -p tcp -m socket -j DIVERT
> -A PREROUTING -p tcp -m tcp --dport 80 -j TPROXY --on-port 3128 --on-ip
> 0.0.0.0 --tproxy-mark 0x1/0x1
> -A DIVERT -j MARK --set-mark 0x1
> -A DIVERT -j ACCEPT
>
> GRE and WCCP rules:
> -A INPUT -i gre0 -j ACCEPT
> -A INPUT -i gre0 -j ACCEPT
> -A INPUT -p gre -j ACCEPT
> -A INPUT -i eth0 -p gre -j ACCEPT
> -A FORWARD -j LocalFW
> -A LocalFW -i lo -j ACCEPT
> -A LocalFW -s 10.48.33.1/32 -p udp -m udp --dport 2048 -j ACCEPT
>
> Given what you are saying, am I to assuming correctly that my iptables
> rules would need to be adjusted? I understand in principle that I would
> need to create a redirection rule to squid on one port with TPROXY, and
> another redirection/NAT/DNAT rule to a squid port with intercept. Is
> this correct?

Only if you wanted to use both. The one TPROXY rule(s) as you have should
be enough.

>
> Thanks in advance for any help. I apologize if this discussion should be
> on the squid-users list, I assumed this list was the place given it was
> squid3HEAD.

It's okay. Either way.

What pops into my head here, without knowing the error your clients show
is a feeling that some bit of the overall flow is playing nasty.
Can you explain what the full traffic flow behavior is vs what should be?

Amos

>
> Nick
>
>
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Sent: Thursday, July 24, 2008 12:05 AM
> To: Ritter, Nicholas
> Cc: squid-dev_at_squid-cache.org
> Subject: RE: squid3HEAD/TPROXY: interception log entries
>
>>
>> I should have added some specifics...here are the log items in
>> cache.log:
>>
>> 2008/07/23 13:35:34| IPInterception.cc(171) NetfilterTransparent: NF
>> getsockopt(IP_TRANSPARENT) failed: (92) Protocol not available
>> 2008/07/23 13:36:37| IPInterception.cc(137) NetfilterInterception: NF
>> getsockopt(SO_ORIGINAL_DST) failed: (11) Resource temporarily
>> unavailable
>
> These can often be cleared up by correct use of 'intercept' and 'tproxy'
> options in http_port. The old 'transparent' option is deprecated and
> will to be backward-compatible, turn both on when often only one lookup
> type is needed on that port.
>
>>
>> ....and occasionally the client browser sees an error page from squid
>> stating a connection to the server failed, and the system returns a
>> "(99) Cannot assign requested address"
>
> This may be related to the above. If a tproxy receiving port is also
> used for DNAT/REDIRECT reception the tproxy kernel sub-system may not
> have records to correctly handle the apparent client address.
>
> The getsockopt() failures should not be a problem, just annoying.
> The assign failure, may be a problem. Squid will use its normal outgoing
> address I think in those cases. But I'm not certain on the network
> routing behavior when transparent squid become visible.
>
> To solve both the the above. I recommend using seperate http_port's to
> receive each type of traffic and setting specific 'intercept' or
> 'tproxy'
> options to match the expected traffic types.
>
> Amos
>
>
>
>
>
Received on Fri Jul 25 2008 - 02:43:19 MDT