On 13/01/2012 3:27 a.m., Dale J. Rodriguez wrote:
Hello World. Noob Here.
I have successfully setup squid as a reverseproxy for port 80, however
What squid version?
my attempts to set up the same server to point to a https server on
sharepoint have failed. All I get is the authentication box, and the
following error message in cache.log:
fwdNegotiateSSL: Error negotiating SSL connection on FD 11:
error:00000000:lib(0):func(0):reason(0) (5/-1/104)
Squid is connecting to a remote server which is responding with
something which is (a) not SSL encrypted, or (b) using an SSL / TLS
version not supported by your OpenSSL library.
The only caveat I have is that I am using an SSL cert that was assigned
to another IP address, do you have to have matching SSL certs for this
to work properly?
If the certificate has been created to tie the domain and IP address
together, then yes. I've only seen it on client certificates and some
high-security setups.
Most server ones seem to just be tied to the domain name, allowing
re-use in reverse proxies like you are trying to do.
Here is my squid config:
visible_hostname squid.localhost
This is the visible (ie public) hostname (read: FQDN / fully qualified
domain name) of your Squid machine.
Also, ".localhost" domain is invalid. The IANA registered domain you
seem to be looking for is ".local". But that leads to problems with ISP
admin unable to find out who on their own LAN is running the machine
"squid".
always_direct allow all
This means do not use cache_peer entries in your config. Ever.
Fix #1:
Please remove this and your actual reverse-proxy config will start to
work the way you configured it.
ssl_bump allow all
pipeline_prefetch off
http_port 80 defaultsite=1.2.3.60
This means your website *domain name* is "1.2.3.60" for all traffic
received on port 80.
Note that clients connecting to 1.2.3.60 will of course *connect
straight to 1.2.3.60* (instead of your Squid). So any URL re-write
related side effects will bypass Squid and go straight to the backend
server.
Clients which are somehow passing requests to Squid will have their
traffic URLs re-written to http://1.2.3.60/ before Squid tries to
resolve the domain (er, 1.2.3.60) in DNS and gets told the IP 1.2.3.60.
always_direct will then force Squid to pass the re-written request to
that IP.
** notice how cache_peer and the cache_peer access logics never got used.
Fix #2:
you need to add the actual public domain name clients are connecting
to as defaultsite=.
if you have multiple domains you need to enabel virtual hosting with
the "vhost" reverse-proxy option to http_port
https_port 443 cert=/usr/ssl/lol.cer key=/usr/ssl/llol2.server.pem
connection-auth=on defaultsite=1.2.3.11
Same problems are happening here. But with the "domain name" 1.2.3.11.
Fix #3: see fix #2.
cache_peer 1.2.3.60 parent 80 0 no-query originserver no-digest
login=PASS name=bi_iis
cache_peer 1.2.3.11 parent 443 0 connection-auth=on no-query
originserver login=PASSTHRU ssl sslflags=DONT_VERIFY_PEER
name=sharepoint
see notes above with always_direct.
These appear at first glance to be okay of themselves.
acl bi_server dst 1.2.3.60
acl sharepoint dst 1.2.3.11
acl lan1 src 1.2.3.0/32
acl lan2 src 1.2.3.0/32
acl vpn src 5.6.7.0/32
acl externalip src 2.3.4.0/32
cache_peer_access bi_iis allow bi_server
cache_peer_access bi_iis allow lan1
cache_peer_access bi_iis allow lan2
cache_peer_access bi_iis allow vpn
cache_peer_access bi_iis allow externalip
cache_peer_access bi_iis deny all
cache_peer_access sharepoint allow bi_server
cache_peer_access sharepoint allow lan1
cache_peer_access sharepoint allow lan2
cache_peer_access sharepoint allow vpn
cache_peer_access sharepoint allow externalip
cache_peer_access sharepoint deny all
see always_direct.
What I see here is nothing like a normal reverse-proxy configuration.
When you have the correct domain names passing through from http_port
and always_direct gone you should be able to revert these back to the
simple dstdomain ACL which are documented for reverse-proxy. Possibly
with HTTP/HTTPS ACLs tying the secure traffic to the SSL peer if you want.
http_access allow lan1
http_access allow lan2
http_access allow vpn
http_access allow externalip
#negative dns entry
acl localhost src 127.0.0.1/32
acl manager proto cache_object
acl Safe_ports port 80 # httpacl Safe_ports port 443 #https
acl CONNECT method CONNECT
acl POST method POST
never_direct allow CONNECT
never_direct allow POST
never_direct allow ALL
A series of allow lines followed by "allow all" is meaningless. Same
applies to a series of deny and "deny all". Every possible ACL test or
combination of tests is a subset of "all".
The only reason you may want to performuse for a test sequence like this
was if it had side effects (DNS lookups, external ACL helper calls, auth
credentials lookup etc) which were needed soon by some following
fast-group access control which cannot perform the lookup itself.
"always_direct allow all" and "never_direct allow all" in the same
config file shows a misunderstanding of how ACLs work.
always_direct determines whether use of cache_peer is forbidden
(DIRECT forced) or if peers *may* be used.
never_direct determines whether DIRECT may be used as a back when
the cache_peer all have problems.
DIRECT being a DNS lookup of the domain name, and connection to the IP
addresses found in DNS.
sslproxy_flags DONT_VERIFY_PEER
cache_mgr a@xxxxxxx
http_access allow manager localhost
http_access allow lan1
http_access allow lan2
http_access allow vpn
http_access allow externalip
You allow'ed these already up above already.
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT
#http_access deny all
This needs a look at after the rest is configured. None of it makes much
sense in a reverse-proxy and can br removed. But for a general proxy it
is broken at present and needs fixing.
Amos
