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@xxxxxxxxxxx> 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?
--
Thanks,
Dean E. Weimer
http://www.dweimer.net/
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
