Switch to full style
Use this forum to post questions relating to WinGate, feature requests, technical or configuration problems
Post a reply

Wingate NAT and Hotmail

Dec 22 04 4:26 pm

Dear Sirs,

We are having a problem with Wingate NAT that has just appeared after some months of operation. The Wingate Server is Wingate 6.0.3 (with your diver for XP SP2). Clients connect via WIngate NAT. Everything has workerd quite well for months. Thank you!

Last Thursday, a problem appeared with Hotmail that has persisted since then. Users logging into Hotmail are able to negotiate a login with MS Passport, but unable to view their mailboxes. The network connection to Hotmail times out before the mailbox appears. I drove down to the plant today to check on the situation. I find the problem does not occur with WGIC or the WWW Proxy. However, when connecting with Wingate NAT, the problem occurs 100% of the time on all workstaions.

This problem never occured prior to last Thursday. I have reinstallled Wingate and reinstalled a test client on a previously unformatted hard disk. The problem persists. I have checked for spyware/viruses on the Wingate server and network. There are no viruses or spyware.

Please help.

Kindest Regards,

Bob Tucker

Dec 22 04 4:31 pm

Is that pure NAT or is it being intercepted? We have seen a few people on the forums having trouble with Hotmail and HTTPs connections - so that might be something to keep in mind too.

Dec 23 04 1:07 pm

Dear Pascal,

This is pure NAT. There is no WWW interception. We adopted this configuratin as, heretofore, there were no significant problems associated with it. The problem with Hotmail began precipitously last Thursday and I cannot get rid of it. I expected to find some nasty Spyware or a virus on the Wingate machine. I began by running a Kaspersky scan and then a Symantec Scan, but I found no viruses. I then ran an Ad-Aware scan and a Giant Antivirus Scan (the later being the antispyware product Microsoft just bought). There was some spyware, but nothing significant. Removing the spyware on the Wingate box, other servers, and test workstations did not affect the Hotmail problem on the network.

This site is a power plant in Thailand, and most users with personal web-based email accounts use local Thai language webmail sites. These are not giving any problems. The network is a simple Win2K3 AD domain. Wingate is on a WinXP SP2 (Dual Xeon Intel Mainboard) box. Client DNS is through the Win2K3 AD DNS through forwarders per the suggested setup for Wingate in your KB. What might I try from here? As only NAT connections give this problem, is there a possibility the driver mught be involved? An obvious possibility is that something has changed in Hotmail. MSN is constantly adding advertising. I need to resolve this, and any ideas you might have are most welcome.

I am not forcing Hotmail via HTTPS on the test workstation. I will check this more completely. Any other ideas you have are most welcome.


Kindest Regards,

Bob Tucker

Dec 23 04 1:40 pm

Hi Bob,

The driver is definately involved in NAT connections. So, a few thoughts.

The first is that a Commview capture of a login attempt (Catching both client -> WG Server and WG Server -> hotmail) would be very interesting to see. (You can use any sniffer package you have - even NetPatrol will give you that information) That will tell us if it was WinGate that timed out the connection, if it was because of some other problem with the traffic itself. If you're worried about the privacy of the data you can either use a temporary hotmail account (Set one up just for this scenario) or get the captures, then talk to me on email so I can tell you what to look for, etc.

Secondly, you can try turning on Intercepts and running the test again. This remains the same as NAT with the exception of port 80 traffic being redirected through the proxy. That might provide a temporary band-aid for the problem.

Thirdly, try purging DNS Caches all round. We saw a problem reasonably recently where certain a specific server would keep on giving bad responses. Perhaps one of those type of responses got stuck in a cache somewhere and now any subsequent connection retrieves it from the cache, rather than trying anew.
Post a reply