Re: [squid-users] Connecting two networks via Squid

Thanks very much for your reply Chris! First off, I'm stuck using 2.5. It was a lot of work getting squid installed in the first place since the linux machine is located in another country and the administrator there is really unhelpful... >> The HTTP part looks fine, but you won't be able to make a secure connection on port 443. It's set up as a http_port, not a https_port, for start. You can proxy secure connections over a http_port (it uses a tunneling method called "CONNECT"). Do you mean that I should remove the line - http_port 10.20.1.1:443 and have my clients connect to 10.20.1.1:80 for both http and https? If not, what should I be doing for https? >> Set it up as a reverse proxy Should this work for both http and https? - httpd_accel_host 10.251.60.180 httpd_accel_port 80 httpd_accel_single_host on httpd_accel_with_proxy on where 10.251.60.180 is the "network b" server I wish the machines in "network a" to connect to? Thanks again, I really appreciate your help, Barry. --- On Thu, 5/21/09, Chris Robertson <crobertson_at_gci.net> wrote: > From: Chris Robertson <crobertson_at_gci.net> > Subject: Re: [squid-users] Connecting two networks via Squid > To: squid-users_at_squid-cache.org > Date: Thursday, May 21, 2009, 11:37 PM > Harry Griff wrote: > > Hello all, > > > > I'm about to configure my squid server and was hoping > that you could confirm for me that i've got the right idea. > > > > My situation is that I installed Squid 2.5.STABLE > > Since you are just starting, get a recent Squid > version.� 2.5 has been > out of support for quite a while. > > >� on a suse machine which is routed via eth0 to > "network A" and via > > eth1 to "network B". I wish for clients in "network A" > to access content on a server located in "network B". > > > > The protocols I wish to support are Http (80) and > Https (443). > > > > Firewalls exist between my linux machine and network > A, and between > > my linux machine and network B. The firewalls are > configured to only accept traffic via port 80 and 443. > > > > I have added networks A and B to my linux machine's > routing table and > > I can now ping from a machine in network A to the > linux machine, and > > from the linux machine to the web server on network > B. > > > > So here's my current configuration which which I hope > to test tomorrow - > > > > http_port 10.20.1.1:80 > > http_port 10.20.1.1:443 > > > > acl All src 0/0 > > acl Manager proto cache_object > > acl Localhost src 127.0.0.1/32 > > acl Safe_ports port 80 443 > > acl SSL_ports 443 > > acl CONNECT method CONNECT > > acl MyNetwork src 200.168.0.0/16 > > > > http_access allow Manager Localhost > > http_access deny Manager > > http_access deny !Safe_ports > > http_access deny CONNECT !SSL_ports > > http_access allow MyNetwork > > http_access deny All > > > > To test this, I will attempt to access the "Network B" > server from a machine on "Network A". In doing this, I will > configure the browser proxy settings on the "Network A" > machine as follows - > > > > HTTP Proxy: 10.20.1.1:80 > > SSL Proxy:� 10.20.1.1:443 > > > > And then attempt to access content from Network B. > Does this sound correct? > >��� > > The HTTP part looks fine, but you won't be able to make a > secure > connection on port 443.� It's set up as a http_port, > not a https_port, > for start.� You can proxy secure connections over a > http_port (it uses a > tunneling method called "CONNECT"). > > > Secondly, is it possible to do the above using a > transparent proxy instead? > > Transparent to your clients, yes.� Set it up as a > reverse proxy > (accelerator) and have your clients on "Network A" connect > to the proxy > (via DNS or IP) instead of the server on "Network B". > > >� I'm a little bit confused about ssl and man in > the middle attacks. If I don't wish to configure the proxies > settings on all machines in network A, should I be looking > at configuring the iptables on the linux machine so that > they forward the sll packets? I'm still a little unsure when > it comes to configuring iptables... > > > > Thanks for your help, > > > > Barry. > > Chris >
Received on Thu May 21 2009 - 23:10:57 MDT