[squid-users] Squid Reverse Proxy to Exchange 2010 OWA

[Amos Jeffries]

On 12/03/2015 8:59 a.m., dweimer wrote:
> On 03/11/2015 1:16 am, Alex Samad wrote:
>> This is mine against 2008. haven't had any issues with attachments up
>> to 10M
>>
>>
>> cache_peer 127.0.0.1 parent 443 0 proxy-only no-query no-digest
>> originserver login=PASS ssl sslflags=DONT_VERIFY_PEER
>> sslcert=/etc/httpd/conf.d/o.crt sslkey=/etc/httpd/conf.d/o.key
>> name=webServer
>> cache_peer 10.32.69.11 parent 443 0 proxy-only no-query no-digest
>> originserver login=PASS front-end-https=on ssl
>> sslflags=DONT_VERIFY_PEER sslcert=/etc/httpd/conf.d/o.crt
>> sslkey=/etc/httpd/conf.d/o.key name=exchangeServer
>>
>> # List of acceptable URLs to send to the Exchange server
>> acl exch_url url_regex -i <o>/exchange
>> acl exch_url url_regex -i <o>/exchweb
>> acl exch_url url_regex -i <o>/public
>> acl exch_url url_regex -i <o>/owa
>> acl exch_url url_regex -i <o>/ecp
>> acl exch_url url_regex -i <o>/microsoft-server-activesync
>> acl exch_url url_regex -i <o>/rpc
>> acl exch_url url_regex -i <o>/rpcwithcert
>> acl exch_url url_regex -i <o>/exadmin
>> acl exch_url url_regex -i <o>/oab
>>
>> # Send the Exchange URLs to the Exchange server
>> cache_peer_access exchangeServer allow exch_url
>>
>> # Send everything else to the Apache
>> cache_peer_access webServer deny exch_url
>>
>> # This is to protect Squid
>> never_direct allow exch_url
>>
>> # Logging Configuration
>> redirect_rewrites_host_header off
>> cache_mem 32 MB
>> maximum_object_size_in_memory 128 KB
>> cache_log none
>> cache_store_log none
>>
>> access_log /var/log/squid/office-access.log squid
>> #access_log none
>> cache_log /var/log/squid/office-cache.log
>> #cache_log none
>> pid_filename /var/run/squid-office.pid
>>
>>
>> # Set the hostname so that we can see Squid in the path (Optional)
>> visible_hostname <o>
>> deny_info TCP_RESET all
>>
>> # ACL - required to allow
>> #acl all src ALL
>>
>> # Allow everyone through, internal and external connections
>> http_access allow all
>> miss_access allow all
>>
>> icp_port 0
>> snmp_port 0
>>
>> via off
>>
>> On 11 March 2015 at 15:42, dweimer <dweimer at dweimer.net> wrote:
>>> We have setup Squid as a reverse proxy to Exchange 2010 OWA server we
>>> thought everything was working OK, but found out that any file
>>> attachments
>>> over 2MB cause a timeout after 5 minutes. I remembered having this
>>> issue a
>>> while back with HTTPS, and it just went away after some updates. Some
>>> searching found other users posting messages to the Squid mailing
>>> list that
>>> had this issue in particular with OWA. However I never found a fix on
>>> any of
>>> the threads.
>>>
>>> Squid is currently running 3.4.11, on FreeBSD 10.1-RELEASE-p5, This
>>> occurs
>>> even when sending the file through the local network passing through the
>>> reverse proxy. With the slowest link being a 1G.
>>>
>>> Below is the relevant parts of the configuration, with some information
>>> excluded for security
>>> https_port 10.50.20.12:443 accel defaultsite=... \
>>>  cert=... \
>>>  key=... \
>>>  options=NO_SSLv2:NO_TLSv1:CIPHER_SERVER_PREFERENCE \
>>>  cipher=RC4:!MD5:!aNULL:!EDH
>>>
>>> cache_peer ... parent 443 0 ssl no-query no-digest no-netdb-exchange
>>> originserver name=owa2010_parent sslcapath=/usr/local/share/certs
>>> sslflags=DONT_VERIFY_PEER login=PASSTHRU front-end-https=on
>>>
>>> We also host sharepoint (certificate is a wildcard certificate) this
>>> way as
>>> well, and I have just verified that it has the same problem. It is
>>> served by
>>> the same https_port line, and a different cache_peer the only
>>> difference is
>>> the IP and it doesn't have the front-end-https option set.
>>>
>>> Does anyone have any ideas to check?
>>>
>>> is this possibly a cause
>>> <http://www.squid-cache.org/Doc/config/broken_posts/>?
>>>
> 
> I don't believe OWA has anything to do with my problem, it appears to be
> related entirely to posting with HTTPS using the reverse proxy. I ran
> into this after the upgrade from squid 3.1 to 3.2 back on FreeBSD
> version 9.0 & 9.1. I never did find the answer to the issue then, it
> finally just went away after the upgrade to squid 3.3. At the time the
> application I was using was using that was affected was running on
> Apache and PHP, that application is still run from this reverse proxy
> server as well but apparently unaffected by the problem now. It's
> current version uses an uploader process that uses java to chunk the
> files into smaller pieces during upload.
> 
> What appears to happen is that the client sends the entire file to the
> Squid Reverse Proxy server, but somehow at the end of the file Squid
> never receives an expected end of file from the client. The client
> believes that everything is sent and sits waiting until it times out.
> 
> Oddly enough when I put fiddler on my laptop to capture the HTTPS
> traffic in a decrypted method so that I could see more information into
> what was happening. It succeeds if the browser is talking to fiddler,
> which is talking to the reverse proxy which is talking to the end
> server. Why adding fiddler to this chain of options fixes it is well
> beyond my understanding.
> 
> I am working on setting up a more simplified VM with mimimal settings in
> that I can run debugging in to get a better logs to help with the issue
> the current system has to much traffic on it. Does anyone have any
> suggestions for which debugging level I should use for squid in order to
> attempt to get useful logs to troubleshoot this?
> 

debug_options ALL,9 if you are using a lab setup like that with easily
repeatable test.


It could be related to the issue for which broken_posts exists, but that
directive will probably only help if Squid is aware that it has the
entire request payload.

Or it could be Squid is stuck with only 1-2 bytes of buffer space
available and waiting for the server to drain it.

Amos