[squid-users] tcp_outgoing_address and ICAP server

[Marcus Kool]

On 01/25/2015 01:12 PM, Amos Jeffries wrote:
> On 25/01/2015 11:43 p.m., Marcus Kool wrote:
>>
>>
>> On 01/24/2015 11:24 PM, Amos Jeffries wrote:
>>> On 25/01/2015 9:39 a.m., Marcus Kool wrote:
>>>>
>>>>
>>>> On 01/24/2015 10:15 AM, Amos Jeffries wrote:
>>>>> On 22/01/2015 10:11 a.m., Marcus Kool wrote:
>>>>>> I am using Squid 3.4.9 and have an issue with tcp_outgoing_address.
>>>>>>
>>>>>> The Squid server is connceted to the internet with multiple NICs and
>>>>>> uses
>>>>>>       tcp_outgoing_address a.public.IP.address
>>>>>>
>>>>>> and also want to use an ICAP server on the same host using
>>>>>>
>>>>>> icap_service  reqmod_urlfilterdb   reqmod_precache
>>>>>> icap://a.local.ip.address:1344/reqmod_icapd  bypass=off  routing=on
>>>>>> on-overload=wait ipv6=off
>>>>>>
>>>>>> It seems that Squid binds the connection to the ICAP server the
>>>>>> same way
>>>>>> it binds
>>>>>> connections to webservers using the rule with tcp_outgoing_address
>>>>>> and that it not desired nor workable.
>>>>>>
>>>>>> I tried
>>>>>>
>>>>>> acl myicaphost dst a.local.ip.address
>>>>>> tcp_outgoing_address a.public.IP.address !myicaphost
>>>>>>
>>>>>> but Squid issues the following errors:
>>>>>> 2015/01/21 21:58:32 kid1| WARNING: myicaphost ACL is used in context
>>>>>> without an HTTP request. Assuming mismatch.
>>>>>> 2015/01/21 21:58:32 kid1| commBind: Cannot bind socket FD 10 to
>>>>>> XX.XX.XX.XX: (99) Cannot assign requested address
>>>>>> 2015/01/21 21:58:32 kid1| essential ICAP service is down after an
>>>>>> options fetch failure: icap://XX.XX.XX.XX:1344/reqmod_icapd
>>>>>> [down,!opt]
>>>>>>
>>>>>> So the question is how to send web traffic over a specific NIC and
>>>>>> traffic to the ICAP server over an other (default?) NIC ?
>>>>>
>>>>>
>>>>> Please try the attached patch against Squid-3.4. It should make your
>>>>> config work.
>>>>>
>>>>> Amos
>>>>
>>>> Thank you for the patch.
>>>> It resolves 1 issue: there is no longer the warning
>>>>      WARNING: myicaphost ACL is used in context without an HTTP request.
>>>> Assuming mismatch.
>>>>
>>>> But the binding to the wrong NIC with the external IP still happens:
>>>>
>>>> 2015/01/24 17:19:48.027 kid1| Xaction.cc(133) openConnection:
>>>> Adaptation::Icap::OptXact opens connection to 10.10.0.6:1344
>>>> 2015/01/24 17:19:48.027 kid1| AsyncCall.cc(18) AsyncCall: The AsyncCall
>>>> Adaptation::Icap::Xaction::noteCommConnected constructed, this=0x1d9d7e0
>>>> [call53]
>>>> 2015/01/24 17:19:48.027 kid1| comm.cc(549) comm_openex: comm_openex:
>>>> Attempt open socket for: a.public.IP.address
>>>> 2015/01/24 17:19:48.027 kid1| comm.cc(590) comm_openex: comm_openex:
>>>> Opened socket local=a.public.IP.address remote=[::] FD 10 flags=1 :
>>>> family=2, type=1, protocol=6
>>>>
>>>> The firewall and routing was changed to allow traffic from the external
>>>> IP to
>>>> the internal IP so for us the urgency of the issue is low, but
>>>> the binding remains on the external IP despite the ACL saying not to
>>>> do it.
>>>
>>> Aha, conceptual problem.
>>>
>>> tcp_outgoing_address does not forbid things. There is no "allow/deny"
>>> action, just a set-IP action. It either sets the IP or it leaves it
>>> alone.
>>
>> Do you agree that the binding should not take place if a socket
>> is created with a destination address 'myicaphost' ?  The myicaphost is
>> 10.10.0.6 and the comm debug output above shows that the socket *is* bound.
>
> I cant agree because I dont know why it was binding.



The debug trace starts with:
Xaction.cc(133) openConnection: *Adaptation::Icap::OptXact* opens connection to 10.10.0.6:1344
and then
comm.cc(549) comm_openex: comm_openex: Attempt open socket for: *a.public.IP.address*
comm.cc(590) comm_openex: comm_openex:Opened socket local=*a.public.IP.address* remote=[::] FD 10 flags=1 : family=2, type=1, protocol=6

so I think it is clear that the socket to the ICAP server on 10.10.0.6
is bound to the NIC with an external IP address (not obeying the ACL).

I do not understand your statement "I dont know why it was binding".

 > Squid only uses
 > bind() if there is an explicit outgoing address required to be used.

Have you considered the possibility of a bug ?

>>> Your rule sets the IP when the dst is non-myicaphost. So what
>>> tcp_outgoing_address rule or OS level routing rule matches when it *is*
>>> myicaphost?
>>
>> Sorry, I don't know which routing decision is taken. All I know is that
>> the routing has been changed to make the connection to the ICAP server
>> work.
>>
>> I tried to show with the comm debug output that the connection to the
>> ICAP server (10.10.0.6) is still bound.  I replaced the public IP address
>> with "a.public.IP.address"  (I do not want to show the real IP but
>> it is definitely a public IP address).
>
> That obfuscation is fine, as long as its clear which IP is which.
>
> Perhapse a new debug trace after applying the patch will help resolve
> what the remaining problem is?

The debug trace that I posted was after applying the patch.

Marcus

> Amos
>
>