Author Topic: Routers & ports firewalls - Oh, my!  (Read 10563 times)

0 Members and 1 Guest are viewing this topic.

Offline LeoNeeson

  • Insane poster
  • *****
  • Posts: 433
  • Solitario...
    • View Profile
    • twitter.com/LeoNeeson
Re: Routers & ports firewalls - Oh, my!
« Reply #15 on: April 22, 2015, 09:00:03 PM »
@fdiskMBR: Enabling "DMZ" is a big security risk, since you are opening all ports, and any services or vulnerabilities that exist on that machine are fully exposed to the internet. Only enable "DMZ" for testings, then disable it. When using individual "Port Forwarding", you're only opening the port you need, for the purpose of hosting a service (ie: FTP server, file server).

I would like to agree with bmartino1, but I can't. I do not recommend enable DMZ, since that will NOT solve your speed problems (enabling DMZ may help if you are dealing with BitTorrent or eMule, but not with HFS). DMZ makes your PC fully and directly open to internet, but will not make your connection faster. If your server is working (and you can transfer files with friends over the internet), it means you have the correct ports open already, so you don't need to touch DMZ.

I seriously recommend you try another HTTP server (and not HFS based), because I'm 99% sure you will get the same speed, because it's an ISP problem. If you get the same speed with another software, you can be sure it's not your internal network fault.

I do not like to do this, because HFS is better than any other HTTP server (IMHO), but you can try "Easy File Sharing Web Server". It's not free, but you can test it for free, and see if your speed problem continues.

Code: [Select]
http://www.sharing-file.com/
Good luck... ;)
• HFS ahora también disponible en Español! (Clic aqui) :)
• HFS is now also available in Spanish! (Click here)

Follow members gave a thank to your post:


Offline bmartino1

  • Insane poster
  • *****
  • Posts: 750
  • I'm only trying to help i mean no offense.
    • View Profile
    • none - google translate
Re: Routers & ports firewalls - Oh, my!
« Reply #16 on: April 24, 2015, 05:45:29 PM »
I agree with Leo on this(only use DMZ for testing!, if its works better then its a port problem...), form the sounds of your last post...(I don't think it is the ISP, it could be thought!)... I think it is due to your network still being on Ethernet Speeds / purposing limiting your LAN bandwidth on the other machines.

Practically over the internet downloading an iso image: (lets say Ubuntu iso...)
A 600 MB file will still take about 15-30 MIN maybe even longer at your current allotted bandwidth form your ISP over the internet.

BUT -- Since you intranet (the network setup that all you machine connect to before the internet) is running at Ethernet speed, a 600 MB file can take up to 1-2 hours maybe a little bit faster... there go your "speed issue"

as for a second web server test, i'm not family with the program LEO mentioned, but her is a setup for a free opwn source project --(there are many variety of it!) XAMPP Apache + MySQL + PHP + Perl (Apache web server for windows) https://www.apachefriends.org/index.html
« Last Edit: April 24, 2015, 05:49:31 PM by bmartino1 »
I'm only trying to help i mean no offense.
thank you for your time and patience,
Bmartino1

Offline fdiskMBR

  • Regular poster
  • **
  • Posts: 16
    • View Profile
Re: Routers & ports firewalls - Oh, my!
« Reply #17 on: April 28, 2015, 05:17:26 AM »
Getting a little more detailed it would seem that the rwin value is automatically adjusted in windows 7. (not that it works)
That presents a serious problem to the hfs server. (in the case of vista & win 7) It limits uploading speed of your hsf server no matter how fast a broadband speed you have OR how fast the clients connection to the hsf server is.

Which now has me wondering about FTP and what the fix would be in win7 or vista since it's an OS limitation.

The rwin is limited to 65535.
The rwin should be about 1045440.

As you can see, win 7 & vista have automatic throttling and a max rwin size of 65535 which limits the servers functionality.
There are "go around's" but not for the common user as they're very technical & tedious.

The information is here if anyone cares to look but I would caution you about the optimizer. If you read "carefully" you'll see that the optimizer when set to "optimal" will adjust some settings contradictory to the statements made by the writer. If you dare, you'll need to "manually" choose all the settings for proper functionality.
http://www.speedguide.net/articles/windows-7-vista-2008-tweaks-2574

Microsoft is aware of the issue and has made some patch's for 2008 Server, Vista and provided information for Win 7. None of these provide the fix for to the issue. From what I can find, speedguide's Optimizer is the only real option.  See the links.

Seems the corp techs are struggling with this also > http://serverfault.com/questions/608060/windows-tcp-window-scaling-hitting-plateau-too-early

I'm a little surprised someone has not mentioned this here as it has a direct effect on hsf and it's functionality.
Did I miss this somewhere?

 

 

Follow members gave a thank to your post:


Offline LeoNeeson

  • Insane poster
  • *****
  • Posts: 433
  • Solitario...
    • View Profile
    • twitter.com/LeoNeeson
Re: Routers & ports firewalls - Oh, my!
« Reply #18 on: April 29, 2015, 02:23:54 AM »
I personally don't have access to such speeds over here. But it's interesting that more HFS users with similar speeds, make further tests. I don't know if in Italy, Rejetto has similar speeds to make tests. Anyway, like you say, this is a Win7/Vista OS limitation, not directly a HFS problem.

I was searching for RWIN Tweaking tools, and I did found some interesting links about it (I didn't test any of these, because I don't need to):

DrTCP & Tweak Test:
Code: [Select]
http://www.dslreports.com/tweaks/RWIN
http://www.dslreports.com/tools
http://www.dslreports.com/faq/8159
http://www.dslreports.com/faq/5699
http://www.dslreports.com/faq/bellsouth/5.0_Connection_and_Tweaking
https://web.archive.org/web/*/http://www.dslreports.com/drtcp

SpeedGuide TCP Optimizer:
Code: [Select]
http://www.speedguide.net/downloads.php
http://www.neowin.net/forum/topic/1026386-speedguide-tcp-optimizer-308/

SpeedGuide TCP/IP Analyzer:
Code: [Select]
http://www.speedguide.net:8080/
http://www.speedguide.net/analyzer.php

How to increase your Network Speed or Internet Speed by over 20%:
Code: [Select]
http://www.addictivetips.com/windows-tips/how-to-increase-your-network-speed-or-internet-speed-by-over-20/
TCP tuning:
Code: [Select]
http://en.wikipedia.org/wiki/TCP_tuning
« Last Edit: April 29, 2015, 02:32:04 AM by LeoNeeson »
• HFS ahora también disponible en Español! (Clic aqui) :)
• HFS is now also available in Spanish! (Click here)

Offline fdiskMBR

  • Regular poster
  • **
  • Posts: 16
    • View Profile
Re: Routers & ports firewalls - Oh, my!
« Reply #19 on: April 29, 2015, 07:52:07 AM »
LeoNeeson:
Some of the links you posted are for earlier Windows operating systems that do not have automatically capped RWIN scaling. 

I must caution those who are following the same rabbit trail as I have here.
The information being discussed here pertains to Vista & Win 7 (32/64) and possibly newer Windows os versions. 
You must look carefully to see which operating system any link or reference here may be discussing!


"Why is it that if I have 3 simultaneous connections from 3 different clients I'm able to see 3 times the upload speed in the hfs window as I would see with just 1 individual upload"  :o
To be more specific:   
It would then seem that either there is a cap on each individual client IP download from the hfs server OR the server window is not accurately showing the speed.   ie. 1 client downloads @ 230 while  3 simultaneous clients download @ 230 each. The total 3 client simultaneous download speed being 690.
Why is a single client unable to download from the server @ 690?
I'll try to do some more detailed testing in the next week and get back to this post.

 
« Last Edit: April 29, 2015, 10:06:16 AM by fdiskMBR »

Offline bmartino1

  • Insane poster
  • *****
  • Posts: 750
  • I'm only trying to help i mean no offense.
    • View Profile
    • none - google translate
Re: Routers & ports firewalls - Oh, my!
« Reply #20 on: April 29, 2015, 10:12:02 AM »
in regards to rwin:

it can be edited!...
(Create a SYSTEM RESTORE!) - this can break your machine!

http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/how-do-you-reduce-tcp-rwin-in-windows-7-to/a46599a0-eb4f-40dd-a9c3-301c2e3c6b33

http://www.speedguide.net/articles/windows-7-vista-2008-tweaks-2574

* http://answers.microsoft.com/en-us/windows/forum/windows_vista-networking/rwin-tcp-window-size-problem/1544522d-386b-4ff5-92b7-dff1cc3d7a22

--------example of one!-------------
QoS Reserved Bandwidth
As with Windows XP, network adapters have a "QoS Packet Scheduler" enabled by default, which reserves 20% of bandwidth by default for QoS applications that request priority traffic. Note this only has effect in the presence of running QoS applications that request priority traffic. Registry value is undocumented for the Vista version of Windows. To customize this setting, in the Windows Registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched
NonBestEffortLimit=0 (DWORD, not present in the registry by default. Recommended: 0 , possible values between 0 and 100) - indicates the percentage value of reserved bandwidth for QoS applications. Set to 0 to disable.

Notes: This tweak applies only to Windows versions that have Qos Packet Scheduler enabled. It will ONLY have effect in the presence of running QoS applications.(windows update...etc...)

... Good luck!

in regards to your multiple downlaods/uplaods:
It is also due to rwin in the fact on waht allocation of bandwidth due they have...

RWIN is a multiple of MSS
Other RWIN values that might work well with your current MTU/MSS:
63888  (up to 2 Mbit lines, depending on latency(ping MS and/or ttl hops). MSS * 44)
127776 (1-5 Mbit lines, depending on latency. MSS * 44 * 2)
255552 (2-14 Mbit lines, depending on latency. MSS * 44 * 2^2)
511104 (8-30 Mbit lines, depending on latency. MSS * 44 * 2^3)
1022208 (25-60 Mbit lines depending on latency. MSS * 44 * 2^4)
« Last Edit: April 29, 2015, 10:23:40 AM by bmartino1 »
I'm only trying to help i mean no offense.
thank you for your time and patience,
Bmartino1

Offline bmartino1

  • Insane poster
  • *****
  • Posts: 750
  • I'm only trying to help i mean no offense.
    • View Profile
    • none - google translate
Re: Routers & ports firewalls - Oh, my!
« Reply #21 on: April 29, 2015, 10:43:41 AM »
http://www.speedguide.net/articles/windows-7-vista-2008-tweaks-2574

(this here is all that you mainly need to test and edit....) (open good old comand prompt -- run as administrator!)

Check the TCP/IP state
To check the current status of the Vista TCP/IP tweakable parameters, in elevated command prompt type the following command:

netsh int tcp show global

You will be presented with something like the following:



The settings, as well as their default and recommended state are explained below. The two most important tweakable parameters are "Auto-Tuning Level" and "Congestion Control Provider".

When checking the TCP state with the "netsh int tcp show global" command, it is also possible to see the following message below all those parameters:

** The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any local/policy configuration on at least one profile.

It is displayed when the "Receive Window Auto-Tuning Level" is not explicitly set, or if the system deemed it necessary to make a change because of user prompted "repairing" of your network connection, for example.



Disable Windows Scaling heuristics
Windows Vista/7 has the ability to automatically change its own TCP Window auto-tuning behavior to a more conservative state regardless of any user settings. It is possible for Windows to override the autotuninlevel even after an user sets their custom TCP auto-tuning level. When that behavior occurs, it can have a very noticeable negative impact on throughput, and it does not automatically correct itself. If auto-tuning gets limited, the "netsh int tcp show global" command displays the following message:

** The above autotuninglevel setting is the result of Windows Scaling heuristics
overriding any local/policy configuration on at least one profile.

To prevent that behavior and enforce any user-set TCP Window auto-tuning level, you should execute the following command:

netsh int tcp set heuristics disabled

possible settings are: disabled,enabled,default (sets to the Windows default state)
recommended: disabled (to retain user-set auto-tuning level)

Note this should be executed in elevated command prompt (with admin priviledges) before setting the autotuninlevel in next section. If the command is accepted by the OS you will see an "Ok." on a new line.

The corresponding Registry value (not necessary to edit if setting via netsh) is located in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters
EnableWsd=0   (default: 1, recommended: 0)

Note: This automatic limitation of the TCP Window usually occurs in the presence of some packet loss, which can be common in longer transfers and server applications.



TCP Auto-Tuning
To turn off the default RWIN auto tuning behavior, (in elevated command prompt) type:

netsh int tcp set global autotuninglevel=disabled

The default auto-tuning level is "normal", and the possible settings for the above command are:

disabled: uses a fixed value for the tcp receive window. Limits it to 64KB (limited at 65535).
highlyrestricted: allows the receive window to grow beyond its default value, very conservatively
restricted: somewhat restricted growth of the tcp receive window beyond its default value
normal: default value, allows the receive window to grow to accommodate most conditions
experimental: allows the receive window to grow to accommodate extreme scenarios (not recommended, it can degrade performance in common scenarios, only intended for research purposes. It enables RWIN values of over 16 MB)

Our recommendation: normal  (unless you're experiencing problems).

If you're experiencing problems with your NAT router or SPI firewall, try the "restricted", "highlyrestricted", or even "disabled" state.

Notes:
- Reportedly, some older residential NAT routers with a SPI firewall may have problems with enabled tcp auto-tuning in it's "normal" state, resulting in slow speeds, packet loss, reduced network performance in general.
- auto-tuning also causes problems with really old routers that do not support TCP Windows scaling. See MSKB 935400
- netsh set commands take effect immediately after executing, there is no need to reboot.
- sometimes when using "normal" mode and long lasting connections (p2p software / torrents), tcp windows can get very large and consume too much resources, if you're experiencing problems try a more conservative (restricted) setting.

If you're experiencing problems with Auto-Tuning, see also:
MSKB 835400 - email issues
MSKB 934430 - network connectivity behind firewall problems
MSKB 940646 - 3G WWAN throughput issues
MSKB 929868 - web browsing issues
MSKB 932170 - slow network file transfer



I'm only trying to help i mean no offense.
thank you for your time and patience,
Bmartino1

Offline fdiskMBR

  • Regular poster
  • **
  • Posts: 16
    • View Profile
Re: Routers & ports firewalls - Oh, my!
« Reply #22 on: April 29, 2015, 10:55:49 AM »
The restore point is a given. A boot disk and acronis full system backup is a necessity ;)

On the microsoft link with the MVP, the poster never replied "if it worked OR iif it didn't".  The simplicity of this answer sums it up...
"It is amazing how the "Support Engineers" can't answer a smiple question: Can you manually set the RWIN or TCP Window Size on Vista 64? If so, how?"

As far as qos goes, I see by selecting "0" it will increase bandwidth by up to 20%.
Lets see..... 230 + 20% = 276 >>>>> That's NOT 630 although I'll implement that also if it doesn't impede the Optimizer settings implied.

Thank you for the input! 

After seeing your last post:
I saw that also and it was the direction I was about to take :)
Thanks again!
« Last Edit: April 29, 2015, 10:58:33 AM by fdiskMBR »

Offline rejetto

  • Administrator
  • Insane programmer
  • *
  • Posts: 12844
    • View Profile
Re: Routers & ports firewalls - Oh, my!
« Reply #23 on: May 01, 2015, 04:28:40 PM »
1. did you already look if you have something enabled in Menu > limits ?
2. did you then test ftp speed?

Offline fdiskMBR

  • Regular poster
  • **
  • Posts: 16
    • View Profile
Re: Routers & ports firewalls - Oh, my!
« Reply #24 on: May 02, 2015, 08:58:43 AM »
1. did you already look if you have something enabled in Menu > limits ?
2. did you then test ftp speed?

No limits set in menu.
No "FTP" transfer test, http transfer tests have been shown in this thread.

I'll detail and take pictures of "FTP" speeds and "http transfer speeds" along with differences each windows setting makes when I get time to focus on this issue only.
Like you, my time is also limited.

Thank you for your software work.

« Last Edit: May 02, 2015, 09:02:01 AM by fdiskMBR »

Offline rejetto

  • Administrator
  • Insane programmer
  • *
  • Posts: 12844
    • View Profile
Re: Routers & ports firewalls - Oh, my!
« Reply #25 on: May 03, 2015, 03:24:55 AM »
ok, i didn't mean to focus on ftp, as any single-stream tcp test would be ok to me (torrent isn't single-stream for example).
I wanted to know if a download test was made with a different software than HFS. I didn't notice any such result reading your posts but i may have overlooked.

Offline fdiskMBR

  • Regular poster
  • **
  • Posts: 16
    • View Profile
Re: Routers & ports firewalls - Oh, my!
« Reply #26 on: May 11, 2015, 07:54:14 AM »
Very frustrating.
Tweaked win 7 pro.
Same result on hfs and a like result with ftp which makes me believe it's not an hfs issue.

There's something very wrong here but I just can't put my finger on it yet.
I'll get back to this again when I have more time.

Thanks for the help.


« Last Edit: May 11, 2015, 10:31:19 AM by fdiskMBR »

Offline j7n

  • Occasional poster
  • *
  • Posts: 8
    • View Profile
Re: Routers & ports firewalls - Oh, my!
« Reply #27 on: May 28, 2015, 08:33:46 PM »
This is an interesting thread. I have been tackling this problem in the past, and have not completely solved it for HTTP servers. (Lighttpd is dog slow.)

Thank you for the link to speedtest.tele2.net I will make good use of it. Most other sites use heavy HTML or Flash, which might be the bottleneck. Another good site for download only is LeaseWeb bins. My ping to tele2 (Sweden) is 9ms, and I'm getting between 9 and 10 MB/s upload. What is your ping to it? What is your ping to the client whose address is obstructed?

TCP has two windows, the receive window and the send window (or congestion window). They are controlled by the client and server respectively. The amount of data in transit is limited by the smallest of these values. You have no direct control over the RWIN of your clients. They could choose to allocate more or less memory, enable or disable auto tuning. If the client has a receive window of 64K, he will download slowly regardless of your tunings. Your RWIN is only a factor when you download from overseas or when clients upload to you. The most you can do is control your transmit buffer.

The send window is set by the operating system and can also be limited by the application when it creates a socket. (For example, FileZilla Server has an option for "Socket buffer size"). I do not know how HFS manages this, because I've just started using this program.

In Win2K/XP the OS setting is (I am unsure if it has an effect in later versions):

Code: [Select]
REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters]
"DefaultReceiveWindow"=dword:0003ebc0
"DefaultSendWindow"=dword:00040000

In WinNT 6 Vista/Seven/2008 the setting is:

Code: [Select]
netsh int tcp set global congestionprovider=ctcp
In WinNT 6.1 another setting controls how rapidly the send window can expand:
Code: [Select]
netsh interface tcp set supplemental template=custom icw=10 enablecwndrestart=disabled
netsh interface tcp set supplemental template=custom


Quote from: fdiskMBR
All wan - intranet speed tests are showing 59 Mb/s download & 62 Mb/s upload.
Hard wired lan/router 10/100 set at 100.
This looks correct. Your router can pass through 60 Mbit as proven by speedtest.net. Although, it possible that a "duplex mismatch" could occur if you forced only one end of the link to a certain speed. Or, if you left the LAN at 1 Gbit, the traffic could get bursty reaching a gigabit speed for short periods of time and overwhelming the receive buffer in the router. Best results will be achieved if the whole system is either FE or GbE. It is not happening here, because the OS never reaches a high enough upload speed.

Maybe try temporarily disabling any security software like firewalls and antiviruses and test again. What was the socket buffer size in FileZilla when you tested the upload to tele2?

Quote
I was about to call and update to a gigabit router BUT than I stumbled across 46 pages of............
This is rather odd. A fiber connection should allow buffers with window scaling to reach good overseas speed. If I understand this correctly, the current RWIN and scalefactor is part of the packet which a firewall/router can read and react to. But the send window, which limits your upload, is not explicitly transmitted. It can only be inferred from the rate at which packets leave your server.

Quote
More than half the lan is on a switch (dynamic), while the server(s) and a few other work horses are static. Some of the machines have 10-100 nic's and a few have gigabit nic's. The work horses of course.
As a last resort, maybe you could run your server on a WinXP box, if that gets more stable speed. Does any other machine get a better speed to distant hosts (europe, australia)?

Quote
"It is amazing how the "Support Engineers" can't answer a smiple question: Can you manually set the RWIN or TCP Window Size on Vista 64? If so, how?"
I think they do not want to admit that the "Next Generation TCP Stack" is in some aspects worse, which is normal with any technology, and suggest to users to stay with 2000/XP/2003. They would rather tiptoe around the issue and deflect it on some other factor.

Quote from: LeoNeeson
I personally don't have access to such speeds over here. But it's interesting that more HFS users with similar speeds, make further tests.
I have shared a file in both HFS and FileZilla, which is known to be working fairly well (expected speed 1MB-4MB depending on the time of day).

---- links removed ----
« Last Edit: July 15, 2015, 07:15:38 PM by j7n »

Offline fdiskMBR

  • Regular poster
  • **
  • Posts: 16
    • View Profile
Re: Routers & ports firewalls - Oh, my!
« Reply #28 on: June 09, 2015, 10:20:42 AM »
Thanks J7n

It would seem that the issue is within my machine and or router.
I have not had time to research further (just too busy) but your comment and info is helpful.

I did notice a change when increasing the send value. Speeds increased from 180kbs to 500kbs in both FTP and http transfers.

The location of this setting is as follows:
Regedit
Hkey_Local_Machine
System
ControlSet001
services
AFD
Peramiters

Change DefaultSendWindow value to what's needed.
If it's not there make a new D word name it DefaultSendWindow
put the number in.

I had changed the default from 261360 to 1045440.
A substantial change & an increase in transfer rate BUT obviously my upload-download speeds in both FTP and HFS should be in the 40 to 50 Mbs range rather than 500kbs on my service. My service is also not throttling as I've tested it.

I've tried local servers, checked hops and other defeating situations. No issues.
I've had others clock their up-downs with the same services and theirs are much much faster. It's an issue on my end that needs to be found.

Thanks again

Offline j7n

  • Occasional poster
  • *
  • Posts: 8
    • View Profile
Re: Routers & ports firewalls - Oh, my!
« Reply #29 on: June 09, 2015, 10:34:46 PM »
Thank you for confirming that these values apply to Win Seven.

1 Megabyte is a rather large buffer and shouldn't be needed to reach these speeds. It seems that "something" is introducing latency into the connection. I don't have a ready explanation. I would keep the buffers in "reasonable" size, because otherwise some applications may start to report inaccurate, fluctuating speeds or register a timeout in extreme cases, as they fill the whole buffer at once and it then, for whatever reason, cannot drain for a while.

The formula for getting the buffer size is: Throughput = buffer / latency. Typical latency for East Coast to "deep" Europe is 120ms. West Coast to Europe would be approx. 200ms.

My system-wide settings are: receive 256960 (0x3ebc0), send 393216 (0x60000), and I found them to work generally well.

256960 / 0.120 = 2,141,333 (2 MB/s).

I've read conflicting information as to what the send buffer size should be rounded to (MSS or memory page). I think it should be rounded to full kilobytes because it is impossible to match it to MTUs of all users (some may negotiate full 1460 segments, others may connect via DSL, or some other VPN and have header overhead). CurrentControlSet, as a shortcut, points to the registry branch selected at boot time. If you put the value in a different "set" it will have no effect.

Maybe DynamicSendBufferDisable could help?

I would proceed with a process of elimination to determine if it's win7, the router, or the ISP that needs to be "fixed". Take a stable working computer with 2000/XP/2003, and no software that can slow it down, adjust the two window size parameters, and measure the speed. As the last step, connect the PC directly to the ISP's network (if possible), and try again.

As for the security of XP, I think it's okay if you purpose build a computer to do one or a few services only, and shut down everything else.

So far, only one user downloaded my test file:

Quote
19:52:26 213.114.xxx.xx:63966 Fully downloaded - 625.8 M @ 5.6 MB/s - /speedtest/656203776.iso

Our ping was approx. 17ms. Which means that the send window was at least 99824 bytes. I was afraid that HFS may have capped it smaller.

Quote
5.6 * 1024 * 1024 * 0.017 = 99824

The speed was definitely limited by congestion on my end at this hour (7PM). Downloads from America or Australia would give more useful statistics about the buffer.