Trying to resolve problem with traffic shaper wizard rules
-
Quite a few rules there. I'd keep it simple. In order to troubleshoot you should only create one rule, SSH for example. Flush your state table. Then SSH to a IPv4 IP (your match rules are IPV4 only, maybe your LAN client uses IPv6) and see if it gets hit.
Edit: also set the logging option for that rule and check the log if it gets hit
-
The rules were created by the wizard not me. Except that top one which is not related to the wizard at all.
-
Sorry if I missed it but why aren't you using a stable release?
Like @athurdent said, you should trouble-shoot firewall rules first and confirm that they are catching the proper traffic then once that is confirmed you can move on to assigned that traffic to the proper queues.
Your top rule, do you have "Quick" toggled?
-
I am not using 2.2 because there is fixes in 2.4 for my isp, so I had to upgrade.
I troubleshooted the rules by watching the hit counters for the rules. I already did this.
This is how I determined that the match rules are only matching the initial setup packets, and not the data after it, it is as if the keep state part of the rule is not working, as its the same behaviour one would see if keep state was missing.
-
Like I said, please turn on logging for the rules you need to debug. Just because the state counter goes up by one it does not mean that the packet you thought was matched. And try with just one rule for a start and choose something easy to track like SSH.
Also consider that you might be using IPv6 for some connections and your IPv4 rules would never get hit, we don't know about your network setup to be sure. -
Like I said, please turn on logging for the rules you need to debug. Just because the state counter goes up by one it does not mean that the packet you thought was matched. And try with just one rule for a start and choose something easy to track like SSH.
Also consider that you might be using IPv6 for some connections and your IPv4 rules would never get hit, we don't know about your network setup to be sure.I am knowledgeable enough to know if I am going over ipv4 or ipv6 for a specific connection :)
I have already done the logging test, so can tell you the result.
It logs to the log when the connection is setup. So as determined by checking the packet counters the initial connection is matched up, however it then behaves as if keep state was turned off. No further packets get logged or tallied for the duration of the connection.
I cannot put a time on when I will do the specific test you requested which is one rule for ssh only with logging enabled, but I will report back here when I have done that test. I connect to ssh directly over ip, so there is zero chance of it going over ipv6 as the actual ipv4 address is specified in the settings. I never use hostnames for ssh.
Also iftop and pftop confirm this as well.
-
@chrcoluk: Had half an hour to test this myself. Opened a new thread for this as it might be ICMP specific.
https://forum.pfsense.org/index.php?topic=123854.0
-
yeah, I replied there :)
In my case its not icmp specific tho.
-
FYI, ive tried reproducing the issue and diagnosing it a little. And it seems 'match' rules don't work on 2.4 'pass quick' rules do successfully shape my test traffic. But that should not be required.. (I did not use the wizard to setup the rules but that shouldnt make a difference, i do have working shapers on my 2.3.2 box.. I did not check counters on the rules, but did check what status/queues shows while traffic is passing.. With match rules counters stay on 0 except for the default queue..
Ive filed a bug for it on redmine: https://redmine.pfsense.org/issues/7116 -
thanks for your testing PiBa is appreciated.