cannot connect to https page!!!!

[boon]

hi,

i having a problem which is i cant access to the https website like hotmail account,bank account site.
i already open the port 443 to accept the connection but still unable to solve this problem. for your information, i;m now using wingate version 6.

10q

[Pascal]

Are you connecting through a proxy, using NAT or using WGIC ? If you are using a proxy, try specifying the port in the WWW Proxy Service on the HTTPs tab. (Not 100% sure if that's what you've done)

[nick_mcruk]

HI,

I have the same problem, using wingate 6, no user can connect to any https site. I am using WGIC and the traffic routes through the www proxy.
I havent yet tried specifiying a port in the WWW Proxy Service https tab, which port number(s) do I need to specify?

[Pascal]

Normally port 443.

[nick_mcruk]

I have tried specifying port 443 but this had no effect. Also tried the 'allow any port to be connected' option but it is still not allowing access to https pages.

Nick

[Pascal]

Okay - we're going to have to push this to our test lab. Out of curiosity, does it make a difference if you use a direct proxy / NAT connection ?

[nick_mcruk]

At the moment, all clients using WGIC and web traffic routes through the www proxy. I have a seperate problem which has been unresolved for some time with enabling the ENS and using the NAT, which prevents all connections so I have kept this disabled.

Thanks
Nick

[genie]

What network card do you have installed in ouyr Wingate machine?

[semihbattal]

Hi, We use NAT and had the same problem with https pages after switching to Version 6. Checking the "Automatically Detect Settings" box on the "Internet Explorer connection settings page" on all clients solved our problem...

[adrien]

Make sure also, that you don't try and get the WWW Proxy to intercept port 443.

This would break all SSL connectivity.

SSL through proxies works a different way - the client connects to the proxy still on port 80, then sends a CONNECT command to connect through to the end server on port 443. Once WinGate creates the basic connection, the client then negotiates an SSL connection over it.

Adrien

[nick_mcruk]

Hi,
I tried checking the "Automatically Detect Settings" box on the "Internet Explorer connection settings page"on the client but this did not work, but when I manually it to use a proxy server, ie set the servers IP and port 80 for all, this worked and now allows https access.

[nick_mcruk]

Hi,
I tried checking the "Automatically Detect Settings" box on the "Internet Explorer connection settings page"on the client but this did not work, but when I manually it to use a proxy server, ie set the servers IP and port 80 for all, this worked and now allows https access.

[adrien]

"Automatically detect settings" only works if you are using WinGate as your DNS server, since this relies on a special DNS lookup.

When you select this option in IE, it makes a DNS lookup for the name "WPAD". WinGate's DNS server recognises this, and returns its own IP address. This means if you are using a different DNS server (e.g. Win 2000 AD server or something), then you could actually get auto detect working by putting a DNS record in that server, pointing lookups for the name "WPAD" through to wingate's IP address.

In the end however, Proxy Auto Detect (PAD) only has the effect of setting your browser up to use proxies. If you were wanting to use NAT or WGIC, it kinda defeats the purpose (although it will work).

Adrien

[krhoades]

Was this issue ever resolved? I am also having the same problem. I am using Wingate 6.0.3 with ENS enabled on a Windows Server 2003 machine. The "Allow ANY port to be connected" setting is enabled in the https section of the WWW proxy server settings. Your help would be greatly appreciated in this issue.

[eric_b]

I have exactly the same problem with 6.0.3

Will you correct that ? Please give us some informations.

Thanks.

[Pascal]

I'm running through 6.0.3 and have no difficulties connecting to bank sites (https), etc.

I suspect it'll be something configuration related. How do you have your WinGate clients setup? Are they connecting using NAT, direct proxy connections or WGIC?

If you are using NAT, are you redirecting (Intercepting) from the WWW Proxy Service?

[mykalel]

I, too, have this problem in v6.0.3 (build 1005). I'm using WGIC authentication and all ports are allowed in SSL connections in the WWW Proxy Server (running on port 85).

Any user attempting to connect to a site using SSL gets a blank page, and the proxy server displays a system message as follows:

Authentication failed - user [logged on username] on [IP address of client] requested [web page address]

The ID code on the system message is 0301.

Incidentally, I think the problem might be related to sites using Active Server, as some https sites work fine. The ones I'm having trouble with all seem to use ActiveX components.

[Nev]

I, too, have this problem in v6.0.3 (build 1005). I'm using WGIC authentication and all ports are allowed in SSL connections in the WWW Proxy Server (running on port 85).

Any user attempting to connect to a site using SSL gets a blank page, and the proxy server displays a system message as follows:

Authentication failed - user [logged on username] on [IP address of client] requested [web page address]

The ID code on the system message is 0301.

Incidentally, I think the problem might be related to sites using Active Server, as some https sites work fine. The ones I'm having trouble with all seem to use ActiveX components.

G'day Michael,

Post a link here to the SSL login in difficulty, others can try to track this down as well!

Cheers from wet and rainy Mudgee > YES!

Nev.

[mykalel]

We're a bit soggy on the Central Coast too (not that there's anything wrong with that!).

Some sites that I know we're having problems with are:

http://www.ecommcorporate.com.au/ecomm/
(select Foreign Exchange from the dropdown at the top, then press Go)
System message in wingate reads "authentication failed - user michaell on 192.168.2.192 requested http://www.ecommcorporate.com.au/ecomm/ ... plet.class"

Authentication failed errors are also being reported for:
http://crl.verisign.com/Calss3CodeSigning2001.crl
http://rms.adobe.com/read/0600/win_/ENU ... be0000.xml
http://www.microsoft.com
and many others...

We also run an internal Windows Update server. The proxy is reporting authentication failed for any computer that tries to connect to the server looking for updates.

All clients on my network run Win XP SP2. The proxy runs on a W2K Server with SP4.

[Pascal]

You said you are using WGIC to connect / authenticate / etc. Is it an intercepted connection or not?

What policies do you have setup?

[mykalel]

There is no intercept setting. "Use transparent proxy" is unticked.

The only policy set on the WWW Proxy is that users must be authenticated.

[Pascal]

If the connections are not being intercepted then you should not be affected by the WWW Proxy Policies.

The policy that would be affecting it will be the one for the WRP Service (And potentially the System Policies; depending on how they are set to be included)

This issue is currently with our QA team.

[Pascal]

Okay, QA has gone through it. We could not replicate the same behavior at all. (Same Client+Server OS, etc.)

So:

1. Which userdatabase are you using?
2. Which policies do you have setup for the WRP Service?

Do you have Java installed on your clients? We ran into problems until we did that. Thereafter, everything worked smoothly. If that does not help; can you export and send me your WinGate registry, please?

[mykalel]

We're using the Windows user database.

The WRP service policy is set to "Users can access this service", the "granted to" box is empty, and "Default rights (System policies) may be used instead."

All clients have Sun Java Runtime environment 1.4.2 installed, and most of them use this as their default Java programme for Internet Explorer. Changing the default to Microsoft's Java Virtual Machine does not solve the problem.

[Pascal]

Do you require authentication on your default rights (System policies)?

[mykalel]

In the system policy, Everyone has access restricted by "User must be authenticated". There are no other restrictions, except for "Guest", which is disabled.

[mykalel]

The problem is still occurring. The most obvious example I can give you is www.ecommcorporate.com.au. With the proxy off we can access the login screen. with the proxy on we can't.

I've emailed you the configuration & registry files.

[Pascal]

We're going to try that today. However, when visiting that same website we had no problems (Post installing of Java).

[erwin]

Hi Michael

How exactly are your client machines attempting to access these sites?.
You mentioned they were using WGIC but when we used your registry config here in the lab we found that GDP (what WGIC uses to locate the WinGate server) is disabled.

It also seems that your ENS driver has been manually disabled (which of course disables the WinGate firewall/startup protection completely) . Are you using a third party firewall on the WinGate machine and if so has this been reconfigured to allow SSL type connections properly via WinGate properly.

Using your registry configuration (and making sure WGIC/WRP was working for the client we have tried several different HTTPS connections/site and found we STILL could not reproduce your issue.

We also noticed that your WWW proxy service on port 85 did not have intercepts enabled, (which is required is you want NAT or WGIC clients to be forced through this proxy). Because of this we presumed that your clients had also configured their browsers to use a straight proxy connection, on port 85, and so tried this type of connection as well but still couldnt repro your issue.

Regards
Erwin

[mykalel]

Hi,

Reading back up the thread I think I've confused NTLM authentication with WGIC. Sorry about that.

Our browsers are directly configured with the proxy settings.. using port 85 for all protocols. These settings are set via Group Policy (except for Firefox users, where it is set manually).

As an experiment I uninstalled Wingate last week, then reinstalled it. The only setting I changed was to change port 80 to 85 for the WWW proxy. I also ticked NTLM as the authentication method, and set a System Policy for Everybody to "Must be authenticated".

Even after doing this, the problem still occurs. We continue to get "authentication denied" messages for "guest" for users whose sessions HAVE been authorised with NTLM. The same sites, over and over, fail to work due, I assume, to this authentication failure. We never had this problem when using Wingate 5 and Java authentication.