Accelerator mode, select peer form request destination ip (feature request?)

[Justo Alonso]

Hi !
    I'm trying to setup an apache & squid in accelerator mode configuration.

   I have the apache in Listen *:80 .. with many virtualhosts and many
namevirtualhosts (namevirtualhost *:80 too). I have the squid at
http_port 8080.

   And now I want squid to make the request to the apache to same
destination ip that client requested .... example

client request -> squid 10.0.0.1:8080 -> apache 10.0.0.1:80
client rquest -> squid 10.0.0.2:8080 -> apache 10.0.0.2:80 ....

I want to configure one http_port and a cache_peer by virtualhost ...
I need a global configuration ... all client requests redirected to
the same destination ip to diferent port.

Reading the documentation I can't find about this, and I'm trying to
add new option to cache_peer (same-dst-ip) .. if this boolean option
is set then this cache_peer don't get the host and get the destination
ip from request ... and open a connection to it on cache_peer port.

What think you about this ?? comments ?? Maybe should I send this
question to squid-dev list ?

thanks in advance,
justo

[Amos Jeffries-2]

You seem to have mixed up your view of the information passed versus the
actions taken and what virtual hosting actually does.

On Mon, 2 Nov 2009 21:22:33 +0100, Justo Alonso <justo.alonso@...>
wrote:
> Hi !
>     I'm trying to setup an apache & squid in accelerator mode
> configuration.

You start by indicating that you are trying to configure a reverse proxy.

>
>    I have the apache in Listen *:80 .. with many virtualhosts and many
> namevirtualhosts (namevirtualhost *:80 too). I have the squid at
> http_port 8080.

Reverse-proxy do not work this way. I wonder if the many other meanings of
the word "accelerator" have confused you.

A reverse proxy is software talking to the client software pretending to
be a web server, but sourcing the replies over network from a real web
server elsewhere.

The client will type http://example.com/ into their browser address bar.
In your config that will take them directly to the apache.

To make a reverse-proxy useful you move apache to some other port and
place the proxy listening on port 80. Which then is configured to source
the data from apache on its other port.

So that when clients enter http://example.com/ into their browser address
bar it will take them directly to the proxy.

>
>    And now I want squid to make the request to the apache to same
> destination ip that client requested .... example
>
> client request -> squid 10.0.0.1:8080 -> apache 10.0.0.1:80
> client rquest -> squid 10.0.0.2:8080 -> apache 10.0.0.2:80 ....

You then indicate that you want Squid to make actual physical TCP links to
different Apache. based on what the receiving Squid IP was. This has
nothing to do with virtual hosting.

This requirement is met by adding a cache_peer directive for each back-end
Apache server. Then using cache_peer_access and ACL of the "myip" type
limiting the requests passed to each peer to be those received on the
matching input IP.

>
> I want to configure one http_port and a cache_peer by virtualhost ...
> I need a global configuration ... all client requests redirected to
> the same destination ip to diferent port.

You then say that all these apache listening addresses are actually the
same machine.

cache_peer is designed to be a TCL link to a _single_ backend software.
Virtual hosting has nothing to do with it. This is so low down as to be
almost wire-level stuff.


Reading between the lines .... I guess that you actually want Squid to
pass the right information such that incoming requests are handled by the
right virtualhost inside Apache correct?


That is done correctly by having the right accelerator setup. Using
http_port settings vhost, vport and defaultsite to alter the Host: header
(virtualhost name) as applicable. The cache_peer forcedomain= option is
also available, but that is for force-sending only a single virtualhost
name to the Apache, opposite of what you want.

By setting squid to listen on port 80 the clients software will be sending
Squid the correct Host: header information as needed by apache to find the
virtualhost.

All you need to do is configure "http_port 80 accel vhost" and one single
cache_peer line pointing at Apache, and it works.
http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting

>
> Reading the documentation I can't find about this, and I'm trying to
> add new option to cache_peer (same-dst-ip) .. if this boolean option
> is set then this cache_peer don't get the host and get the destination
> ip from request ... and open a connection to it on cache_peer port.
>
> What think you about this ?? comments ?? Maybe should I send this
> question to squid-dev list ?
>
> thanks in advance,
> justo

Your description of 'same-dst-ip' seems to me to be you attempting to make
squid a semi-transparent proxy instead of accelerator by opening security
vulnerability CVE-2009-0801 for reverse-proxy (accelerator) configurations
as well as interception-proxy configurations. This is a very bad idea.

If you find the basic accelerator config I outlined above still is not
workable for your specific needs then please get back to me on the details
of why you think this option might still be needed. I'm working on fixes
for the CVE and would like to make sure any such option fits with the
solution and does not open new vulnerabilities.

Amos

[Henrik Nordstrom-5]

tis 2009-11-03 klockan 11:26 +1300 skrev Amos Jeffries:

> This requirement is met by adding a cache_peer directive for each back-end
> Apache server. Then using cache_peer_access and ACL of the "myip" type
> limiting the requests passed to each peer to be those received on the
> matching input IP.

But beware of cache pollution attacks when doing this approach.

The urlgroup= http_port option of squid-2 allows the cache pollution
problem to be solved by dividing the cache per http_port (urlgroup), but
this is not yet available in Squid-3.

Regards
Henrik

[Justo Alonso]

Hi Amos !

On Mon, Nov 2, 2009 at 11:26 PM, Amos Jeffries <squid3@...> wrote:

>
> You seem to have mixed up your view of the information passed versus the
> actions taken and what virtual hosting actually does.
>
> On Mon, 2 Nov 2009 21:22:33 +0100, Justo Alonso <justo.alonso@...>
> wrote:
>> Hi !
>>     I'm trying to setup an apache & squid in accelerator mode
>> configuration.
>
> You start by indicating that you are trying to configure a reverse proxy.
>
>>
>>    I have the apache in Listen *:80 .. with many virtualhosts and many
>> namevirtualhosts (namevirtualhost *:80 too). I have the squid at
>> http_port 8080.
>
> Reverse-proxy do not work this way. I wonder if the many other meanings of
> the word "accelerator" have confused you.
>
> A reverse proxy is software talking to the client software pretending to
> be a web server, but sourcing the replies over network from a real web
> server elsewhere.
>
> The client will type http://example.com/ into their browser address bar.
> In your config that will take them directly to the apache.
>
> To make a reverse-proxy useful you move apache to some other port and
> place the proxy listening on port 80. Which then is configured to source
> the data from apache on its other port.
>
> So that when clients enter http://example.com/ into their browser address
> bar it will take them directly to the proxy.

It's ok .. the port it's not important. In my configuration, the
firewall nat the 80 port to 8080 in the sites with reverse proxy:

client to www.example.com:80 -> fw nat www.internal.example.com:8080
-> squid cache in 8080 -> apache in 80

So, the client get http://www.example.com in your browser and the
squid receive the request in 8080 port .. The port it's not important.

>
>>
>>    And now I want squid to make the request to the apache to same
>> destination ip that client requested .... example
>>
>> client request -> squid 10.0.0.1:8080 -> apache 10.0.0.1:80
>> client rquest -> squid 10.0.0.2:8080 -> apache 10.0.0.2:80 ....
>
> You then indicate that you want Squid to make actual physical TCP links to
> different Apache. based on what the receiving Squid IP was. This has
> nothing to do with virtual hosting.

Yes, if you have namevirtualhosting. If you have many virtualhost and
many namevirtualhost (the machine with apache and squid has many
interface aliases)

With namevirtualhost and virtualhost apache selects the correct
configuration for the site with the destination ip and port and the
servername/serveralias directives

>
> This requirement is met by adding a cache_peer directive for each back-end
> Apache server. Then using cache_peer_access and ACL of the "myip" type
> limiting the requests passed to each peer to be those received on the
> matching input IP.

Yes, but this makes the configuration very complex. You need to
configure one cache_peer by interface and acls for cache_peer .. if
you have about 150 interfaces per machine .. the posibility to make a
mistake it's higher !

>
>>
>> I want to configure one http_port and a cache_peer by virtualhost ...
>> I need a global configuration ... all client requests redirected to
>> the same destination ip to diferent port.
>
> You then say that all these apache listening addresses are actually the
> same machine.
>
> cache_peer is designed to be a TCL link to a _single_ backend software.
> Virtual hosting has nothing to do with it. This is so low down as to be
> almost wire-level stuff.

ummm ... but .. if the same-dst-ip option is defined on this
cache_peer, we can change the cache_peer configuration or create a
dynamic cache_peer for attend this request setting the host of this
cache_peer to the destination ip (the ip that the squid receive the
request)

>
>
> Reading between the lines .... I guess that you actually want Squid to
> pass the right information such that incoming requests are handled by the
> right virtualhost inside Apache correct?
>
>
> That is done correctly by having the right accelerator setup. Using
> http_port settings vhost, vport and defaultsite to alter the Host: header
> (virtualhost name) as applicable. The cache_peer forcedomain= option is
> also available, but that is for force-sending only a single virtualhost
> name to the Apache, opposite of what you want.
>
> By setting squid to listen on port 80 the clients software will be sending
> Squid the correct Host: header information as needed by apache to find the
> virtualhost.
>
> All you need to do is configure "http_port 80 accel vhost" and one single
> cache_peer line pointing at Apache, and it works.
> http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting
>

But my apache listen on diferent interfaces and have namevirtualhost
configuration, then one cache_peer don't work fine.

>
>>
>> Reading the documentation I can't find about this, and I'm trying to
>> add new option to cache_peer (same-dst-ip) .. if this boolean option
>> is set then this cache_peer don't get the host and get the destination
>> ip from request ... and open a connection to it on cache_peer port.
>>
>> What think you about this ?? comments ?? Maybe should I send this
>> question to squid-dev list ?
>>
>> thanks in advance,
>> justo
>
>
> Your description of 'same-dst-ip' seems to me to be you attempting to make
> squid a semi-transparent proxy instead of accelerator by opening security
> vulnerability CVE-2009-0801 for reverse-proxy (accelerator) configurations
> as well as interception-proxy configurations. This is a very bad idea.

The CVE-2009-0801 doesn't apply with this configuration ... It's the
same case as if the client connects directly to the web server. Squid
doesn't selects the cache_peer by Host header .. selects by
destination ip of the request.

>
> If you find the basic accelerator config I outlined above still is not
> workable for your specific needs then please get back to me on the details
> of why you think this option might still be needed. I'm working on fixes
> for the CVE and would like to make sure any such option fits with the
> solution and does not open new vulnerabilities.
>
> Amos
>
>

justo

[Amos Jeffries-2]

Justo Alonso wrote:

> Hi Amos !
>
> On Mon, Nov 2, 2009 at 11:26 PM, Amos Jeffries <squid3@...> wrote:
>> You seem to have mixed up your view of the information passed versus the
>> actions taken and what virtual hosting actually does.
>>
>> On Mon, 2 Nov 2009 21:22:33 +0100, Justo Alonso <justo.alonso@...>
>> wrote:
>>> Hi !
>>>     I'm trying to setup an apache & squid in accelerator mode
>>> configuration.
>> You start by indicating that you are trying to configure a reverse proxy.
>>
>>>    I have the apache in Listen *:80 .. with many virtualhosts and many
>>> namevirtualhosts (namevirtualhost *:80 too). I have the squid at
>>> http_port 8080.
>> Reverse-proxy do not work this way. I wonder if the many other meanings of
>> the word "accelerator" have confused you.
>>
>> A reverse proxy is software talking to the client software pretending to
>> be a web server, but sourcing the replies over network from a real web
>> server elsewhere.
>>
>> The client will type http://example.com/ into their browser address bar.
>> In your config that will take them directly to the apache.
>>
>> To make a reverse-proxy useful you move apache to some other port and
>> place the proxy listening on port 80. Which then is configured to source
>> the data from apache on its other port.
>>
>> So that when clients enter http://example.com/ into their browser address
>> bar it will take them directly to the proxy.
>
> It's ok .. the port it's not important. In my configuration, the
> firewall nat the 80 port to 8080 in the sites with reverse proxy:
>
> client to www.example.com:80 -> fw nat www.internal.example.com:8080
> -> squid cache in 8080 -> apache in 80

Alert!! your Squid is now a NAT interception proxy.

IP addresses as viewed by Squid are always:
   src:   client.IP with random port
   dst:   www.internal.example.com with port 8080

>
> So, the client get http://www.example.com in your browser and the
> squid receive the request in 8080 port .. The port it's not important.
>
>>>    And now I want squid to make the request to the apache to same
>>> destination ip that client requested .... example
>>>
>>> client request -> squid 10.0.0.1:8080 -> apache 10.0.0.1:80
>>> client rquest -> squid 10.0.0.2:8080 -> apache 10.0.0.2:80 ....
>> You then indicate that you want Squid to make actual physical TCP links to
>> different Apache. based on what the receiving Squid IP was. This has
>> nothing to do with virtual hosting.
>
> Yes, if you have namevirtualhosting. If you have many virtualhost and
> many namevirtualhost (the machine with apache and squid has many
> interface aliases)
>
> With namevirtualhost and virtualhost apache selects the correct
> configuration for the site with the destination ip and port and the
> servername/serveralias directives

Due to NAT above destination IP is erased and replaced with a constant
value.

>
>> This requirement is met by adding a cache_peer directive for each back-end
>> Apache server. Then using cache_peer_access and ACL of the "myip" type
>> limiting the requests passed to each peer to be those received on the
>> matching input IP.
>
> Yes, but this makes the configuration very complex. You need to
> configure one cache_peer by interface and acls for cache_peer .. if
> you have about 150 interfaces per machine .. the posibility to make a
> mistake it's higher !
>
>>> I want to configure one http_port and a cache_peer by virtualhost ...
>>> I need a global configuration ... all client requests redirected to
>>> the same destination ip to diferent port.
>> You then say that all these apache listening addresses are actually the
>> same machine.
>>
>> cache_peer is designed to be a TCL link to a _single_ backend software.
>> Virtual hosting has nothing to do with it. This is so low down as to be
>> almost wire-level stuff.
>
> ummm ... but .. if the same-dst-ip option is defined on this
> cache_peer, we can change the cache_peer configuration or create a
> dynamic cache_peer for attend this request setting the host of this
> cache_peer to the destination ip (the ip that the squid receive the
> request)
>
>>
>> Reading between the lines .... I guess that you actually want Squid to
>> pass the right information such that incoming requests are handled by the
>> right virtualhost inside Apache correct?
>>
>>
>> That is done correctly by having the right accelerator setup. Using
>> http_port settings vhost, vport and defaultsite to alter the Host: header
>> (virtualhost name) as applicable. The cache_peer forcedomain= option is
>> also available, but that is for force-sending only a single virtualhost
>> name to the Apache, opposite of what you want.
>>
>> By setting squid to listen on port 80 the clients software will be sending
>> Squid the correct Host: header information as needed by apache to find the
>> virtualhost.
>>
>> All you need to do is configure "http_port 80 accel vhost" and one single
>> cache_peer line pointing at Apache, and it works.
>> http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting
>>
>
> But my apache listen on diferent interfaces and have namevirtualhost
> configuration, then one cache_peer don't work fine.
>
>>> Reading the documentation I can't find about this, and I'm trying to
>>> add new option to cache_peer (same-dst-ip) .. if this boolean option
>>> is set then this cache_peer don't get the host and get the destination
>>> ip from request ... and open a connection to it on cache_peer port.
>>>
>>> What think you about this ?? comments ?? Maybe should I send this
>>> question to squid-dev list ?
>>>
>>> thanks in advance,
>>> justo
>>
>> Your description of 'same-dst-ip' seems to me to be you attempting to make
>> squid a semi-transparent proxy instead of accelerator by opening security
>> vulnerability CVE-2009-0801 for reverse-proxy (accelerator) configurations
>> as well as interception-proxy configurations. This is a very bad idea.
>
> The CVE-2009-0801 doesn't apply with this configuration ... It's the

Client can connect to any of Squid IPs and forge Host: info of any
apache IP. In your case it just has very limited impact.
With dst-ip option that will make squid ignore cache_peer explicit
destination and loop back on itself.

> same case as if the client connects directly to the web server. Squid
> doesn't selects the cache_peer by Host header .. selects by
> destination ip of the request.

Above you said NAT was involved.
  "client to www.example.com:80 -> fw nat www.internal.example.com:8080"

Therefore destination IP will _always_ be IP www.internal.example.com
because NAT erased the real destination IP and replaced it.

This breaks your option as described for accelerators.

>> If you find the basic accelerator config I outlined above still is not
>> workable for your specific needs then please get back to me on the details
>> of why you think this option might still be needed. I'm working on fixes
>> for the CVE and would like to make sure any such option fits with the
>> solution and does not open new vulnerabilities.
>>
>> Amos
>>
>>
>
> justo

Given that your Squid is really a NAT interception proxy you can drop
the pretense of configuring it as an accelerator...


   http_port 8080 transparent

   acl toapaches dst 10.0.0.0/8
   http_access allow toapaches

Will do exactly what you are asking to be done. Squid will decode the
Host: header, look it up in DNS and send the request to the relevant
server IP and port as encoded by the client.

Now all you need do is make the DNS resolver tell Squid what internal
apache IP for all the namevirtualhosts that apache services (DNS views).
You can even have multiple IPs returned for each name to make seamless
failover between apaches when some go down.


Amos
--
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
   Current Beta Squid 3.1.0.14

[Justo Alonso]

On Tue, Nov 3, 2009 at 12:12 PM, Amos Jeffries <squid3@...> wrote:

> Justo Alonso wrote:
>>
>> Hi Amos !
>>
>> On Mon, Nov 2, 2009 at 11:26 PM, Amos Jeffries <squid3@...>
>> wrote:
>>>
>>> You seem to have mixed up your view of the information passed versus the
>>> actions taken and what virtual hosting actually does.
>>>
>>> On Mon, 2 Nov 2009 21:22:33 +0100, Justo Alonso <justo.alonso@...>
>>> wrote:
>>>>
>>>> Hi !
>>>>    I'm trying to setup an apache & squid in accelerator mode
>>>> configuration.
>>>
>>> You start by indicating that you are trying to configure a reverse proxy.
>>>
>>>>   I have the apache in Listen *:80 .. with many virtualhosts and many
>>>> namevirtualhosts (namevirtualhost *:80 too). I have the squid at
>>>> http_port 8080.
>>>
>>> Reverse-proxy do not work this way. I wonder if the many other meanings
>>> of
>>> the word "accelerator" have confused you.
>>>
>>> A reverse proxy is software talking to the client software pretending to
>>> be a web server, but sourcing the replies over network from a real web
>>> server elsewhere.
>>>
>>> The client will type http://example.com/ into their browser address bar.
>>> In your config that will take them directly to the apache.
>>>
>>> To make a reverse-proxy useful you move apache to some other port and
>>> place the proxy listening on port 80. Which then is configured to source
>>> the data from apache on its other port.
>>>
>>> So that when clients enter http://example.com/ into their browser address
>>> bar it will take them directly to the proxy.
>>
>> It's ok .. the port it's not important. In my configuration, the
>> firewall nat the 80 port to 8080 in the sites with reverse proxy:
>>
>> client to www.example.com:80 -> fw nat www.internal.example.com:8080
>> -> squid cache in 8080 -> apache in 80
>
> Alert!! your Squid is now a NAT interception proxy.
>
> IP addresses as viewed by Squid are always:
>  src:   client.IP with random port
>  dst:   www.internal.example.com with port 8080

???

>
>>
>> So, the client get http://www.example.com in your browser and the
>> squid receive the request in 8080 port .. The port it's not important.
>>
>>>>   And now I want squid to make the request to the apache to same
>>>> destination ip that client requested .... example
>>>>
>>>> client request -> squid 10.0.0.1:8080 -> apache 10.0.0.1:80
>>>> client rquest -> squid 10.0.0.2:8080 -> apache 10.0.0.2:80 ....
>>>
>>> You then indicate that you want Squid to make actual physical TCP links
>>> to
>>> different Apache. based on what the receiving Squid IP was. This has
>>> nothing to do with virtual hosting.
>>
>> Yes, if you have namevirtualhosting. If you have many virtualhost and
>> many namevirtualhost (the machine with apache and squid has many
>> interface aliases)
>>
>> With namevirtualhost and virtualhost apache selects the correct
>> configuration for the site with the destination ip and port and the
>> servername/serveralias directives
>
> Due to NAT above destination IP is erased and replaced with a constant
> value.
>
>>
>>> This requirement is met by adding a cache_peer directive for each
>>> back-end
>>> Apache server. Then using cache_peer_access and ACL of the "myip" type
>>> limiting the requests passed to each peer to be those received on the
>>> matching input IP.
>>
>> Yes, but this makes the configuration very complex. You need to
>> configure one cache_peer by interface and acls for cache_peer .. if
>> you have about 150 interfaces per machine .. the posibility to make a
>> mistake it's higher !
>>
>>>> I want to configure one http_port and a cache_peer by virtualhost ...
>>>> I need a global configuration ... all client requests redirected to
>>>> the same destination ip to diferent port.
>>>
>>> You then say that all these apache listening addresses are actually the
>>> same machine.
>>>
>>> cache_peer is designed to be a TCL link to a _single_ backend software.
>>> Virtual hosting has nothing to do with it. This is so low down as to be
>>> almost wire-level stuff.
>>
>> ummm ... but .. if the same-dst-ip option is defined on this
>> cache_peer, we can change the cache_peer configuration or create a
>> dynamic cache_peer for attend this request setting the host of this
>> cache_peer to the destination ip (the ip that the squid receive the
>> request)
>>
>>>
>>> Reading between the lines .... I guess that you actually want Squid to
>>> pass the right information such that incoming requests are handled by the
>>> right virtualhost inside Apache correct?
>>>
>>>
>>> That is done correctly by having the right accelerator setup. Using
>>> http_port settings vhost, vport and defaultsite to alter the Host: header
>>> (virtualhost name) as applicable. The cache_peer forcedomain= option is
>>> also available, but that is for force-sending only a single virtualhost
>>> name to the Apache, opposite of what you want.
>>>
>>> By setting squid to listen on port 80 the clients software will be
>>> sending
>>> Squid the correct Host: header information as needed by apache to find
>>> the
>>> virtualhost.
>>>
>>> All you need to do is configure "http_port 80 accel vhost" and one single
>>> cache_peer line pointing at Apache, and it works.
>>> http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting
>>>
>>
>> But my apache listen on diferent interfaces and have namevirtualhost
>> configuration, then one cache_peer don't work fine.
>>
>>>> Reading the documentation I can't find about this, and I'm trying to
>>>> add new option to cache_peer (same-dst-ip) .. if this boolean option
>>>> is set then this cache_peer don't get the host and get the destination
>>>> ip from request ... and open a connection to it on cache_peer port.
>>>>
>>>> What think you about this ?? comments ?? Maybe should I send this
>>>> question to squid-dev list ?
>>>>
>>>> thanks in advance,
>>>> justo
>>>
>>> Your description of 'same-dst-ip' seems to me to be you attempting to
>>> make
>>> squid a semi-transparent proxy instead of accelerator by opening security
>>> vulnerability CVE-2009-0801 for reverse-proxy (accelerator)
>>> configurations
>>> as well as interception-proxy configurations. This is a very bad idea.
>>
>> The CVE-2009-0801 doesn't apply with this configuration ... It's the
>
> Client can connect to any of Squid IPs and forge Host: info of any apache
> IP. In your case it just has very limited impact.
> With dst-ip option that will make squid ignore cache_peer explicit
> destination and loop back on itself.
>
>> same case as if the client connects directly to the web server. Squid
>> doesn't selects the cache_peer by Host header .. selects by
>> destination ip of the request.
>
> Above you said NAT was involved.
>  "client to www.example.com:80 -> fw nat www.internal.example.com:8080"
>
> Therefore destination IP will _always_ be IP www.internal.example.com
> because NAT erased the real destination IP and replaced it.
>
> This breaks your option as described for accelerators.
>
>>> If you find the basic accelerator config I outlined above still is not
>>> workable for your specific needs then please get back to me on the
>>> details
>>> of why you think this option might still be needed. I'm working on fixes
>>> for the CVE and would like to make sure any such option fits with the
>>> solution and does not open new vulnerabilities.
>>>
>>> Amos
>>>
>>>
>>
>> justo
>
> Given that your Squid is really a NAT interception proxy you can drop the
> pretense of configuring it as an accelerator...

no, I don't want a transparent proxy (nat interception) I want an
accelerator for the web servers (indepently of my infrastructure,
firewall and balancers, needs)

>
>
>  http_port 8080 transparent
>
>  acl toapaches dst 10.0.0.0/8
>  http_access allow toapaches
>
> Will do exactly what you are asking to be done. Squid will decode the Host:
> header, look it up in DNS and send the request to the relevant server IP and
> port as encoded by the client.
>
> Now all you need do is make the DNS resolver tell Squid what internal apache
> IP for all the namevirtualhosts that apache services (DNS views). You can
> even have multiple IPs returned for each name to make seamless failover
> between apaches when some go down.
>

This solution works, but then I need to configure the /etc/hosts (or
bind views) for the web servers farm .. more complex configuration ->
mixtake sure !

Finaly, what I need is a cache_peer selector by destination ip not by
Host header or dns lookup.

thanks in advance,

justo
>
> Amos
> --
> Please be using
>  Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
>  Current Beta Squid 3.1.0.14
>