Johnson, S wrote:
> Hello,
>
> I've got a weird issue that I've been finding off an on. I can finally
> duplicate it regularly now. I'm working with a "public" network that
> we've separated from the local network. We have web resources that are
> on the external side of the squid box.
>
> This is what our network looks like:
>
> --------public network 65.80.133.x--------
> | |
> | public network
> firewall---(nat)DMZ (192.168.80.x/23)
> | (192.168.2.0/24)
> | (web servers)
> |
> |
> private network
> (10.x.x.x)
> The squid server here is configured with an AUP page with a click
> through to continue to the site they originally were trying to get to.
> Any page outside of our network altogether works great; they get the AUP
> and the click through it. However, if they try to access the local web
> server which shares the same external subnet as the squid server then I
> cannot click past the AUP.
>
> To make this a little more complex, I'm attempting to do this through
> transparent proxy. I've also got DNS configured to provide a WPAD file.
> If I use the autoproxy config in the browser then it works just fine
> (which is why it was working for me). Once I turn this off in the
> browser I once again cannot get to the local web server but other
> outside sites work just fine. I don't see any hits in the log if I try
> to browse the local web server which makes me believe that the traffic
> isn't even hitting the proxy. However, it should since there are no
> local routes on the workstation that would do otherwise. It's like the
> proxy server isn't picking up the packets at all...
>
> Oh one more weird thing... if I set myweb in the acl below at the top
> of the ACL list then I'm able to get to the local servers but the AUP
> page never shows if their homepage is set to the local web server. I
> guess I would expect this behavior since I've never denied the session.
> I've tried moving the myweb acl around the whole list but I don't get
> any other results...
>
> This is my config:
>
> # TAG: acl
> #Recommended minimum configuration:
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32
> acl to_localhost dst 127.0.0.0/8
> acl to_localbox dst 192.168.80.5/32
> acl myweb dst 64.80.132.1/32
>
>
> follow_x_forwarded_for allow localhost
> acl_uses_indirect_client on
> delay_pool_uses_indirect_client on
> log_uses_indirect_client on
>
>
> external_acl_type session ttl=10 children=1 negative_ttl=0
> concurrency=200 %SRC /usr/lib/squid/squid_session -t 1800
>
> acl session external session
>
> acl localnet src 192.168.80.0/23 # RFC1918 possible internal network
> acl SSL_ports port 443
> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl CONNECT method CONNECT
>
> # TAG: http_access
> http_access allow to_localbox
> deny_info http://192.168.80.5/index.php?url=%s session
Using the IP address in the URL like that breaks when NAT is involved.
Clients outside the 192.* routable network won't ever be able to open
the page directly.
You need some form of publicly resolvable domain name that resolves to a
the relevant IP for each network.
> #http_access allow myweb #trying different locations for the session to
> be set
> http_access deny !Safe_portshttp_access allow session
I hope that was a typo of the cut-n-paste process?
> http_access allow SSL_ports
> http_access allow CONNECT SSL_ports
> http_access deny !session
> http_access allow myweb
> http_access deny !Safe_ports
>
> http_access deny all
>
> http_port 3128 transparent
Due to CVE-2009-0801 it's no longer safe practice to receive NAT
intercepted traffic on the same port as normal proxy traffic.
Another port should be chosen and secured for the private channel
between Squid and the firewall doing NAT.
Amos
-- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.1Received on Wed Apr 21 2010 - 06:30:24 MDT
This archive was generated by hypermail 2.2.0 : Wed Apr 21 2010 - 12:00:05 MDT