NAT: large file downloads stall

[redheat]

Hi!

Can anyone help with this issue please?

I have a Windows Xp box with Wingate running as NAT server. Everything works fine but large file transfers. After some time, downloads just stall (be it FTP or HTTP doesn't matter). I played with the connection timeouts in the advanced settings but this didn't help. The connection is still shown as active in the Gatekeeper, but no data is transferred. On the client, the download connection stays alive, but no data..
To me, the time after which downloads stall seems to vary. Very weird issue.

This happened already with Wingate 6.0.4, now I use 6.1.4, same problem. Disabled any firewalls on the system for testing.

The server has one external interface, through which clients connect via VPN. The VPN clients then use the NAT gateway for internet access (through the same external interface of the server), since they are not allowed to access the i-net directly.

Any help appreciated, thanks!

[genie]

Try adding a DWORD value with name ValidateTCPChecksum set to 0 in the following key:
HKLMSYSTEM\CurrentControlSet\Services\QbikHkXP\Parameters

You need to reboot the machine in order for the change to take an effect.

[redheat]

Problem solved, thank you! Great support.

[redheat]

WAIT problem NOT solved!
Large downloads work now, but everything else doesn't!!!
I can't get stable connections with just about anything, games, VOIP, IM... they all connect, disconnect, connect, disconnect.. in a matter of seconds!
This is useless. Any more ideas?

[adrien]

Those things you listed I think all use UDP, so the TCP checksum change you made won't affect them.

I think there is another setting to validate UDP checksums - Gene?

[genie]

I would suggest checking your network card properties and if there is an option to off-load checksum calculation - turn it off.

[redheat]

@adrien: you were right, it was a coincidence. and only a few apps are affected, like icq, but yahoo works strangely.

@genie: the NIC advanced settings don't have this... the adapter help file lists such a setting, but the config tool is for a whole line of NICs.

thanks again for the hints.
don't have time to work on this now, will go back to XP ICS at least for now :-(

[trace]

i have the same problem with big downloads ! :( i even try to reinstal my os and the same problem ! pls help

[trace]

someone answer pls ! all my clients can`t download big files :( i have wingate 6.1.4 on win 2003 server i test with xp to but same problem :( all downloads stops .


Regards

[genie]

Hi, Trace

Have you tried this registry change?

[olaf.krause]

someone answer pls ! all my clients can`t download big files :( i have wingate 6.1.4 on win 2003 server i test with xp to but same problem :( all downloads stops .


Regards

Do you use NAT or HTTP Proxy or SOCKS? If HTTP also with Antivirus plugin?

[trace]

hi olaf.krause

i`m using only nat and all my clients have static ip

[trace]

Hi, Trace

Have you tried this registry change?

yes i tried the reg change but no change ! :( pls help guys !

[jiroscop]

I have this problem too.
Staff pls help.

[trace]

if everybody use bandwidth control the wingate don`t work with big downloads even radio streaming stops ! same :(

[genie]

We are still investigating this download stall problem - it is not easy to reproduce locally.

[kgoodknecht]

We are still investigating this download stall problem - it is not easy to reproduce locally.

I've had this issue for quite some time, too. It doesn't seem to be a problem if you're downloading through the proxy, but there seems to be a limit on the connection time even if the connection is not idle.
I think there is a connection between this issue and playing online games behind behind Wingate.
My son was on me for as long as I can remember because he could not stay connected to Xbox Live or Battle.net to play his online games. I tried disabling Wingate NAT and using Windows NAT on the Wingate server, disabling the Wingate Firewall and every conbination I could think of using the Wingate server as the gateway for his online games. I have two Wingate servers one on Win2k and one on Win2k3, both have the issue and nothing would stop him from getting disconnected after 5 to 10 minutes of play. Along with this, if I tried a download that was more than 5-10MB through Wingate NAT, whether it was FTP or HTTP, the download would stall, if I was lucky I could restart the download from where it left off. I have had better luck downloading large files through Wingate NAT using HTTPS.

The only way I was able to resolve this was to install a Windows Server in Virtual PC, then setup static routes on the Wingate machine that sent connections to the Battle.net and Xbox Live servers through the Virutal Server's NAT. Now he's happy and can play online for hours at a time.
I realize that not everyone can do this, but if you can fix Xbox Live and Battle.net it may resolve this too.

[adrien]

we just found a problem with checksum validation in certain rare cases.

This can result in dropped packets. You are more likely to see this on TCP connections that transmit a lot of data. However UDP and other IP protocols could suffer from this.

We're just testing a fix for this, which looks promising. I'll send an update through soon. We'll make new drivers available prior to release to anyone who wants them.

Regards

Adrien

[kgoodknecht]

we just found a problem with checksum validation in certain rare cases.

This can result in dropped packets. You are more likely to see this on TCP connections that transmit a lot of data. However UDP and other IP protocols could suffer from this.

We're just testing a fix for this, which looks promising. I'll send an update through soon. We'll make new drivers available prior to release to anyone who wants them.

Regards

Adrien

I'm still hoping for a fix for the BSOD with Wingate on Windows 2000 when using RAS.

[genie]

Hi, Kevin

We are still investigating this issue - sorry for the delay.

[genie]

There are XP and 2k test drivers available for download:
XP: http://www.wingate.com/downloads/qbikhkxp.sys
2k: http://www.wingate.com/downloads/qbikhk2k.sys

People with big download problem are advised to give it a try:

- Backup the existing driver (\windows\system32\drivers\qbikhkXX.sys)
- copy the appropriate downloaded driver there
- reboot the machine[/url]

[kgoodknecht]

There are XP and 2k test drivers available for download:
XP: http://www.wingate.com/downloads/qbikhkxp.sys
2k: http://www.wingate.com/downloads/qbikhk2k.sys

People with big download problem are advised to give it a try:

- Backup the existing driver (\windows\system32\drivers\qbikhkXX.sys)
- copy the appropriate downloaded driver there
- reboot the machine[/url]

I no longer get blue screens, but Wingate seems to handle RAS connections diffeently, unless I mark the RAS connection as a DMZ, I can only access the RAS server, even though the RAS interface is on the same subnet as the Private adapter.
When connecting to Win2k Terminal Servers behind Wingate I get a lot of "The connection was ended because of a Network Error" Each time I try to reconnect it creates a new terminal server session. (That's another story) but the real problem is that many times I am not able to fully logon to the session before it is disconnected.
I can see an NAT maping in gatekeeper when I connect to clients behind Wngate, s I beleive this is an issue caused by NAT.

[adrien]

Hi Kevin

For dial-in connections, the interface should be marked as Internal.

If you mark it as DMZ, then for access to other internal networks, NAT will be performed.

I'm wondering if there is a routing issue which is causing the problem.

If the machines on the internal subnet don't know about the IPs being assigned to dial-in users, then if their default gateway is not the WinGate machine, they won't send packets back to WinGate when they receive a connection request routed to them from the dial-in user.

Try tracert from one of the LAN machines to the IP of a dial-in user and you should see where the packets are being routed... if not to WinGate, then there's the problem.

Adrien

[kgoodknecht]

Hi Kevin

For dial-in connections, the interface should be marked as Internal.

If you mark it as DMZ, then for access to other internal networks, NAT will be performed.

Adrien

Yes, I understand this, but if I mark it as internal I can have only one VPN connection at a time. If I have two connected one will stop, I can disconnect the one that stopped routing then reconnect it, routing for that connection works again but the other stops.
The only way I can have two VPNs connected and working is to mark the incoming connections as a DMZ, then use NAT to the internal network.
It is getting better because previously just connecting two VPNs as soon as I tried connecting to a server behind Wingate the Wingate server Blue Screened and I had two Win2k/VPN/Wingate servers doing the same.

I'm wondering if there is a routing issue which is causing the problem.

If the machines on the internal subnet don't know about the IPs being assigned to dial-in users, then if their default gateway is not the WinGate machine, they won't send packets back to WinGate when they receive a connection request routed to them from the dial-in user.

Try tracert from one of the LAN machines to the IP of a dial-in user and you should see where the packets are being routed... if not to WinGate, then there's the problem.

Adrien

I will email relevant routing tables from all machines.

[adrien]

Hi Kevin

Thanks for that further information. Looks like a routing issue / bug with WinGate's driver.

The key is the second dial-in connection.

It now makes sense to me why NAT works and routing doesn't. NAT remembers which interface to send packets on for each connection, whereas routing doesn't create an entry for this, and relies on the route table for each packet.

So if WinGate is not picking up the correct interface to send packets out to, then outbound routed packets (i.e. return packets from the LAN to the dial-in clients) may be mis-routed.

THe odd thing is that the route table specifies the same outbound interface to be used for both dial-in clients - 192.168.201.80.

I think you'll find even with DMZ/NAT, that only incoming connections from the dial-in clients operate properly. Connections from the LAN will work to the second one, but not the first.

A possible workaround would be to enable routing in the OS, and disable routing in WinGate. That way packets will just go up the stack and be directed to the correct RAS interface (hopefully) by the OS.

I'l have the test lab set up a scenario to validate this so we can fix it.

Adrien

[kgoodknecht]

Hi Kevin

Thanks for that further information. Looks like a routing issue / bug with WinGate's driver.

The key is the second dial-in connection.

It now makes sense to me why NAT works and routing doesn't. NAT remembers which interface to send packets on for each connection, whereas routing doesn't create an entry for this, and relies on the route table for each packet.

So if WinGate is not picking up the correct interface to send packets out to, then outbound routed packets (i.e. return packets from the LAN to the dial-in clients) may be mis-routed.

THe odd thing is that the route table specifies the same outbound interface to be used for both dial-in clients - 192.168.201.80.

I think you'll find even with DMZ/NAT, that only incoming connections from the dial-in clients operate properly. Connections from the LAN will work to the second one, but not the first.

A possible workaround would be to enable routing in the OS, and disable routing in WinGate. That way packets will just go up the stack and be directed to the correct RAS interface (hopefully) by the OS.

I'l have the test lab set up a scenario to validate this so we can fix it.

Adrien

That interface is the RAS server's Internal interface, its IP varies depending on what my DHCP server assigns it. AFAIK, there is no way to assign it a static IP. If I give RAS a static list of IP addreses to use the RAS interface is usually the first IP in the list.

I realy need to keep NAT in Wingate to take advantage of the proxy redirection on outgoing connections on port 80, 21, 25 and 110. And what ever port I deem necessary to redirect to internal servers.

PPP adapter RAS Server (Dial In) Interface:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-45-00-00-00
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.201.80
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 127.0.0.1
NetBIOS over Tcpip. . . . . . . . : Disabled

[adrien]

WinGate will still do NAT ok if you disable routing in WinGate.

It's the setting called "Enable support for multiple subnetworks".

If you disable this, then if WinGate ENS finds packets that aren't to be translated (i.e. they aren't destined for a default gateway, or going out an external interface), then it will simply let the packet up the stack. Then the OS will receive it, and if routing is enabled in the OS, it should then actually work.

NAT and everything else should still work as well - it's not dependent on this setting.

Adrien

[kgoodknecht]

WinGate will still do NAT ok if you disable routing in WinGate.

It's the setting called "Enable support for multiple subnetworks".

If you disable this, then if WinGate ENS finds packets that aren't to be translated (i.e. they aren't destined for a default gateway, or going out an external interface), then it will simply let the packet up the stack. Then the OS will receive it, and if routing is enabled in the OS, it should then actually work.

NAT and everything else should still work as well - it's not dependent on this setting.

Adrien

I wish could say this worked perfectly, I was up until 4AM this morning testing and retesting with the OS routing and Wingate routing, setting up static routes it seemed nothing I did worked. So I took another look at it today the VPN worked perfectly with Wingate stopped, as soon as Wngate started the routes would break.
So I did some testing with the Wingate firewall and found that it is the firewall breaking the connection. I set one of the external routers with a ping -t and found that even though the firewall wasn't logging any blocks, I'd turn the firewall off and the pings were returned, turn it on and they stopped, just like turning a switch on and off. This was with the RAS incomming connection marked as internal as they should be.

[adrien]

Hi

I've just been looking at this in the lab.

there was a change we made to the driver that I'd forgotten about which breaks os-based routing even if WinGate routing is turned off. we patched that out in a test driver, and we were then able to communicate from a local network to several dial-in VPN clients.

I can send you another driver to test if you like. I'm pretty sure this one will work.

Adrien

[kgoodknecht]

Hi

I've just been looking at this in the lab.

there was a change we made to the driver that I'd forgotten about which breaks os-based routing even if WinGate routing is turned off. we patched that out in a test driver, and we were then able to communicate from a local network to several dial-in VPN clients.

I can send you another driver to test if you like. I'm pretty sure this one will work.

Adrien

Sure send it to me, it will be tomorrow afternoon (18 hrs from now) before I can test it. I have I have to take my son to school at 7AM and appointments with clients in the morning.