Re: [squid-users] Squid2.6-17: Problematic DMZ to Private pass-through with OWA

> I have been working on this config for 4 straight days without success
> and need some help. What I am trying to configure is a DMZ server (with
> true public addresses) running Squid that acts as a front-end server to
> three separate Exchange OWA servers in private networks (all accessible
> behind the same firewall).

OK, the hosts file should not enter into the deal here, you can and should
NX those entries. OWS need settign up as peers which can be configured
straight with internal FQDN or private IPs.
more on that later...

>
> Internet --- Firewall --- Squid Server (public with 3 IPs)
> |
> |---- Exch 1 (private)
> |---- Exch 2 (private)
> |---- Exch 3 (private)
>
> Squid (2.6 stable 17, running on CentOS 5) is configured to bind three
> public IPs on port 80, one for each internal server. Using the config
> excerpted below, I can open the public IP for each one and reach the
> proper private OWA server. BTW, resolution for internal IPs is handled
> correctly by Squid server "Hosts" file.
>
> The problem is that, instead of Squid handling the entire transaction
> and acting as a middleman, Squid receives the first request and then
> passes the client completely on to the internal server. For example, 1)
> open squid-pub1.domain.com/exchange; 2) receive the authentication
> pop-up for Exchange OWA (from squid-pub1 server) and provide
> credentials; 3) receive the authentication pop-up for Exchange OWA (from
> internal OWA server) and provide credentials; 4) browser loads internal
> OWA server 1 (address is now internal server name). When I am here on
> the network this works since I have access to both public and private
> network segments. Obviously, when outside on the public Internet this
> fails miserably since the internal addresses cannot be publicly routed.
>
> I need the Squid server to operate entirely as a middleman for this
> situation to work. Eventually, this will also be changed over to HTTPS
> and SSL, but for now, we need it running on port 80.
>
> I've dug through the FAQ, tried to find similar issues in the Archive,
> read all of the docs at ViSolve (they are from older versions anyway),
> and searched Google for hours. Any/all help would be appreciated.
>
> TIA, Michael
>
> Here are all active lines from the config file (names and IPs changed to
> protect the innocent):
>
> acl all src 0.0.0.0/0.0.0.0
> acl manager proto cache_object
> acl localhost src 127.0.0.1/255.255.255.255
> acl to_localhost dst 127.0.0.0/8
> acl SSL_ports port 443
> acl Safe_ports port 80 # http
> acl Safe_ports port 443 # https
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl CONNECT method CONNECT
> http_access allow manager localhost
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> acl OWAip dst 10.xxx.xxx.xx ##internal
> server 1
> acl OWAip2 dst 10.xxx.xxx.xx ##internal
> server 2
> acl OWAip3 dst 192.xxx.xxx.x ##internal
> server 3

!! NX these. Clients should never be told the real location of OAW
servers, so these should never be used.

> acl OWA dstdomain exch1.domain1.local ##internal exch OWA FQDN
> 1
> acl OWA2 dstdomain exch2.domain2.com ##internal exch OWA FQDN
> 2
> acl OWA3 dstdomain exch3.domain3.com ##internal exch OWA FQDN
> 3

!! Clients MUST NEVER be told the internal FQDN for the OWA. Thus the
dstdomain here must be the public FQDN for squid.

> http_access allow OWAip
> http_access allow OWAip2
> http_access allow OWAip3
> http_access deny all
> icp_access allow all
> miss_access allow OWAip
> miss_access allow OWAip2
> miss_access allow OWAip3
> miss_access deny all

> http_port 208.xxx.xxx.210:80 accel defaultsite=exch1.domain1.local
> ##pub/DMZ IP on port 80 to priv OWA via FQDN
> http_port 208.xxx.xxx.211:80 accel defaultsite=exch2.domain2.com
> ##pub/DMZ IP on port 80 to priv OWA via FQDN
> http_port 208.xxx.xxx.212:80 accel defaultsite=exch3.domain3.com
> ##pub/DMZ IP on port 80 to priv OWA via FQDN

> cache_peer 10.xxx.xxx.xx parent 80 0 no-query originserver login=PASS
> name=exch1
> cache_peer 10.xxx.xxx.xx parent 80 0 no-query originserver login=PASS
> name=exch2
> cache_peer 192.xxx.xxx.x parent 80 0 no-query originserver login=PASS
> name=exch3
> cache_peer_access exch1 allow OWA
> cache_peer_access exch2 allow OWA2
> cache_peer_access exch3 allow OWA3

All to the good, assuming you fix the ACL problems mentioned above.

> never_direct allow OWAip
> never_direct allow OWAip2
> never_direct allow OWAip3

!! These should be the same OWA, OWA2, OWA3 ACL used above.

!! after all that is fixed. Configure the OWA so they internally think
they are servers for the public (squid) FQDN which they secretly handle.
You NEED this so the details OWA privately pass back to clients is
consistent with the squid-FQDN the clients are connecting to.

After fixing the config as above any client can access squid which will
multiplex the requests to internal OWA depending on the requested
virtual-domain which points at squid.

You then have an option of dropping 2 of the IP and just pointing all
three external domains at squid, OR adding a myip ACL to each
cache_peer_access to make squid give 404/* when exch3.domain3.com is
requested at 208.xxx.xxx.211:80 and vice-versa.

Amos
Received on Tue Dec 04 2007 - 20:25:36 MST