Before I post the site, I want to explain our use of WebWasher. We are a public library system and use the product for our public internet computers. Most of the sites visited are sites people would normally view from home, not sites you would expect to see viewed in a typical business setting. We only block categories such as pornography, nudity, sexual materials and malicious sites.
The website we are having problems with and getting daily complaints from customers is http://payday411.com/
When you type a zipcode and click "Go", it just refreshed the page and returns to the same URL. If I try to access the site using a direct connection to the internet, it works fine, I get a results URL such as: http://payday411.com/list.php?p=46206352&z1=73102&z2=Oklahoma%20City&z3=OK
I looked at the site using Firebug and notice there is a "302 found" result for the longer URL listed above (see image below). I'm guessing this has something to do with it, but can't figure out how to use this information to allow the site to work.
Solved! Go to Solution.
I think I found a solution to this problem, as I had the same behavior on my MWG box.
Create a rule like the following :
In case that second image is small, Under the events tab, add an event called "Header.RemoveAll()
When adding it click parameters and in the value section put "x-forwarded-for" .
This worked for me, but, I'm also in a transparent proxy, so YMMV
the 302 sounds interesting. Can you send some screenshots of the expanded firebug view? I would like to see that URL is returned for the 302 response. There should be a "Location" header that tells the browser where to go when following the 302. Can you tell where it points to?
so the response from the server really tells the browser to go to "/", thats why you end up on the original page again. I have just tried to replicate the issue in my lab, but it seems that at the moment whatever I do (with or without MWG) I see the same issue and get redirected to "/".
I am pretty sure that I was able to search for a Zip code yesterday. Maybe this is a temporary problem with the web site? Can you verify again that it is working fine without MWG? If it does, do you think you can make a test with an entry in the global whitelist, just to see if it makes a difference?
I just tested again and it still works fine if I have a direct connection to the internet but running through the proxy it redirects to the original page again. I added the site to the Global Whitelist as you requested, but it didn't make any difference.
unfortunately I still can't get it to work even without MWG. This makes it pretty hard to find out what is going on. Do you think you have any chance to capture the traffic and send me the dumps? If you have a Windows PC you could use Wireshark to capture the communication when your browser talks to the web site.
You could grab the tool from http://www.wireshark.org/ . There is some video material that shows how to capture traffic You could start with http://wiresharkdownloads.riverbed.com/video/wireshark/introduction-to-wireshark/ .
It would be helpful if you can capture an attempt to talk to the web site without MWG in the loop. There must be something different which causes the server to respond in a different way. I am not sure why I can't access without MWG from here, maybe the web site is restricted to source IPs from the US or similar.
Do you think you can do the capture?
cool. You can upload it to our FTP Server, which only has write permissions for the public, so no one (except McAfee support staff) can retrieve it:
Just upload it and send me the filename via PM.
If you like you can also use SCP:
... and let me know the filename please :-)
I looked into the dumps but unfortunately I still can´t tell why the site is not working. I have tried to access the website using the same browser etc as visible on your packet capture and even tried to replay the packets, but I am always redirected back to the start website.
I can only imagine that the site is maybe restricted and it does not like that I am coming from a foreign country. I only have two things left:
1.) You can try to create an event which calls the "Enable HTTP Tunnel" event for this URL. This will make sure that MWG does not touch the traffic at all and it also leaves compression in place, which is otherwise removed by MWG. It would be interesting to see if this changes anything.
2.) If this does not help as well I would recommend to open a service request with technical support. They will have better capabilities to troubleshoot the issue most likely. Since they are also working from the US maybe they have more luck in replicating the issue.
Are there any instructions on how to create the event that calls the "Enable HTTP Tunnel" event for that URL? I think I found how to do it based on another thread in this forum, except I don't know where to add it. Do I add it to the URL Filtering Ruleset? If so, do I add it to the top of the list?