Re: [squid-users] squid 3.1.x with IIS SharePoint as back-end.
Thanks Amos, Currently, we use a VM ( vmware) to host a RHEL with squid running. I change the back-end site with only an IIS test web site which is hosted on the same IIS system. And it's just a png image file. And it seem working. On RHEL side, there is no limitations on outgoing on iptables rules. Regards, ~Kimi On 12/01/2012, Amos Jeffries wrote: > On 12.01.2012 02:28, kimi ge wrote: >> Hi Amos, >> >> Really appreciate your help. >> >> I did changes with your sugguestion. >> >> Some debug logs are here: >> >> 2012/01/11 13:21:58.167| The request GET >> http://ids-ams.elabs.eds.com/ >> is ALLOWED, because it matched 'origin_servers' >> >> 2012/01/11 13:21:58.168| client_side_request.cc(547) >> clientAccessCheck2: No adapted_http_access configuration. >> >> 2012/01/11 13:21:58.168| The request GET >> http://ids-ams.elabs.eds.com/ >> is ALLOWED, because it matched 'origin_servers' >> >> 2012/01/11 13:21:58.170| ipcacheMarkBadAddr: >> wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 >> >> 2012/01/11 13:21:58.171| TCP connection to >> wtestsm1.asiapacific.hpqcorp.net/80 failed >> > > There you go. Squid unable to even connect to the IIS server using TCP. > > Bit strange that it should use 404 instead of 500 status. But that TCP > connection failure is the problem. > > >> My squid environment information: >> RHEL6.0 64bit. >> squid v 3.1.4 > > A very outdated Squid release version, even for RHEL (which are on > 3.1.8 or so now). > > * start with checking your firewall and packet routing configurations > to ensure that Squid outgoing traffic is actually allowed and able to > connect to IIS. > > * if that does not resolve the problem, please try a newer 3.1 > release. You will likely have to self-build or use non-RHEL RPM, there > seem to be no recent packages for RHEL. > > > Amos > >
Re: [squid-users] squid 3.1.x with IIS SharePoint as back-end.
On 12.01.2012 02:28, kimi ge wrote: Hi Amos, Really appreciate your help. I did changes with your sugguestion. Some debug logs are here: 2012/01/11 13:21:58.167| The request GET http://ids-ams.elabs.eds.com/ is ALLOWED, because it matched 'origin_servers' 2012/01/11 13:21:58.168| client_side_request.cc(547) clientAccessCheck2: No adapted_http_access configuration. 2012/01/11 13:21:58.168| The request GET http://ids-ams.elabs.eds.com/ is ALLOWED, because it matched 'origin_servers' 2012/01/11 13:21:58.170| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.171| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed There you go. Squid unable to even connect to the IIS server using TCP. Bit strange that it should use 404 instead of 500 status. But that TCP connection failure is the problem. My squid environment information: RHEL6.0 64bit. squid v 3.1.4 A very outdated Squid release version, even for RHEL (which are on 3.1.8 or so now). * start with checking your firewall and packet routing configurations to ensure that Squid outgoing traffic is actually allowed and able to connect to IIS. * if that does not resolve the problem, please try a newer 3.1 release. You will likely have to self-build or use non-RHEL RPM, there seem to be no recent packages for RHEL. Amos
Re: [squid-users] squid 3.1.x with IIS SharePoint as back-end.
Hi Amos, Really appreciate your help. I did changes with your sugguestion. Some debug logs are here: 2012/01/11 13:21:58.167| The request GET http://ids-ams.elabs.eds.com/ is ALLOWED, because it matched 'origin_servers' 2012/01/11 13:21:58.168| client_side_request.cc(547) clientAccessCheck2: No adapted_http_access configuration. 2012/01/11 13:21:58.168| The request GET http://ids-ams.elabs.eds.com/ is ALLOWED, because it matched 'origin_servers' 2012/01/11 13:21:58.170| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.171| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed 2012/01/11 13:21:58.171| fwdServerClosed: FD 11 http://ids-ams.elabs.eds.com/ 2012/01/11 13:21:58.177| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.177| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed 2012/01/11 13:21:58.177| fwdServerClosed: FD 11 http://ids-ams.elabs.eds.com/ 2012/01/11 13:21:58.183| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.184| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed 2012/01/11 13:21:58.184| fwdServerClosed: FD 11 http://ids-ams.elabs.eds.com/ 2012/01/11 13:21:58.190| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.191| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed 2012/01/11 13:21:58.191| fwdServerClosed: FD 11 http://ids-ams.elabs.eds.com/ 2012/01/11 13:21:58.197| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.197| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed 2012/01/11 13:21:58.197| fwdServerClosed: FD 11 http://ids-ams.elabs.eds.com/ 2012/01/11 13:21:58.203| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.204| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed 2012/01/11 13:21:58.204| fwdServerClosed: FD 11 http://ids-ams.elabs.eds.com/ 2012/01/11 13:21:58.210| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.210| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed 2012/01/11 13:21:58.210| fwdServerClosed: FD 11 http://ids-ams.elabs.eds.com/ 2012/01/11 13:21:58.216| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.216| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed 2012/01/11 13:21:58.217| fwdServerClosed: FD 11 http://ids-ams.elabs.eds.com/ 2012/01/11 13:21:58.222| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.223| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed 2012/01/11 13:21:58.223| fwdServerClosed: FD 11 http://ids-ams.elabs.eds.com/ 2012/01/11 13:21:58.229| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.229| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed 2012/01/11 13:21:58.229| Detected DEAD Parent: main 2012/01/11 13:21:58.229| fwdServerClosed: FD 11 http://ids-ams.elabs.eds.com/ 2012/01/11 13:21:58.235| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:21:58.236| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 failed 2012/01/11 13:21:58.236| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 dead 2012/01/11 13:21:58.236| fwdServerClosed: FD 11 http://ids-ams.elabs.eds.com/ 2012/01/11 13:21:58.238| The reply for GET http://ids-ams.elabs.eds.com/ is ALLOWED, because it matched 'all' 2012/01/11 13:21:58.240| ConnStateData::swanSong: FD 9 2012/01/11 13:22:07.406| The request GET http://ids-ams.elabs.eds.com/ is ALLOWED, because it matched 'origin_servers' 2012/01/11 13:22:07.406| client_side_request.cc(547) clientAccessCheck2: No adapted_http_access configuration. 2012/01/11 13:22:07.406| The request GET http://ids-ams.elabs.eds.com/ is ALLOWED, because it matched 'origin_servers' 2012/01/11 13:22:07.407| ipcacheMarkBadAddr: wtestsm1.asiapacific.hpqcorp.net 16.173.232.237:80 2012/01/11 13:22:07.408| Failed to select source for 'http://ids-ams.elabs.eds.com/' 2012/01/11 13:22:07.408| always_direct = 0 2012/01/11 13:22:07.408|never_direct = 0 2012/01/11 13:22:07.408|timedout = 0 2012/01/11 13:22:07.410| The reply for GET http://ids-ams.elabs.eds.com/ is ALLOWED, because it matched 'all' 2012/01/11 13:22:07.410| TCP connection to wtestsm1.asiapacific.hpqcorp.net/80 dead 2012/01/11 13:22:07.412| ConnStateData::swanSong: FD 9 2012/01/11 13:22:09.381| The request GET http://ids-ams.elabs.eds.com/ is ALLOWED, because it matched 'origin_servers' 2012/01/11 13:22:09.381| client_side_request.cc(547) clientAccessCheck2: No adapted_http_access configuration. 2012/01/11 13:22:09.381| The request GET http://ids-ams.elabs.eds.com/ is ALLOWED, because it matched 'origin_servers' 2012/01/11 13:22:09.383| ipcacheMarkBadAddr: wtestsm1.asiapacific.h
Re: [squid-users] squid 3.1.x with IIS SharePoint as back-end.
On 11/01/2012 8:46 p.m., kimi ge(巍俊葛) wrote: Thanks Amos. I did the lynx test on back-end web site on squid system like this: sudo lynx http://wtestsm1.asiapacific.hpqcorp.net First, it show the message: Alert!: Invalid header 'WWW-Authenticate: NTLM' Then it show the following message. Show the 401 message body? (y/n) Aha. NTLM authentication. Very probaby that login=PASS then. For the domain auth, I mean the back-end web site need corp domain user to be accessed. I put this in this way, if I log on with my corp domain on my laptop, then I could acces IIS Share Point without any credentials window pop up. If not, I have to input my domain account on credentials window to access the Share Point Site. The following is my squid configuration about this case which I ignore some default sections. #added by kimi acl hpnet src 16.0.0.0/8# RFC1918 possible internal network #added by kimi acl origin_servers dstdomain ids-ams.elabs.eds.com http_access allow origin_servers http_access allow hpnet http_port 192.85.142.88:80 accel defaultsite=ids-ams.elabs.eds.com connection-auth=on forwarded_for on request_header_access WWW-Authenticate allow all This is not needed. The Squid default is to relay www-auth headers through. www-authenticate is a reply header anyway, to inform the client agent what types of auth it can use. cache_peer wtestsm1.asiapacific.hpqcorp.net parent 80 0 no-query no-digest originserver name=main connection-auth=on login=PASS "connection-auth=on" should be enough. Try without login=PASS. cache_peer_domain main .elabs.eds.com hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid # Add any of your own refresh_pattern entries above these. refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 cache_dir aufs /data/squid/cache 12000 64 256 cache_mem 1024 MB maximum_object_size_in_memory 1024 KB maximum_object_size 51200 KB visible_hostname ids-ams.elabs.eds.com debug_options ALL,5 http_access deny all While let squid be running, I do test like this http://ids-ams.elabs.eds.com The 404 error page is shown. Okay. Which error page? Squid sends three different ones with that status code. Invalid request or Invalid URL or something else? That's why I am wondering squid could be as reverse-proxy with IIS SharePoint as back-end? It can be. There is normally no trouble. But the newer features MS have been adding for IPv6 and cloud support recently are not widely tested yet. Amos
Re: [squid-users] squid 3.1.x with IIS SharePoint as back-end.
Thanks Amos. I did the lynx test on back-end web site on squid system like this: sudo lynx http://wtestsm1.asiapacific.hpqcorp.net First, it show the message: Alert!: Invalid header 'WWW-Authenticate: NTLM' Then it show the following message. Show the 401 message body? (y/n) For the domain auth, I mean the back-end web site need corp domain user to be accessed. I put this in this way, if I log on with my corp domain on my laptop, then I could acces IIS Share Point without any credentials window pop up. If not, I have to input my domain account on credentials window to access the Share Point Site. The following is my squid configuration about this case which I ignore some default sections. #added by kimi acl hpnet src 16.0.0.0/8# RFC1918 possible internal network #added by kimi acl origin_servers dstdomain ids-ams.elabs.eds.com http_access allow origin_servers http_access allow hpnet http_port 192.85.142.88:80 accel defaultsite=ids-ams.elabs.eds.com connection-auth=on forwarded_for on request_header_access WWW-Authenticate allow all cache_peer wtestsm1.asiapacific.hpqcorp.net parent 80 0 no-query no-digest originserver name=main connection-auth=on login=PASS cache_peer_domain main .elabs.eds.com hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid # Add any of your own refresh_pattern entries above these. refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 cache_dir aufs /data/squid/cache 12000 64 256 cache_mem 1024 MB maximum_object_size_in_memory 1024 KB maximum_object_size 51200 KB visible_hostname ids-ams.elabs.eds.com debug_options ALL,5 http_access deny all While let squid be running, I do test like this http://ids-ams.elabs.eds.com The 404 error page is shown. That's why I am wondering squid could be as reverse-proxy with IIS SharePoint as back-end? Thanks, ~Kimi On 11/01/2012, Amos Jeffries wrote: > On 11/01/2012 6:28 p.m., kimi ge(巍俊葛) wrote: >> Hi, >> >> I have an issue to make squid 3.1.x to work with IIS SharePoint as the >> back-end. >> The details are listed below. >> >> 1. squid 3.1.x is running as a reverse-proxy. >> 2. The back-end is IIS SharePoint Site with domain authentication >> required. >> That means only the valid domain user could access this SharePoint site. >> The issue is it always return 404 error page. And the logon window is >> not prompted. > > What is this "domain authentication" you mention? All of the HTTP auth > mechanisms count as "domain auth" to a reverse proxy, and none of them > are named "Domain". > >> >> My question is whether squid supports this kind of case or not? >> If supports, how should I do configuration on squid.conf file? >> >> Thanks in advance. >> ~Kimi > > 404 status is about the resource being requested _not existing_. Login > only operates when there is something to be authorized fetching. So I > think auth is not relevant at this point in your testing. > > Probably the URL being passed to IIS is not what you are expecting to be > passed and IIS is not setup to handle it. You will need to share your > squid.conf details for more help. > > Amos >
Re: [squid-users] squid 3.1.x with IIS SharePoint as back-end.
On 11/01/2012 6:28 p.m., kimi ge(巍俊葛) wrote: Hi, I have an issue to make squid 3.1.x to work with IIS SharePoint as the back-end. The details are listed below. 1. squid 3.1.x is running as a reverse-proxy. 2. The back-end is IIS SharePoint Site with domain authentication required. That means only the valid domain user could access this SharePoint site. The issue is it always return 404 error page. And the logon window is not prompted. What is this "domain authentication" you mention? All of the HTTP auth mechanisms count as "domain auth" to a reverse proxy, and none of them are named "Domain". My question is whether squid supports this kind of case or not? If supports, how should I do configuration on squid.conf file? Thanks in advance. ~Kimi 404 status is about the resource being requested _not existing_. Login only operates when there is something to be authorized fetching. So I think auth is not relevant at this point in your testing. Probably the URL being passed to IIS is not what you are expecting to be passed and IIS is not setup to handle it. You will need to share your squid.conf details for more help. Amos
