Problem with IPv6 config when destination is dual-stacked (but everything works when destination is IPv4 or IPv6 only)

[Moser, Stefan (SIDB)]

Hi,

we are testing with squid, latest beta, in a dual-stack configuration:

squid is running on SLES 11. Server has 1 interface card only, configured with an IPv4 and IPv6 address, both running on standard 3128 port. Server has true, native IPv4 and IPv6 internet connectivity (no IPv6 tunnel broker, etc.). I have applied "IPv6 magic ACLs" as described in http://www.squid-cache.org/Doc/config/tcp_outgoing_address. Client (latest Internet Explorer and Firefox) talks to squid via IPv4 and IPv6 transport (that means, I enter an IPv4- or IPv6- address in browser´s connection settings).


Now, what DOES work, is the following:

1. IPv4 transport from browser to squid, squid can access an IPv4 only internet site (site has an A record only in DNS)
2. IPv4 transport from browser to squid, squid accesses an IPv6 only internet site (site has an AAAA record only in DNS)
3. IPv6 transport from browser to squid, squid accesses an IPv4 only internet site (site has an A record only in DNS)
4. IPv6 transport from browser to squid, squid accesses an IPv6 only internet site (site has an AAAA record only in DNS)

So far, so good, this IPv4 / IPv6 bridging obviously works.

Now, what does NOT work, is:

1. IPv4 transport from browser to squid, squid CANNOT access an IPv4/IPv6 internet site (that means, a site that has both A and AAAA in DNS and that is reachable via IPv6 and IPv4)
2. IPv6 transport from browser to squid, squid CANNOT access an IPv4/IPv6 internet site (that means, a site that has both A and AAAA in DNS and that is reachable via IPv6 and IPv4)

The cache log says (true IPv4 address removed for privacy reasons):

2009/10/28 15:59:46| commBind: Cannot bind socket FD 10 to <IPv4 address from my providers range>: (22) Invalid argument
2009/10/28 15:59:46| WARNING: Reset of FD 10 for <IPv4 address from my providers range>:failed to bind: (22) Invalid argument



Has everybody encountered the same problem?


With best regards,
Stefan Moser

[Amos Jeffries-2]

Moser, Stefan (SIDB) wrote:

> Hi,
>
> we are testing with squid, latest beta, in a dual-stack
> configuration:
>
> squid is running on SLES 11. Server has 1 interface card only,
> configured with an IPv4 and IPv6 address, both running on standard
> 3128 port. Server has true, native IPv4 and IPv6 internet
> connectivity (no IPv6 tunnel broker, etc.). I have applied "IPv6
> magic ACLs" as described in
> http://www.squid-cache.org/Doc/config/tcp_outgoing_address. Client
> (latest Internet Explorer and Firefox) talks to squid via IPv4 and
> IPv6 transport (that means, I enter an IPv4- or IPv6- address in
> browser´s connection settings).
>
>
> Now, what DOES work, is the following:
>
> 1. IPv4 transport from browser to squid, squid can access an IPv4
> only internet site (site has an A record only in DNS) 2. IPv4
> transport from browser to squid, squid accesses an IPv6 only internet
> site (site has an AAAA record only in DNS) 3. IPv6 transport from
> browser to squid, squid accesses an IPv4 only internet site (site has
> an A record only in DNS) 4. IPv6 transport from browser to squid,
> squid accesses an IPv6 only internet site (site has an AAAA record
> only in DNS)
>
> So far, so good, this IPv4 / IPv6 bridging obviously works.
>
> Now, what does NOT work, is:
>
> 1. IPv4 transport from browser to squid, squid CANNOT access an
> IPv4/IPv6 internet site (that means, a site that has both A and AAAA
> in DNS and that is reachable via IPv6 and IPv4) 2. IPv6 transport
> from browser to squid, squid CANNOT access an IPv4/IPv6 internet site
> (that means, a site that has both A and AAAA in DNS and that is
> reachable via IPv6 and IPv4)
>
> The cache log says (true IPv4 address removed for privacy reasons):
>
> 2009/10/28 15:59:46| commBind: Cannot bind socket FD 10 to <IPv4
> address from my providers range>: (22) Invalid argument 2009/10/28
> 15:59:46| WARNING: Reset of FD 10 for <IPv4 address from my providers
> range>:failed to bind: (22) Invalid argument
>
>
> Has everybody encountered the same problem?

Yes. The magic is not complete and has a point of failure.

FWIW, crossover works perfectly for me without tcp_outgoing_addr.

tcp_outgoing_addr is a "fast" category access control and cannot do the
dst lookup on its own. The destination IP address needs to be forced by
something earlier (http_access) for the magic to work.

I'm working on a few ways to fix this. But for now try adding
"http_access allow to_ipv6 !to_ipv6" to your config.

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

[Henrik Nordstrom-5]

fre 2009-10-30 klockan 13:33 +1300 skrev Amos Jeffries:

> Yes. The magic is not complete and has a point of failure.

Another idea. Why don't we address this in another way, making
tcp_outgoing_address select an IPv4+IPv6 pair of addresses?

I don't see how it can be made to work properly for hosts having both
IPv4+IPv6 otherwise considering that we may need to do failover from one
to the other.

Regards
Henrik

[Amos Jeffries-2]

Henrik Nordstrom wrote:

> fre 2009-10-30 klockan 13:33 +1300 skrev Amos Jeffries:
>
>> Yes. The magic is not complete and has a point of failure.
>
> Another idea. Why don't we address this in another way, making
> tcp_outgoing_address select an IPv4+IPv6 pair of addresses?
>
> I don't see how it can be made to work properly for hosts having both
> IPv4+IPv6 otherwise considering that we may need to do failover from one
> to the other.

I'm looking at a few approaches;
   having Squid kick off the DNS test earlier on in the processing. So
that the data may be available later as needed, but not hold up the
processing.

  Getting rid of the magic entirely by pre-filtering the outgoingAddr
ACL address against the dst IP type.

   making tcp_outgoing_addr a slow ACL type. that gets us around the
open bug and all the other custom ACL tests people keep trying to use there.

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

[Henrik Nordstrom-5]

fre 2009-10-30 klockan 14:01 +1300 skrev Amos Jeffries:

> I'm looking at a few approaches;
>    having Squid kick off the DNS test earlier on in the processing. So
> that the data may be available later as needed, but not hold up the
> processing.

I think the right there is to move tcp_outgoing_* later in the
processing chain, after selecting the current address to connect to. But
this requires some layering changes as it's comm that does lots of this
ipv4/ipv6 magic but comm do not have access to full request details..

I don't really see how it can be done properly before asking comm to
establish the connection.

Which means comm needs to make a async callback asking forward to pick
suitable connection parameters (address + tos) when trying to connect to
a host address (after DNS resolution).

Regards
Henrik

[Moser, Stefan (SIDB)]

Amos, Henrik,

"http_access allow to_ipv6 !to_ipv6" did work, squid now seems to work as required and can access both single (IPv4 or IPv6) and dual-stack (IPv4 and IPv6) destinations.

I´m going to play with the configuration within the next days and post a summary of my findings, this may be evolved by the community into a guideline for early IPv6 adaptors of squid (although, as you already have written, some more discussion seems to be necessary).


Thanks for your help so far!


Stefan

-----Ursprüngliche Nachricht-----
Von: Amos Jeffries [mailto:squid3@...]
Gesendet: Freitag, 30. Oktober 2009 01:34
An: Moser, Stefan (SIDB)
Cc: squid-users@...
Betreff: Re: [squid-users] Problem with IPv6 config when destination is dual-stacked (but everything works when destination is IPv4 or IPv6 only)

Moser, Stefan (SIDB) wrote:

> Hi,
>
> we are testing with squid, latest beta, in a dual-stack
> configuration:
>
> squid is running on SLES 11. Server has 1 interface card only,
> configured with an IPv4 and IPv6 address, both running on standard
> 3128 port. Server has true, native IPv4 and IPv6 internet
> connectivity (no IPv6 tunnel broker, etc.). I have applied "IPv6
> magic ACLs" as described in
> http://www.squid-cache.org/Doc/config/tcp_outgoing_address. Client
> (latest Internet Explorer and Firefox) talks to squid via IPv4 and
> IPv6 transport (that means, I enter an IPv4- or IPv6- address in
> browser´s connection settings).
>
>
> Now, what DOES work, is the following:
>
> 1. IPv4 transport from browser to squid, squid can access an IPv4
> only internet site (site has an A record only in DNS) 2. IPv4
> transport from browser to squid, squid accesses an IPv6 only internet
> site (site has an AAAA record only in DNS) 3. IPv6 transport from
> browser to squid, squid accesses an IPv4 only internet site (site has
> an A record only in DNS) 4. IPv6 transport from browser to squid,
> squid accesses an IPv6 only internet site (site has an AAAA record
> only in DNS)
>
> So far, so good, this IPv4 / IPv6 bridging obviously works.
>
> Now, what does NOT work, is:
>
> 1. IPv4 transport from browser to squid, squid CANNOT access an
> IPv4/IPv6 internet site (that means, a site that has both A and AAAA
> in DNS and that is reachable via IPv6 and IPv4) 2. IPv6 transport
> from browser to squid, squid CANNOT access an IPv4/IPv6 internet site
> (that means, a site that has both A and AAAA in DNS and that is
> reachable via IPv6 and IPv4)
>
> The cache log says (true IPv4 address removed for privacy reasons):
>
> 2009/10/28 15:59:46| commBind: Cannot bind socket FD 10 to <IPv4
> address from my providers range>: (22) Invalid argument 2009/10/28
> 15:59:46| WARNING: Reset of FD 10 for <IPv4 address from my providers
> range>:failed to bind: (22) Invalid argument
>
>
> Has everybody encountered the same problem?

Yes. The magic is not complete and has a point of failure.

FWIW, crossover works perfectly for me without tcp_outgoing_addr.

tcp_outgoing_addr is a "fast" category access control and cannot do the
dst lookup on its own. The destination IP address needs to be forced by
something earlier (http_access) for the magic to work.

I'm working on a few ways to fix this. But for now try adding
"http_access allow to_ipv6 !to_ipv6" to your config.

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

[Amos Jeffries-2]

Moser, Stefan (SIDB) wrote:

> Amos, Henrik,
>
> "http_access allow to_ipv6 !to_ipv6" did work, squid now seems to work as required and can access both single (IPv4 or IPv6) and dual-stack (IPv4 and IPv6) destinations.
>
> I´m going to play with the configuration within the next days and post a summary of my findings, this may be evolved by the community into a guideline for early IPv6 adaptors of squid (although, as you already have written, some more discussion seems to be necessary).
>
>
> Thanks for your help so far!
>
>
> Stefan
>

Thanks for testing.

I'm going to add a small hack to Squid over the next few days to get
around the need for this extra config hack and a few other problems with
the dst ACL.

If you would like to do some more testing that will be of immediate
benefit...

  a few people have reported Squid-3.1 failing to drop back to IPv4 and
just returning "connection timeout" or "unable to connect" error pages.

I'm fairly suspicious that it has something to do with the various
timeout settings being too short for forwarding+failover operations. Any
more testing in this area to deny or confirm and narrow things down to
which setting(s) would be a great help.


Amos

> -----Ursprüngliche Nachricht-----
> Von: Amos Jeffries [mailto:squid3@...]
> Gesendet: Freitag, 30. Oktober 2009 01:34
> An: Moser, Stefan (SIDB)
> Cc: squid-users@...
> Betreff: Re: [squid-users] Problem with IPv6 config when destination is dual-stacked (but everything works when destination is IPv4 or IPv6 only)
>
> Moser, Stefan (SIDB) wrote:
>> Hi,
>>
>> we are testing with squid, latest beta, in a dual-stack
>> configuration:
>>
>> squid is running on SLES 11. Server has 1 interface card only,
>> configured with an IPv4 and IPv6 address, both running on standard
>> 3128 port. Server has true, native IPv4 and IPv6 internet
>> connectivity (no IPv6 tunnel broker, etc.). I have applied "IPv6
>> magic ACLs" as described in
>> http://www.squid-cache.org/Doc/config/tcp_outgoing_address. Client
>> (latest Internet Explorer and Firefox) talks to squid via IPv4 and
>> IPv6 transport (that means, I enter an IPv4- or IPv6- address in
>> browser´s connection settings).
>>
>>
>> Now, what DOES work, is the following:
>>
>> 1. IPv4 transport from browser to squid, squid can access an IPv4
>> only internet site (site has an A record only in DNS) 2. IPv4
>> transport from browser to squid, squid accesses an IPv6 only internet
>> site (site has an AAAA record only in DNS) 3. IPv6 transport from
>> browser to squid, squid accesses an IPv4 only internet site (site has
>> an A record only in DNS) 4. IPv6 transport from browser to squid,
>> squid accesses an IPv6 only internet site (site has an AAAA record
>> only in DNS)
>>
>> So far, so good, this IPv4 / IPv6 bridging obviously works.
>>
>> Now, what does NOT work, is:
>>
>> 1. IPv4 transport from browser to squid, squid CANNOT access an
>> IPv4/IPv6 internet site (that means, a site that has both A and AAAA
>> in DNS and that is reachable via IPv6 and IPv4) 2. IPv6 transport
>> from browser to squid, squid CANNOT access an IPv4/IPv6 internet site
>> (that means, a site that has both A and AAAA in DNS and that is
>> reachable via IPv6 and IPv4)
>>
>> The cache log says (true IPv4 address removed for privacy reasons):
>>
>> 2009/10/28 15:59:46| commBind: Cannot bind socket FD 10 to <IPv4
>> address from my providers range>: (22) Invalid argument 2009/10/28
>> 15:59:46| WARNING: Reset of FD 10 for <IPv4 address from my providers
>> range>:failed to bind: (22) Invalid argument
>>
>>
>> Has everybody encountered the same problem?
>
> Yes. The magic is not complete and has a point of failure.
>
> FWIW, crossover works perfectly for me without tcp_outgoing_addr.
>
> tcp_outgoing_addr is a "fast" category access control and cannot do the
> dst lookup on its own. The destination IP address needs to be forced by
> something earlier (http_access) for the magic to work.
>
> I'm working on a few ways to fix this. But for now try adding
> "http_access allow to_ipv6 !to_ipv6" to your config.
>
> Amos

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