Unfortunately I don't have time to test myself but if you can run a tcpdump on the appliance whilst replicating this would help determine the cause.
In the GUI at Troubleshooting > Packet tracing run with the following command line parameters:
-s 0 -i any
Please post the capture here and one of us can review it.
Make sure to tell us what IP address are used for the client and MWG.
Make sure your Global White list is on top of all your Rule Sets.
Also put a * after the url in the whitelist. *.rois.com*
Changed whitelist to *.rois.com*, still doesn't work, anybody any other ideas ?
Ok so what we have here is a non-rfc compliant response from the host therefore the Web Gateway gives a 502 Bad Gateway Error.
In HTTP 1.1 all headers must be ended with a carriage return and a line feed \r \n
If you take a look at the screen shot packet #936 the HTTP response from the host kinda looks mangled.
If you look up the RFC for HTTP 1.1 response you can tell in they are missing the first carriage return \r at the first line then the Content-Type header has two line feeds \n \n.
I have tried this on Web Gateway 188.8.131.52 and it works. You may want to upgrade on a test environment before deploying to production but I am positive this will work.
non-rfc.png 72.9 K
I have several sites that exhibit the same problem and a couple have been found to be related to non-rfc compliance. My discovery came when I tested by running a particular website through the 6.8 rev and it worked fine.
Is McAfee going to make allowances in the 7.0 rev for scenarios such as this??? The need for standards compliance is understood, but while its nice to know our WG is up to par, it seems a little bold to think that everyone/everything on the Internet is going to follow the same model. Furthermore, it causes quite a bit of headache to have to call into support/development for these situations since there's really nothing that even the most experienced WG admin can do.
I'm running 184.108.40.206 and just had another non-rfc issue yesterday.
Thanks for looking at this, I also logged it with support and got the same recommendation to upgrade to 220.127.116.11, did both nodes over the weekend and so far it looks good
How do you know the issue you experience was a non RFC compliance HTTP response?
The error message 'Bad Gateway - Cannot Connect to Host' is a generic HTTP response and can be caused by many issues.
If you feel that 18.104.22.168 did not resolve this particular issue please open a case with support.
This definately sounds like the issue I am having, where exactly do I make these changes. I've already upgraded to 22.214.171.124 and still get the Bad Gateway messages.
I'm kinda a noob, so I need baby step instructions! Thanks!