We have our Mcafee web gateway appliacnces (126.96.36.199.0) setup for WCCP and they ware working fine for all http traffic but for pages over ssl we get page cannot be displayed or page interupted. When i try to use openssl through the gateway we get the following error for all sites
4304:error:140770FCSL routinesSL23_GET_SERVER_HELLO:unknown protocol:
This looks like th gateway is not replying to the SSL connection form the cleint. I have looked at the tcpdump traces for GRE packets and we get a RST for IE or FIN for Firefox cleints
We have the SSL scanner turned on and if we use the box as a direct proxy it all works fine and the SSL scanner is working as it should.
Solved! Go to Solution.
it seems that the proxy wants to speak HTTP instead of HTTPS on that port! Do you have configured a different listener port for HTTP and HTTPS?
the proxys are setup as shown. We have the first proxy that we are using as a direct proxy till we can get the wccp fixed and th second 9091 is the one the wccp is pointing to
seems to be correct. As you do not have provided the HTTP-<number>-S.txt I assume that it will not be written, correct?
I recognized that the browser does not seem to send an SNI header. Can you verify on a client computer that will be redirected via WCCP if it works if the SNI is there?
openssl s_client -connect web.de:443 -servername web.de
You are right there are no http-<number>-S.txt files created
I ran the command above on a pc that has the wccp redirect applied. here are the screenshots
There still is no http-<number>-s.txt files created
You havent by chance been flipping between transparent router mode and WCCP? If so you will need to reboot as there are some kernel modules loaded when you go into transparent router mode.
I do not think the applicances have been ever in transparent mode. i have done some more investigating and found the authentication server was always using port 9091 hard coded for the authentication pages.
this works fine for http traffic but not for https
i then changed this back to the default of
http://$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.ip"/>$:$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.port"/>$
This works for http traffic but the authentication page has the ip address of the site you are going to so the borwser will not pass the login details as that site is not in the trusted list. I guess this is because the block page is being handled by the wccp link as the ip is external. This still will not work for https.
I then changed it to
http://$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.hostname"/>$.xpat.nhs.uk:$<propertyInstance useMostRecentConfiguration="false"
This makes the browser go to the block page with the gateways hostname on port 80 for http traffic but the gateway will not respond as it is not listening/allowing the client to talk on port 80 but this stil does not work for https traffic at all.
Hope this makes sence
This doesnt make sense with your description of the initial issue. The original problem you brought up, was that the MWG wasnt working for HTTPS at all. What happens if you disable all the rules? Does it work then?
Please try this so we can help you better:
Disable all the rules or put a stop cycle rule in for your IP address at the top of the rules, if HTTPS pages still dont load then I beleive you need to restart the appliance.
If HTTPS pages start loading, does disabling authentication server cause things to load properly?