On Sat, Jan 30, 2010 at 08:40:09AM -0500, Arch Willingham wrote:
>
> 1. The certificate question. I saw your answer but at http://wiki.squid-cache.org/ConfigExamples/Reverse/ExchangeRpc there are two lines that mention a certificate. One being SSL Certificate to present to Exchange Server (/path/to/certificate) and one being SSL certificate to present to Clients (/path/to/clientcertificate). Here is what they used in the example:
>
> Publish the RPCoHTTP service via SSL
> https_port ip_of_squid:443 cert=/path/to/clientcertificate defaultsite=rpc_domain_name
>
> cache_peer ip_of_exchange_server parent 443 0 no-query originserver login=PASS ssl sslcert=/path/to/certificate name=exchangeServer
>
> I had no idea what they were talking about so I just used the certificate I exported from Exchange for both lines but that was a SWAG and something tells me I was wrong. Can you or Brett offer some guidance on how you have done it in an install that worked?
>
Firstly, you have to ensure the certificate is in the correct format
for squid to use - when you export out of exchange is a pkcs12 format
certificate, you need to convert this to a PEM format with no password
on it.
I only have a certificate on the https_port, our certificate was
purchased from a certificate authority so web browsers automatically
trust the cert. For the cache_peer I set sslflags=DONT_VERIFY_PEER
which turns off the certificate checking for the backend machine.
>
> 3. The connection-auth=off question - I saw where you said "only if the Squid is handling authentication. If the
> backend needs to see it, this reduces support to basic or digest auth." And if you heard the sound "woosh" that was the comment going over my head. I don't know the answer...with Exchange 2007, what am I supposed to use? Brett...what did you use?
>
Passthrough authentication. You can get away without getting squid to
do the authentication, it really depends on what you are aiming to
achieve. If it is simply to allow people access to their mail from
outside then passthrough should be fine.
> 4. The question about ""forwarding" I do_ hope you really mean routing. If DNAT / REDIRECT is involved things get useless fast.".....hmmm. I have a product called "Ebox" running on the firewall (sits on Ubuntu). I picked the option called "port forwarding". How would I tell? That server's /etc/iptables.up.rules has two lines like this:
> -A fredirects -d 192.168.10.2 -i eth0 -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
> -A PREROUTING -d 65.25.30.23 -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.10.2
>
How would we tell? We don't know your network at all. If your squid
reverse proxy is on a private IP address behind a NAT firewall then,
yes, you will need to do port forwarding. Are you sure you are not
getting confused between IP port forwarding and squid request
forwarding?
-- Brett Lymn "Warning: The information contained in this email and any attached files is confidential to BAE Systems Australia. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is expressly prohibited. If you have received this email in error, please notify us immediately. VIRUS: Every care has been taken to ensure this email and its attachments are virus free, however, any loss or damage incurred in using this email is not the sender's responsibility. It is your responsibility to ensure virus checks are completed before installing any data sent in this email to your computer."Received on Tue Feb 02 2010 - 05:33:19 MST
This archive was generated by hypermail 2.2.0 : Tue Feb 02 2010 - 12:00:03 MST