Dec 16 09 1:17 am
adrien wrote:But it does have access to the packets travelling between the WinGate computer and any other computer, e.g. a client computer and a proxy, or the proxy and the internet. So it can be used to control bandwidth for proxy traffic, intercepted traffic, or traffic from the WinGate computer to any other computer.
Dec 17 09 2:16 am
Dec 22 09 7:34 pm
Jan 11 10 10:24 pm
Mar 22 10 2:15 am
I extremely need a method of limiting bandwidth of clients connections to Internet regardless of the connection method: NAT or Proxy.
For example, if we set 10KB/sec speed limit for all, then the integral (i.e. NAT + Proxy + WGIC) maximum speed for each user should be limited by 10KB/sec. How could this be done?
Mar 23 10 1:06 pm
Mar 23 10 8:02 pm
Llimit the total bandwidth of client's connections to Internet regardless of the connection method: NAT or Proxy or their simultaneous usage.
Mar 23 10 8:09 pm
Mar 23 10 9:19 pm
adrien wrote:It's painful sorry.
adrien wrote:the best way to limit all traffic for a client, is by matching on the client IP. That will get everything, including proxy, NAT etc. So the rule would specify the source as the client IP, bidirectional (so affects connections to or from client IP).
Mar 23 10 9:33 pm
adrien wrote:Rules are only used for choosing which piece of pie a user is sharing. If you want each user to have their own piece of pie, you need to define each piece, and define the rule that assigns that piece to only that user.
Mar 23 10 11:55 pm
Mar 24 10 12:25 am
adrien wrote:I'll have to check through the code to see about how restrictions are shared, or if there is any other possible explanation for what you are seeing.
adrien wrote:bidirectional simply affects how a rule is matched. Matching of rules only is performed on a new connection. So, the first packet of a connection is examined against the rules. Bidirectional matching means it will match either source or dest, rather than just source or just dest. So this is an indepedent issue of whether local traffic (to / from firewall iteself) is counted. However if the clients are using proxy, you definitely want this option selected (local traffic) So yes, you are correct both these options need to be on.
Mar 24 10 1:18 am
Mar 24 10 1:35 am
Mar 24 10 1:59 am
adrien wrote:I checked the code. There's only one copy of each restriction, and all rules assigned to it refer to it.
So all traffic matching a rule will share the same single restriction.
So, if you are seeing more bandwidth, then this would imply that the rule isn't being applied for some reason.
adrien wrote:So, if you are seeing more bandwidth, then this would imply that the rule isn't being applied for some reason.
Mar 24 10 2:06 am
Mar 24 10 2:19 am
adrien wrote:and you're certain they are all getting that same amount of bandwidth at the same time?
Mar 24 10 7:12 am
Apr 09 10 11:45 am
Apr 10 10 11:06 pm
Apr 11 10 2:57 am
As for the explanation of to/from local machine here it is.
WinGate gets different indications of packets from NDIS depending on whether the packet is indicated by a miniport (incoming from a NIC), or sent by a protocol (going out a NIC). These different indications go into different handler functions, since the requirements are somewhat different.
The setting whether traffic applies to traffic to/from the WinGate machine merely controls whether traffic sent by a protocol (outbound to a NIC) should be controlled. This doesn't differentiate on whether the traffic is outbound to the LAN or WAN - purely if the host OS is sending the packet rather than receiving one.
adrien wrote:When a client is configured to use a proxy, it connects to the proxy, so the SYN packet has the destination address of the WinGate server. Since this is the first packet in the connection (which is the only packet we check bandwidth rules for) and since it is to the WinGate server, unless the "apply to traffic to/from the local machine" option is set, the rule will not apply. So if you want to control proxy traffic this option must be set.
Apr 30 10 6:34 pm