I think the cipher list is explained here:
I just had a quick look but from what I understand
should be read similar to:
- Allow all cipher suites (except enull ciphers, which do not offer encryption)
- Do not allow ADH (caused by the exclamation mark)
- Move RC4 to the end of the list of ciphers, e.g. use them as the last option
- Sort the list of ciphers by their strength
From the packet capture I do not really see a cipher incompatibility. All I can see is that IE tries to setup an SSL connection and MWG denies access by sending a block page back:
Your requested URL has been blocked by the McAfee Web Gateway URL Filter database
module. The URL is listed in categories that are not allowed by your administrator
at this time.
I would expect an SSL Alert if there was a cipher incompatibility, but I have to check. Do you maybe have a working tcpdump from your IE8/Firefox environment for comparison?
Attached the packet capture for mozilla, you can use the following query on this TCP Dump: ip.src==10.6.11.141 or ip.dst==10.6.11.141
You can see that the client hello in mozilla has proper server name. Whereas Web gateway is unable to receive any server name from IE7 on Winxp. Are there any browser compatibility issues for Reverse proxy?
email@example.com 642.0 K
thank you for the data. The server name is transferred as an TLS extension called "Server Name Indication". This is used to tell Web Gateway the requested server name during the SSL handshake. This is not supported by IE 7, so MWG only knows the IP address of the destination server. I think that you maybe have a rule that looks for the URL and blocks access if the URL does match. Since MWG does not know the server name (as it is not sent by IE 7), the block action is triggered and blocks the request.
You can read more about this at
It points out that Internet Explorer on Windows XP is not capable of sending the SNI extension.
Maybe you will be able to access if you also allow the IP address of the server, instead of the URL only. I can´t tell exactly since I do not know the policy. You need to allow access to the destination IP for the Internet Explorer on XP users.
I hope this helps,
The answer was very helpful, but it points a major inadequacy in Web Gateway 7. A reverse proxy should be able to host a number of webservers; and the appliance can't predict the the server name the client wants to connect to, unless client specifies it. As SNI feature is unavailable in Win XP, clients will never mention the server name, and server will be confused about the certificate to send.
Also since the DNS entries point to Web Gateway's IP instead of web server's, the purpose is still unserved, as Win xp client is effectively sending a CONNECT https://webgateway's_IP_address
In short, a large win xp user base will be deprived of the Reverse Proxy if we go ahead implementing Reverse proxy in its present state. Is McAfee planning any workaround to circumvent this issue, or Is there any OS identifier info, we could use in order to bypass XP users from using Reverse proxy. i.e.: If User's OS == win xp then Don't use Reverse proxy.
did 'I understand you correctly that you want to have one MWG as reverse proxy for different sides? And you modified the DNS entry to point to MWG?
Ok, read it again and my assumptions seem to be correct! Is this possible for you to change the DNS entries to point to different IP addresses that are all hold by MWG?
If a client does not send the SNI, then the proxy uses it's *own* IP in the mapping process for the certificate. So you can define in the ssl client context without ca:
Server - Certificte - Comment
mydomain.com - cert1 - client sends SNI
myotherdomain.com - cert2 - client sends SNI
10.20.30.40 - cert1 - client does not send SNI
10.20.30.41 - cert2 - client does not send SNI
mydomain.com -> 10.20.30.40
myotherdomain.com -> 10.20.30.41
Can't open the attachment.
You guessed the setup correctly. I already implemented the solution you have suggested. It works, but it won't be helpful as I have to route a large number of internal websites through reverse proxy. Therefore my web-server hosting ability of Webwasher will be limited to the number of LAN interfaces my appliance has. Also, which attachment are you unable to open?
Andre/Tyomini: I am going to try configure my appliance in transparent bridge instead of explicit proxy mode as it is now. Do you have any ideas, if it could leverage the Reverse proxy feature to serve my Win XP users.
1 of 1 people found this helpful
you are not limited to the number of LAN interfaces. You can add alias IP addresses for each interface, e.g. eth0 can hold 192.168.1.1, 192.168.1.2, ..., 192.168.1.10. Doing so you can host 10 virtual hosts by IP, you don´t need 10 LAN interfaces. You can use more than 10 IP addresses, of course.
I never set up a transparent bridge reverse proxy so far, so I can´t really tell if that is working fine but I believe it could. MWG sees the original Web Server IP address in the request from the client, and should be able to obtain the host name by talking to the IP address, obtain the certificate and use the CN of the certificate for the host name decision. You may need "transparent common name handling" enabled on MWG.
As mentioned I don´t know, it´s just how I would expect it to work.