Firewall rules, Traffic shaping, LAN vs WAN & In vs Out
-
Do you know why wizard created rules affect LAN interfaces (and LAN to LAN traffic), even though thy have only the WAN interface explicitly selected? Is there something going on behind the scenes, not reflected in the floating rules GUI?
-
I don't know. Can you give an example of what you are seeing?
-
Yes, just clicking on any floating rule created by the traffic shaping wizard you can observe that this rule has WAN interface explicitly selected and no others.
Attached is a screenshot.
Thanks
-
I went and checked all my floating rules. Some have WAN selected, most have nothing selected. What is happening for you? Do you have a WAN rule that is affecting LAN traffic somehow?
-
Yes, I run the traffic shaping Wizard with one WAN and eight LAN interfaces. It created the rules, and traffic shaping works.
The problem is; traffic shaping works everywhere, so my LAN-to-LAN traffic slowed down to the crawl.
I am not afraid of manual configuration, to make the LAN traffic go around the queues; but to start doing that, first I need to understand how the traffic shaping system works. And, I do not understand where the rules that assign traffic to the LAN interfaces are.
Every single rule the traffic shaping wizard created for me has the WAN interface selected and no others.
-
If all your rules have WAN selected then I don't know how it is affecting your LAN traffic. As far as I understand, all traffic shaper rules are put in Floating Rules, and the entire floating rules system was designed with shaping in mind. Most rules use ports to distinguish typical Internet traffic types (WWW, FTP, DNS, etc). I'm not sure how these kinds of specific rules would interfere with your inter-LAN traffic, unless your rules use the wildcard * for everything like Source * Port * Destination * Port * Gateway * Queue Whatever.
-
They (wizard created rules) do use wildcard for source, source port, destination, and gateway. All uncategorized traffic is categorized as P2P.
I guess, then, interface is ignored, for queue settings, and always applies on all interfaces, no matter what interface is selected in the floating firewall rule?
It does not matter if I put my LAN-to-LAN traffic in the least restrictive queues; they are still going to be slowed down 500 times, because I have very slow Internet.
The right way to do it would be to ether have the LAN-to-LAN traffic not put into the queues in the first place. Or have separate queues for it with different bandwidth settings.
-
The HFSC multi-lan wizard creates a link queue for full-lan-speed traffic (qLink) and nested queues for shaped traffic. I don't think that's available in priq.
I have had limited success using HFSC, having many of the same questions you have about exactly how the floating rules should be defined. Every time I try it again, I blow out all the rules and start with the wizard. When I try to customize it some seems to work (traffic seems to be going in the proper queue) then I do something else that I think should work and no traffic goes into the queue.
-
Make sure that the action for your floating rules is MATCH, not PASS. I used to trip on this at first because you're used to writing firewall rules where PASS and BLOCK are common actions.
-
They're all match.
-
If you have a specific example in mind, let's see the rules.
-
To get the firewall to categorize any of my data I had to set the following settings:
(using PrioQ)
Action: PASS
Quick: Checked
Interface: LAN
Direction: any
Proto: TCP/UDP
Dest Port Range: torrent ports
Ack/Que: qAck/qP2PI had to create two rules, one for LAN and one for WAN, but I had to set them to pass or the firewall would not categorize the traffic… I'm not sure why match was not working and why I had leave interface/direction on LAN&WAN /any.. but thats the only way I seem to capture all of the data. Does this seem like an overly aggressive rule?
-
@G.D.:
Yes, I run the traffic shaping Wizard with one WAN and eight LAN interfaces.
Not your fault, since it is not explicitely explained anywhere besides some forum posts (most of them written by me…), but shaping multi-LAN does not work as you expect. For reasons and an explanation on how the shaper works, check this post I have just written.
Regards!
-
…
shaping multi-LAN does not work as you expect. For reasons and an explanation on how the shaper works, check this post I have just written.Regards!
Sorry if this is considered hijacking a thread, but just one small question: Does this apply to all shaping disciplines? I'm considering using the PRIQ shaper in a LAN party (which will have multiple subnets/VLANs) to prioritize gaming and other important traffic to/from the Internet. The Internet connection speed will be 1Gbps, if that makes any difference.
-
…
shaping multi-LAN does not work as you expect. For reasons and an explanation on how the shaper works, check this post I have just written.Regards!
Sorry if this is considered hijacking a thread, but just one small question: Does this apply to all shaping disciplines? I'm considering using the PRIQ shaper in a LAN party (which will have multiple subnets/VLANs) to prioritize gaming and other important traffic to/from the Internet. The Internet connection speed will be 1Gbps, if that makes any difference.
Yes, it is the same for any scheduler since this is originated from the fact that you cannot have the same queue applying to multiple interfaces simoultaneously. Since download is "shaped" (and I put it in between quotes because you cannot really shape download, but do some TCP based tricks) on the LAN side, you are actually having multiple download pipes not communicating with each other