[squid-users] I keep getting connection refused
I have just finished setting up Squid and I am having the hardest time. I have tried everything. The current problem I am having is that I have to reload the page 20 times for me to see the page load once. The other 19 loads are a connection refused error. My squid.conf is as follows: auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd auth_param basic children 1 auth_param basic concurrency 500 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 2 hours acl manager proto cache_object acl localhost src 127.0.0.1/32 acl to_localhost dst 127.0.0.0/8 acl localnet src 10.0.0.0/8 # RFC1918 possible internal network acl localnet src 172.16.0.0/12 # RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost acl ncsaauth proxy_auth REQUIRED http_access allow ncsaauth http_access allow localnet http_access allow localhost icp_access allow localnet htcp_access allow localnet http_port 3128 acl ip1 myip 66.63.191.247 tcp_outgoing_address 66.63.191.247 ip1 acl ip2 myip 66.63.167.178 tcp_outgoing_address 66.63.167.178 ip2 acl ip3 myip 66.63.167.179 tcp_outgoing_address 66.63.167.179 ip3 acl ip4 myip 66.63.167.180 tcp_outgoing_address 66.63.167.180 ip4 acl ip5 myip 66.63.167.181 tcp_outgoing_address 66.63.167.181 ip5 acl cli_10_0_0_10 src 76.94.55.2 http_access allow cli_10_0_0_10 hierarchy_stoplist cgi-bin ? access_log /var/log/squid/access.log squid refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern (cgi-bin|\?)0 0% 0 icp_port 3130 forwarded_for off coredump_dir /var/spool/squid request_header_access Allow allow all request_header_access Authorization allow all request_header_access WWW-Authenticate allow all request_header_access Proxy-Authorization allow all request_header_access Proxy-Authenticate allow all request_header_access Cache-Control allow all request_header_access Content-Encoding allow all request_header_access Content-Length allow all request_header_access Content-Type allow all request_header_access Date allow all request_header_access Expires allow all request_header_access Host allow all request_header_access If-Modified-Since allow all request_header_access Last-Modified allow all request_header_access Location allow all request_header_access Pragma allow all request_header_access Accept allow all request_header_access Accept-Charset allow all request_header_access Accept-Encoding allow all request_header_access Accept-Language allow all request_header_access Content-Language allow all request_header_access Mime-Version allow all request_header_access Retry-After allow all request_header_access Title allow all request_header_access Connection allow all request_header_access Proxy-Connection allow all request_header_access User-Agent allow all request_header_access Cookie allow all And I added the following line to my iptables: -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 3128 -j ACCEPT Here is the message I always see: * About to connect() to proxy 66.63.167.181 port 3128 (#0) * Trying 66.63.167.181... * Connection refused * couldn't connect to host * Closing connection #0 Any help would be great! -- View this message in context: http://www.nabble.com/I-keep-getting-connection-refused-tp26112209p26112209.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Tproxy4+squid: ebtables wiki
Ok My ebtable rules are(without -i option): ebtables -t broute -A BROUTING -p ipv4 --ip-proto tcp --ip-dport 80 -j redirect --redirect-target ACCEPT ebtables -t broute -A BROUTING -p ipv4 --ip-proto tcp --ip-sport 80 -j redirect --redirect-target ACCEPT This might be the different: Bridge is up and it is having an ip address. Ethernet interfaces are up but not having any ip address asigned. ifconfig eth0 up promisc ... bridge interface is configured with dhclient: dhclient3 br0 This rules are for the routing; ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 And: echo 0 /proc/sys/net/ipv4/conf/lo/rp_filter echo 1 /proc/sys/net/ipv4/ip_forward iptables are: iptables -t mangle -N DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129 squid configuration is default, except acl allow all and port is set to the same address as in iptables, and having TPROXY set. I am using: 2.6.28-16-server x86_64 ubuntu, default or compiled ebtables v2.0.9-1 (June 2009), compiled iptables v1.4.5, Squid Cache: Version 3.1.0.14 configure options: '--enable-linux-netfilter' --with-squid=/home/marko/src/squid-3.1.0.14 --enable-ltdl-convenience configured ony with additional linux-netfilter flag I've used various network configurations: -virtual computer using VmBox with virtual interface in the linux bridge on guest pc. -computer with two interfaces. -double bridged vmbox: two virtual machines: first having 2 virtual interfaces. birdged and having sqiud. second virtual pc being client with one virtual interface. one interface of first was bridged on guest computer to external interface, other two were bridged together. Drop didn't work in any of them, accept was tested only in first. i think thats all the settings i have. --- On Wed, 10/28/09, Dan d...@jisp.net wrote: From: Dan d...@jisp.net Subject: Re: [squid-users] Tproxy4+squid: ebtables wiki To: Marko Kotar kotarma...@yahoo.com, squid-users@squid-cache.org Date: Wednesday, October 28, 2009, 9:21 PM Marko Kotar wrote: Thanks. redirect The redirect target will change the MAC target address to that of the bridge device the frame arrived on. This target can only be used in the BROUTING chain of the broute table and the PREROUTING chain of the nat table. In the BROUTING chain, the MAC address of the bridge port is used as destination address, in the PREROUTING chain, the MAC address of the bridge is used. --redirect-target target Specifies the standard target. After doing the MAC redirect, the rule still has to give a standard target so ebtables knows what to do. The default target is ACCEPT. Making it CONTINUE could let you use multiple target extensions on the same frame. Making it DROP in the BROUTING chain will let the frames be routed. RETURN is also allowed. Note that using RETURN in a base chain is not allowed. I think: If accept is used it goes in the tproxy because dst mac is changed to bridge address. (So it goes up as it would if client had gateway configured to that machine?) But is also should drop work? I decided to test it. I changed my rule to ACCEPT and traffic passes but not through the proxy. My access.log shows no new traffic after changing the rule. DROP is what passes the frame off to iptables. Could you show all your rules? If squid is receiving the traffic the only thing I can think of is that maybe there is another rule further down the chain that cause the frame to be routed. I have tryed drop but it didn't work. I didn't get through any traffic. If i didn't use any of ebtable rules it went through. But accept works. --- On Wed, 10/28/09, Dan d...@jisp.net wrote: From: Dan d...@jisp.net Subject: Re: [squid-users] Tproxy4+squid: ebtables wiki To: Marko Kotar kotarma...@yahoo.com Cc: squid-users@squid-cache.org Date: Wednesday, October 28, 2009, 1:03 AM Marko Kotar wrote: Hi, You have incorrect commands in squid wiki for tproxy4 ebtables: I figure out that it is not --redirect-target DROP but it is --redirect-target ACCEPT . With ebtables using broute ACCEPT and DROP have special meanings. DROP means route the frame and ACCEPT means bridge the frame. http://ebtables.sourceforge.net/misc/ebtables-man.html There is a -j REDIRECT which should be in lowercase letters -j redirect. Thanks for guide. Marko Dan
[squid-users] Problem with IPv6 config when destination is dual-stacked (but everything works when destination is IPv4 or IPv6 only)
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 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 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 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 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
Re: [squid-users] Tproxy4+squid: ebtables wiki
Those are the same ebtable and iptable rules that I am using except that I use DROP. If it is working for you then that is great. :) As for why it works that way I don't know. When I use ACCEPT the traffic is bridged through and not redirected to squid. Dan Marko Kotar wrote: Ok My ebtable rules are(without -i option): ebtables -t broute -A BROUTING -p ipv4 --ip-proto tcp --ip-dport 80 -j redirect --redirect-target ACCEPT ebtables -t broute -A BROUTING -p ipv4 --ip-proto tcp --ip-sport 80 -j redirect --redirect-target ACCEPT This might be the different: Bridge is up and it is having an ip address. Ethernet interfaces are up but not having any ip address asigned. ifconfig eth0 up promisc ... bridge interface is configured with dhclient: dhclient3 br0 This rules are for the routing; ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 And: echo 0 /proc/sys/net/ipv4/conf/lo/rp_filter echo 1 /proc/sys/net/ipv4/ip_forward iptables are: iptables -t mangle -N DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129 squid configuration is default, except acl allow all and port is set to the same address as in iptables, and having TPROXY set. I am using: 2.6.28-16-server x86_64 ubuntu, default or compiled ebtables v2.0.9-1 (June 2009), compiled iptables v1.4.5, Squid Cache: Version 3.1.0.14 configure options: '--enable-linux-netfilter' --with-squid=/home/marko/src/squid-3.1.0.14 --enable-ltdl-convenience configured ony with additional linux-netfilter flag I've used various network configurations: -virtual computer using VmBox with virtual interface in the linux bridge on guest pc. -computer with two interfaces. -double bridged vmbox: two virtual machines: first having 2 virtual interfaces. birdged and having sqiud. second virtual pc being client with one virtual interface. one interface of first was bridged on guest computer to external interface, other two were bridged together. Drop didn't work in any of them, accept was tested only in first. i think thats all the settings i have. --- On Wed, 10/28/09, Dan d...@jisp.net wrote: From: Dan d...@jisp.net Subject: Re: [squid-users] Tproxy4+squid: ebtables wiki To: Marko Kotar kotarma...@yahoo.com, squid-users@squid-cache.org Date: Wednesday, October 28, 2009, 9:21 PM Marko Kotar wrote: Thanks. redirect The redirect target will change the MAC target address to that of the bridge device the frame arrived on. This target can only be used in the BROUTING chain of the broute table and the PREROUTING chain of the nat table. In the BROUTING chain, the MAC address of the bridge port is used as destination address, in the PREROUTING chain, the MAC address of the bridge is used. --redirect-target target Specifies the standard target. After doing the MAC redirect, the rule still has to give a standard target so ebtables knows what to do. The default target is ACCEPT. Making it CONTINUE could let you use multiple target extensions on the same frame. Making it DROP in the BROUTING chain will let the frames be routed. RETURN is also allowed. Note that using RETURN in a base chain is not allowed. I think: If accept is used it goes in the tproxy because dst mac is changed to bridge address. (So it goes up as it would if client had gateway configured to that machine?) But is also should drop work? I decided to test it. I changed my rule to ACCEPT and traffic passes but not through the proxy. My access.log shows no new traffic after changing the rule. DROP is what passes the frame off to iptables. Could you show all your rules? If squid is receiving the traffic the only thing I can think of is that maybe there is another rule further down the chain that cause the frame to be routed. I have tryed drop but it didn't work. I didn't get through any traffic. If i didn't use any of ebtable rules it went through. But accept works. --- On Wed, 10/28/09, Dan d...@jisp.net wrote: From: Dan d...@jisp.net Subject: Re: [squid-users] Tproxy4+squid: ebtables wiki To: Marko Kotar kotarma...@yahoo.com Cc: squid-users@squid-cache.org Date: Wednesday, October 28, 2009, 1:03 AM Marko Kotar wrote: Hi, You have incorrect commands in squid wiki for tproxy4 ebtables: I figure out that it is not --redirect-target DROP but it is --redirect-target ACCEPT . With ebtables using broute ACCEPT and DROP have special meanings. DROP means route the frame and ACCEPT means bridge the frame. http://ebtables.sourceforge.net/misc/ebtables-man.html
[squid-users] LDAP authentication not working
I am unable to get the LDAP authentication working, does anyone have a working config file to share? We are using server 2003 domain controller/active directory. Currently it will prompt for username but if you hit cancel it will still let you in. We are using squid 2.7 built for windows. Thanks, Jason
[squid-users] Squid 2.7 with ICAP
Hi everyone, Another quick question I hope you don't mind answering. We're running Squid 2.7 here and a need has recently arisen to have it talk to an ICAP server. Squid 3.1 and 3.0 appear to explicitly support ICAP in squid.conf, but 2.7 doesn't seem to have the lines in the config file that you can uncomment to configure it to talk to an ICAP server. Is upgrading to 3.0 or 3.1 our only option, or do plugins/patches exist that would make this possible? Thanks! Jack This message (and any associated files) is the property of S. R. Weiner and Associates Inc. and W/S Development Associates LLC and is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by calling our corporate office at 617-232-8900 and deleting this message from your computer. Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, S. R. Weiner and Associates, Inc. and W/S Development Associates LLC do not accept responsibility for any errors or omissions that are present in this message, or any attachment, that have arisen as a result of e-mail transmission. If verification is required, please request a hard-copy version of this message. Any views or opinions presented in this message are solely those of the author and do not necessarily represent those of the company.
[squid-users] Transparent SSL allowed list. If not possible with squid, would it be possible other ways?
Hello, Ive been advised by Amos in past postings that having transparent SSL manipulation with SQUID is not possible, agreed. However I need to be able to _somehow_ have an allowed list of ssl sites specific to each LAN user (based on private IP or MAC) that he/she can access. Again this has to be with squid configured as transparent, and not with a pac file or settings in a browser. If squid definately cannot help here, I thought of a way to then take my list of SSL enabled sites (gmail.com for example) and resolve the domain to an IP and then add it in a firewall so that X user has access to port 443 on that firewall. However the downside to this is that if gmail changes the IP (which they will) the firewall rule which is static would need an update. Other a lot more complicated way would be for a packet sniffer on the outgoing DNS connection soliciating the access to enabled ssl site and then immediately create a firewall rule for that. What is the best practice? Thank you. - Andres
[squid-users] squid refresh_pattern question
ref, http://www.squid-cache.org/Doc/config/refresh_pattern/ if i wanted to ensure that *all* objects without explicit expiry time should be considered fresh for 4320 seconds, what do I set? #1: refresh_pattern . 0 20% 4320 or #2: refresh_pattern . 4320100%4320 I think #2. but then why would #1 have 4320? or, ims goes out based on some combo of min, percent max values? any help would be much appreciated. many thanks in advance.
Re: [squid-users] Tproxy4+squid: ebtables wiki
Kernel 2.6.30.8, Squid 3.1.0.14, iptables 1.4.3.1, ebtables 2.0.9 Marko Kotar wrote: Just curious which kernel version are u using? --- On Thu, 10/29/09, Dan d...@jisp.net wrote: From: Dan d...@jisp.net Subject: Re: [squid-users] Tproxy4+squid: ebtables wiki To: Marko Kotar kotarma...@yahoo.com Cc: squid-users@squid-cache.org Date: Thursday, October 29, 2009, 5:24 PM Those are the same ebtable and iptable rules that I am using except that I use DROP. If it is working for you then that is great. :) As for why it works that way I don't know. When I use ACCEPT the traffic is bridged through and not redirected to squid. Dan Marko Kotar wrote: Ok My ebtable rules are(without -i option): ebtables -t broute -A BROUTING -p ipv4 --ip-proto tcp --ip-dport 80 -j redirect --redirect-target ACCEPT ebtables -t broute -A BROUTING -p ipv4 --ip-proto tcp --ip-sport 80 -j redirect --redirect-target ACCEPT This might be the different: Bridge is up and it is having an ip address. Ethernet interfaces are up but not having any ip address asigned. ifconfig eth0 up promisc ... bridge interface is configured with dhclient: dhclient3 br0 This rules are for the routing; ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 And: echo 0 /proc/sys/net/ipv4/conf/lo/rp_filter echo 1 /proc/sys/net/ipv4/ip_forward iptables are: iptables -t mangle -N DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129 squid configuration is default, except acl allow all and port is set to the same address as in iptables, and having TPROXY set. I am using: 2.6.28-16-server x86_64 ubuntu, default or compiled ebtables v2.0.9-1 (June 2009), compiled iptables v1.4.5, Squid Cache: Version 3.1.0.14 configure options: '--enable-linux-netfilter' --with-squid=/home/marko/src/squid-3.1.0.14 --enable-ltdl-convenience configured ony with additional linux-netfilter flag I've used various network configurations: -virtual computer using VmBox with virtual interface in the linux bridge on guest pc. -computer with two interfaces. -double bridged vmbox: two virtual machines: first having 2 virtual interfaces. birdged and having sqiud. second virtual pc being client with one virtual interface. one interface of first was bridged on guest computer to external interface, other two were bridged together. Drop didn't work in any of them, accept was tested only in first. i think thats all the settings i have. --- On Wed, 10/28/09, Dan d...@jisp.net wrote: From: Dan d...@jisp.net Subject: Re: [squid-users] Tproxy4+squid: ebtables wiki To: Marko Kotar kotarma...@yahoo.com, squid-users@squid-cache.org Date: Wednesday, October 28, 2009, 9:21 PM Marko Kotar wrote: Thanks. redirect The redirect target will change the MAC target address to that of the bridge device the frame arrived on. This target can only be used in the BROUTING chain of the broute table and the PREROUTING chain of the nat table. In the BROUTING chain, the MAC address of the bridge port is used as destination address, in the PREROUTING chain, the MAC address of the bridge is used. --redirect-target target Specifies the standard target. After doing the MAC redirect, the rule still has to give a standard target so ebtables knows what to do. The default target is ACCEPT. Making it CONTINUE could let you use multiple target extensions on the same frame. Making it DROP in the BROUTING chain will let the frames be routed. RETURN is also allowed. Note that using RETURN in a base chain is not allowed. I think: If accept is used it goes in the tproxy because dst mac is changed to bridge address. (So it goes up as it would if client had gateway configured to that machine?) But is also should drop work? I decided to test it. I changed my rule to ACCEPT and traffic passes but not through the proxy. My access.log shows no new traffic after changing the rule. DROP is what passes the frame off to iptables. Could you show all your rules? If squid is receiving the traffic the only thing I can think of is that maybe there is another rule further down the chain that
[squid-users] can squid redirect the browser?
Can squid do redirection? For example, instead of microsoft's run once website loading (http://runonce.msn.com/runonce2.aspx), I'd like to redirect the browser to our internal home page. How would I accomplish this? -- View this message in context: http://www.nabble.com/can-squid-redirect-the-browser--tp26119294p26119294.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] can squid redirect the browser?
tor 2009-10-29 klockan 12:30 -0700 skrev ant2ne: Can squid do redirection? For example, instead of microsoft's run once website loading (http://runonce.msn.com/runonce2.aspx), I'd like to redirect the browser to our internal home page. Yes. How would I accomplish this? Either using url_rewrite_program and an url rewriter/redirector helper, or by using http_access deny + deny_info. Regards Henrik
Re: [squid-users] squid refresh_pattern question
tor 2009-10-29 klockan 11:55 -0700 skrev Evuraan: ref, http://www.squid-cache.org/Doc/config/refresh_pattern/ if i wanted to ensure that *all* objects without explicit expiry time should be considered fresh for 4320 seconds, what do I set? #1: refresh_pattern . 0 20% 4320 or #2: refresh_pattern . 4320100%4320 I think #2. but then why would #1 have 4320? or, ims goes out based on some combo of min, percent max values? For objects with no expiry and no Last-Modified min is used. If there is a known Last-Modified then % of the modification age bounded by max is used. There is also a refresh_pattern option to make min apply when there is a last-modified as well. Generally setting min 0 in normal Internet proxies is not a good idea, and may cause cache problems with many sites still. Not technically forbidden by HTTP specifications, but unexpected by many webauthors. Regards Henrik
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 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 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 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 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
Re: [squid-users] Problem with IPv6 config when destination is dual-stacked (but everything works when destination is IPv4 or IPv6 only)
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
Re: [squid-users] Problem with IPv6 config when destination is dual-stacked (but everything works when destination is IPv4 or IPv6 only)
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
Re: [squid-users] WCCP
Ross Kovelman wrote: From: Amos Jeffries squ...@treenet.co.nz Date: Tue, 27 Oct 2009 12:17:12 +1300 To: Ross Kovelman rkovel...@gruskingroup.com Cc: squid-users@squid-cache.org squid-users@squid-cache.org Subject: Re: [squid-users] WCCP On Wed, 21 Oct 2009 12:20:00 -0400, Ross Kovelman rkovel...@gruskingroup.com wrote: From: Ross Kovelman rkovel...@gruskingroup.com Date: Mon, 19 Oct 2009 22:35:36 -0400 To: Amos Jeffries squ...@treenet.co.nz Cc: squid-users@squid-cache.org squid-users@squid-cache.org Subject: Re: [squid-users] WCCP From: Amos Jeffries squ...@treenet.co.nz Date: Tue, 20 Oct 2009 13:20:27 +1300 To: Ross Kovelman rkovel...@gruskingroup.com Cc: squid-users@squid-cache.org squid-users@squid-cache.org Subject: Re: [squid-users] WCCP On Mon, 19 Oct 2009 20:06:55 -0400, Ross Kovelman rkovel...@gruskingroup.com wrote: From: Amos Jeffries squ...@treenet.co.nz Date: Tue, 20 Oct 2009 12:40:02 +1300 To: Ross Kovelman rkovel...@gruskingroup.com Cc: squid-users@squid-cache.org squid-users@squid-cache.org Subject: Re: [squid-users] WCCP On Mon, 19 Oct 2009 18:26:18 -0400, Ross Kovelman rkovel...@gruskingroup.com wrote: From: Amos Jeffries squ...@treenet.co.nz Date: Tue, 20 Oct 2009 11:04:42 +1300 To: Ross Kovelman rkovel...@gruskingroup.com Cc: squid-users@squid-cache.org squid-users@squid-cache.org Subject: Re: [squid-users] WCCP On Mon, 19 Oct 2009 14:21:44 -0400, Ross Kovelman wrote: From: Amos Jeffries Ross Kovelman wrote: From: Amos Jeffries: Ross Kovelman wrote: I am going to be using WCCP. I did another reconfigure with the --enable WCCP option. How can I check that it is on and running? The next step I need to do is upgrade to version 2 since the Cisco only communicates on version 2. I tried to do the patch upgrade patch but then I get a response with path to upgrade and I am not sure where the file is I need patch. There is zero need to patch for support WCCPv2. It's been built into Squid for many years now. Run ./configure --help. * If it lists --disable-wccpv2 there is no need to do anything. * If it lists --enable-wccpv2 , add that to your build options. * If it does not mention wccpv2 at all upgrade your Squid version. Then setup squid.conf with the relevant wccp2_* options. http://www.squid-cache.org/Doc/config/ or the wiki example configs have details on those. Thanks again. Running the ./configure --help only says this: --disable-wccp Disable Web Cache Coordination V1 Protocol --disable-wccpv2Disable Web Cache Coordination V2 Protocol When I did the install I ran the ./configure --enable wccp option. I didn't say --enable-wccpv2, does this matter? I also have this in the config: wccp2_router 192.168.16.1 wccp2_forwarding_method 1 wccp2_return_method 1 I am running Squid Web Proxy 2.7.STABLE5. Okay. Thats fine. The ./configure results mean that both WCCP versions are built into Squid by default unless you explicitly say --disable. Nothing extra needed to build them. The config options you have there are already WCCPv2-only options for Cisco. Nothing new needed there either. If thats not working its a config error somewhere. I am getting this in my cache log: Accepting proxy HTTP connections at 0.0.0.0, port 3128, FD 20. commBind: Cannot bind socket FD 21 to *:3128: (48) Address already in use Accepting proxy HTTP connections at 0.0.0.0, port 80, FD 21. commBind: Cannot bind socket FD 22 to *:80: (48) Address already in use http://wiki.squid-cache.org/SquidFaq/TroubleShooting#Cannot_bind_socket_FD_NN _ to_.2A:8080_.28125.29_Address_already_in_use I would suspect this as part of the problem. The WCCP router will be trying to contact whatever software is already running on port 3128, not the Squid you are starting with WCCP config. Accepting ICP messages at 0.0.0.0, port 3130, FD 22. WCCP Disabled. Accepting WCCPv2 messages on port 2048, FD 23. To answer your earlier question: the above two lines means WCCPv1 is disabled, WCCPv2 is being used. Initialising all WCCPv2 lists As from my other posting I need WCCP enabled but it is showing disabled. Any reason why? How can I resolve this. Below is my lines in config wccp2_router 192.168.16.1 wccp2_forwarding_method 1 wccp2_return_method 1 The above are only the config of how squid sends packets to the Cisco. WCCP requires configuration Cisco, the squid box OS and firewall, and routing tables. Any one of which could be the problem. The tutorials and troubleshooting info we have at present is a little spread out and disjointed. What how-to are you working from? Amos Amos, I just did a TCP dump and I think my problem is the GRE packet. It is being listed I think as unknown. Shouldn't squid be able to pick the packet up and open it? The Cisco sees squid and relays the information good but it is stopping at the squid box. Any ideas? I am just google'ing around no set how to. Okay. I've polished up our exemplar
Re: [squid-users] Problem with IPv6 config when destination is dual-stacked (but everything works when destination is IPv4 or IPv6 only)
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
[squid-users] Unsuscribed
-- Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas Infomed: http://www.sld.cu/
[squid-users] can squid filter the contents of request's payload?
Hi all, Is there any way we can filter the http traffic based on payload's contents? I am using Squid Cache (Version 2.7.STABLE5) under SmoothWall 3.0Sp1. It is working fine but I want to block such requests/responses that are formed by anonymous proxies that hide the actuall URL that is blocked by squid. For example, if youtube is blocked, and another anonymous proxy opens the youtube site by making an altogether different URL. thanks, -- Regards, Asim Ahmed Khan IT Manager, Folio3 (Pvt.) Ltd. www.folio3.com Direct: 92-21-4323721-4 Ext 110 Email: aah...@folio3.com
Re: [squid-users] can squid filter the contents of request's payload?
Asim Ahmed @ Folio3 wrote: Hi all, Is there any way we can filter the http traffic based on payload's contents? I am using Squid Cache (Version 2.7.STABLE5) under SmoothWall 3.0Sp1. It is working fine but I want to block such requests/responses that are formed by anonymous proxies that hide the actuall URL that is blocked by squid. For example, if youtube is blocked, and another anonymous proxy opens the youtube site by making an altogether different URL. thanks, Squid-2 does not alter or allow processing of the body content. For that you need to use Squid-3 with an ICAP server or eCAP plugin. Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20 Current Beta Squid 3.1.0.14
