Some questions, some complaints
-
Hi, i have been using pfsense for a long time.
specs: N2800 2 core 4 thread cpu, 2gb ram
Questions
1. I use traffic shaper and i always set my rules in floating tab. Should i use "match" or "pass" for setting action in a rule. What is the difference? I tried both. I'm just setting queues
2. What is the best practice of setting interfaces in a rule? i always select both wan and lan. In some other threads, i saw that selecting no interface equals to selecting all.
3. Sometime ago, some people suggested that we shouldn't use a rule with TCP/UDP protocol. We should create 2 seperate rule for both TCP and UDP especially when setting queues. Is this argument still valid?
4. I'm trying to put "steam" game downloads into a queue. I have found that steam downloads from remote http servers. I also check which server it connects, it seems it is a Tier1 service provider so last option could be L7 filtering but how?Complaints
1. When my download bandwidth reach 8-10Mbit/s, webgui becomes very slow even unresponsive, this is true for ssh connection to pfsense too, is it normal?
2. Status/queues page have been always somewhat unreliable, i have always waited for sometime to see actual bandwidth numbers.
3. pftop could be improved too, using something like "tcpview" is very easy to detect which game is using which port (local and remote) -
1. In my testing, my traffic didn't seem to go into the queues it was supposed to when I used a PASS rule. If you look at the floating rules created by the wizard, they all use MATCH. IN my tests, when I changed a rule that didn't shunt the traffic properly from PASS to MATCH, it started working.
2. VoIP floating rules created by the wizard do not have an interface selected, yet they work. This leads me to believe that if nothing is selected, it either defaults to WAN or defaults to all interfaces. I haven't done any testing to determine which is correct. Other default rules do have WAN selected.
3. I haven't seen or read anything of concern about using a mixed-protocol rule. Do you remember the gist of what was meant?
4. L7 matching isn't easy and requires you to analyze packets to determine bytestream sequences to key on. It might be a lot easier to write a rule that matches all traffic from Steam's networks into your high queues. Then your gameplay and downloads would take priority.
1. I've never seen this myself, sorry.
2. This is true for me too. The outputs seem to show averages instead of realtime values or something else going on. Sometime my throughput is orders of magnitude above our actual link speed.
-
1 and 2) What I recommend is to use "match" floating rules to handle the queueing for outgoing connections, and regular inbound interface rules to match and queue incoming traffic (from the interface point of view). Furthermore, remember the "quick" option on floating rules: on action "match", it doesn't work, but on "pass" it means that no further rules are going to be applied. Since "match" rules are applied in order, this creates an scenario where the last-applying rule is the one actually queueing the traffic. This could get quite messy to understand if you are not careful. This is also why I usually recommend to always select the proper interface and direction for the traffic you are trying to handle (so you can be sure that no other rule is going to catch the traffic)
-
For shaping purposes, I prefer to create a separate rule for TCP and UDP. The reason is that the "ack" queue on UDP does not really make any sense. You will not know for certain what UDP traffic will get into this "ack" queue (as I have found, it looks like that depends on some IP headers, ToS or alike). Better use a rule with no "ack" queue for UDP.
-
Good luck with L7! :P
-
-
-
You both recommend "match" action but georgeman states that "quick" option on floating rules work only for "pass" action. That's interesting because i have always used match action with quick option and some traffic went into some other queue that i didn't want it to go. I have always thought that it must be some kind of bug but now it all makes sense now.
I had switched all match actions to pass a while ago, all went fine, i didn't notice any performance hit either. In my opion "pass" action could be better? -
Steam downloads are like watching youtube videos or web browsing, they both use remote http port. That's why i tried to find steam servers but the servers steam connect ,when it downloads something, is not steam's servers but a Tier1 service provider (i checked ip addresses steam connects) . At the end, all steam downloads get into my youtube web browsing queue no matter what. Steam must be very popular and people should have done something about it maybe i should open a seperate thread
-
-
1. From the definitive guide, it says that Quick is enabled by default on all rules except floating rules. I don't know if that means it doesn't work or if Quick is not desirable. And., honestly, I can't even dream up a scenario where I create rules and then want them last-matched. Who does this, and what good is it? I tend to stick with hat's originally suggested. If the wizard-created rules use MATCH, I use MATCH.
2. You can only filter based on a few variables. If it isn't a custom port or particular network, then you're going to have trouble separating that traffic from all other.
3. One last word about L7, it's very CPU-dependent and can lessen your throughput unless your hardware is fast enough.
-
1. From the definitive guide, it says that Quick is enabled by default on all rules except floating rules. I don't know if that means it doesn't work or if Quick is not desirable. And., honestly, I can't even dream up a scenario where I create rules and then want them last-matched. Who does this, and what good is it? I tend to stick with hat's originally suggested. If the wizard-created rules use MATCH, I use MATCH.
You mean that quick option should work with match action otherwise it doesn't make sense or this makes settings very confusing.
I always try and test my configuration after i set new rules because funny things could always happen. I tested match action with quick option. I doubled ("add a new rule based on this one" button) an existing rule and i changed second rule's queue with another queue. I set both rule's action to "match". Then i've found out that traffic goes to second rule's queue.
Then,for second test, i set first rule's action to "pass" then i tested again, traffic goes to first rule's queue.
In my opinion, this trial and error method proves that match action doesn't work with quick option or there is a major bug in there. I use 2.1.4 version-p16 which seems to be latest as for today
