Amos Jeffries-2 wrote >> logfile_rotate 5 >> >> ## this line is obsolete in 3.3.5 >> ##emulate_httpd_log yes >> >> server_persistent_connections off > > The above is no longer necessary with squid-3.2 and later. You can > safely enable server persistence now without getting any of the > connection crossover bugs which were so annoying in older Squid. Thank you, that is very helpful. Amos Jeffries-2 wrote >> forwarded_for off >> >> ## declare an acl that is true for all ipv6 destinations >> acl to_ipv6 dst ipv6 >> >> ## deny ipv4 access >> http_access deny !to_ipv6 > > This is probably the cause of your non-connectivity problem. IPv4 and > not-IPv6 are two different things, all of IPv4 space maps inside IPv6. > Also, just about all IPv6-enabled sites also have IPv4 addresses. > > What exactly are you trying to achieve here? > ensuring that your clients get to IPv6 version of sites? > or, ensuring that they get rejection pages if they go to IPv4-only sites? > or, preventing access to IPv4 side of dual-stacked sites? The purpose in this instance was to force IPv6 connection, or no connection at all. The sites to be accessed in this case should be dual-stacked and as far as I can see (at least, when testing my previous partially working script with 3.1.1) IPv6 was taking priority. What I wanted to ensure was no leakage of the IPv4 address of the proxy on dual stack sites. Would this accomplish this? When I tested this on 3.1.1 it seemed to work for that purpose - I went to http://ipv6-test.com/ and without this line, the test was showing both IPv6 and IPv4 address. With the line enable, the test only showed IPv6. Is there a better way to approach this? Amos Jeffries-2 wrote >> ## disable caching >> cache deny all >> >> ## this line is obsolete in 3.3.5 >> ##acl manager proto cache_object >> >> request_header_access Allow allow all >> request_header_access Authorization allow all > <snip...> >> request_header_access Cookie allow all >> request_header_access All deny all > > A bunch of these are not request headers. The documentation has been > updated recently to list which are request header and which are reply > headers. > > http://www.squid-cache.org/Doc/config/request_header_access/ > http://www.squid-cache.org/Doc/config/reply_header_access/ > > FWIW: The example is documenting how Squid can perform behaviour of some > long-ago anonymising feature. There are many HTTP/1.1 and later headers > (most noticeablyTransfer-Encoding reply header) whih are missing from > that list. > > Amos Thank you - I hadn't seen the updated documentation - time for some digging, and yes, you are correct those lines were supposed to be anonymising - would any of these contribute to the connectivity issue? Also, are the obsolete lines not needed anymore? ## this line is obsolete in 3.3.5 ##acl manager proto cache_object ## this line is obsolete in 3.3.5 ##emulate_httpd_log yes Thanks again for your comments. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-how-to-link-inbound-IPv4-multiple-port-connections-to-unique-outbound-IPv6-s-tp4660190p4660230.html Sent from the Squid - Users mailing list archive at Nabble.com.
