This is driving me nuts!

I'm trying to set up a RHEL box in a DMZ to act as a proxy server for other machines in the LAN. The idea is that all the other machines won't have direct internet access, they'll all have to go through the proxy as the single point of internet access. We have installed a Juniper SRX firewall and the zones and security policies have been set up to allow the squid proxy full internet access via a NATed IP.

What works:

- Direct internet access from the squid box (bypassing proxy)

- Proxy access from the squid box works (so firefox has localhost as proxy address to use with default port 3128).

However, trying to use any other machine with the proxy does not work. I get either garbage data, a 400 bad request or the proxy returns an html page saying that the url is invalid.

This is even with a machine in the same DMZ subnet as the squid box so it's not a routing issue.

Basic settings:

- default squid proxy 3.1 configuration file (so it permits the used IPs). Running RHEL 5.8.

- firewalls, etc, all configured to allow content

Any ideas where to start looking?

Hmm, after a bit of digging, it looks like the "garbage" appears only on routed proxy traffic (client on different subnet to squid proxy server)

the "Error" page appears only when client is on the same subnet as the squid proxy server:

I've edited out the end of the FQDN for anonymity.

For a start, HTTP/1.1 isn't a valid URL, so if that's the page your Squid proxy is being asked for then something's going horribly wrong somewhere...does the SRX do any kind of packet inspection itself? As it seems to me like the HTTP requests could be getting mangled before even making it to Squid, for example, my client sends

GET / HTTP/1.1

Host: www.google.com

which is the correct string for fetching Google via HTTP 1.1 rather than 1.0. But it seems that what Squid is receiving is simply "GET HTTP/1.1" with the URL stripped, and then it's treating "HTTP/1.1" as the URL (which is the correct way to handle a GET request with a single parameter) which obviously isn't valid. Not sure what would cause the URL to be stripped from the middle of the string though, if it was on the end it would make more sense, but in an HTTP GET the URL is the first parameter. Since you say you're using the stock Squid configs, I'm guessing these have been tested properly as working, which leads me to point to the firewall device and any layer 7 packet inspection it might be doing. Bit of a stab in the dark but without seeing all the configs and network setup, it's the only thing that makes sense to me atm...

edit - edited connection string, as it was incorrect

Hmm, I think it's because the Squid box is behind the firewall and gets to the net via NAT (provided by the firewall).

What I have is this setup:

And reading up, it sounds like Squid has to have a direct net IP and cannot go through a firewall / NAT unless you configure a forwarding proxy which I don't have.

So whilst browsing via the proxy on the squid box itself is OK and works (and I can see the logs all good), if it's another machine, then it falls apart.

Now it's working.

And I haven't changed anything.

Or rather, the only thing I changed was upgraded our ESXi hypervisors to Update 1 (vSphere 5 Update 1).

I had already come across a few bugs with the initial release, looks like this might have been another.

Ah, I see. When you said your Squid proxy was in a DMZ, I was assuming this was on its own DMZ network hung off the SRX directly (i.e. so that even your internal traffic has to pass through the SRX to get into the DMZ, rather than what you pictured). I'm pretty sure that Squid can work while behind NAT, I've seen several guides on how to set it up on home Linux systems for downloading/caching Linux updates, improving web surfing on shared connections, etc. I've never done it myself mind, but I've definitely read use cases of Squid which are for home use, implying NAT.

I can confirm that I've run Squid behind a home DSL connection and worked a treat.

We use Microsoft TMG as a proxy only (no incoming external connection), works great and its running on VMWare ESXi 4.1 with all the latest updates. We have yet to venture into Vsphere 5.

Well, I've now had three instances with the initial release of vSphere 5.0.0 on HP G7 blade server hardware having issues, all three related to networking in some way.

One of them does some wierd stuff with UDP traffic if you're using VMXNET3 interfaces (go back to emulated intel ones and you're fine).

Another didn't manage VLAN tagging to the host, only untagged traffic worked.

And then this strange thing with the proxy.

Now we've updated to 5.0.0 Update 1 build 639890, it all seems to be ok...