Re: [squid-users] Random image generator w/ reverse-proxy

Keith M. Richard wrote:
> All,
>
> I have a web page on my site that has a randomly generated image (Alpha numeric picture) to allow users to register. I am using squid as an accelerator in my DMZ to this internal web server. Right now the image is coded as an unsecured (http) link/servlet on port 8888, which is just a random port. This is embedded in a HTTPS page. If I don't use squid it works but through squid if fails to display the image.
> I have checked the firewall and it is properly configured. When I check the firewalls log, it shows the request to 8888 from the outside, but those same requests are never passed through squid for some reason. I have also run Wireshark on the squid server to capture the traffic as users made requests and I see the TCP [SYN] from the client to the squid servers IP address, but then the squid sends a TCP [RST, ACK]. When I watch the same request being made from the squid server running FireFox to the internal web server it makes the handshake. I cannot figure out why the reset is happening.
>

I'd guess it's because Squid is not listening on port 8888... See
comments in the squid.conf section below.

> I modified the logformat so that I can get some readable data and this is what I get from the output:
>
> 18/Feb/2008:13:03:12 -0600 xxx.xxx.xxx.xxx:51651 192.168.0.135:8888 TCP_MISS/404 697 GET http://www.my-company.org/randomimages/servlet/org.groupbenefits.por
> tal.RandomImageGenServlet? FIRST_UP_PARENT/192.1.0.59 text/html
>

That's certainly an interesting log fragment as it goes against what you
state in the second paragraph above (this is not evidence of a TCP [RST,
ACK]). Instead it is indicative of a different problem (namely the
forward is going to the wrong port (notice the lack of a port on the GET
request), hence the 404).

>
> ******************************************************************
> # Basic config
> acl all src 0.0.0.0/0.0.0.0
> acl manager proto http 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 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 8080 # safe
> acl Safe_ports port 8888 # safe
> 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
>
> # Accelerator Mode
> http_port 80 defaultsite=www.my-company.org
> http_port 192.1.0.59:8888 defaultsite=www.my-company.org
>

Considering the fact that squid is using the server at 192.1.0.59 as the
origin server, and that you stated Squid is in the DMZ, and the web
server is internal, I can surmise that Squid is on a different host from
the origin server. There is no way for Squid to open a port on an IP
address that is not assigned to a local interface. Check your cache.log
when you start up, and I bet you will see evidence of this problem.

> https_port 443 cert=/etc/squid/cert/portalcert.pem key=/etc/squid/cert/key.pem defaultsite=www.my-company.org
> cache_peer 192.1.0.59 parent 443 0 no-query originserver ssl login=PASS name=www.my-company.org
> cache_peer 192.1.0.59 parent 8888 0 no-query originserver
>
> visible_hostname www.my-company.org
> acl ourSite dstdomain www.my-company.org
> http_access allow ourSite
>
> # Log file and cache options
> logformat squid %tl %>a:%>p %la:%lp %Ss/%03Hs %<st %rm %ru %Sh/%<A %mt
> cache_dir ufs /var/cache/squid 100 16 256
> cache_swap_low 90
> cache_swap_high 95
> access_log /var/log/squid/access.log squid
> cache_log /var/log/squid/cache.log
> cache_store_log /var/log/squid/store.log
> pid_filename /var/spool/squid/squid.pid
>
> #Cache Manager settings
> http_access allow manager localhost
> http_access deny manager
> http_access deny all
> *******************************************************************
> Thanks,
> Keith
>
>

Chris
Received on Mon Feb 18 2008 - 15:37:17 MST