Trying to resolve problem with traffic shaper wizard rules
-
Ok guys, following some good advice from dotdash, here is a clean thread on an issue I am having with pfSense.
Information is this.
pfSense version is 2.4 using early Jan snapshot.
Isp is sky UK who I connect via WAN_DHCP and WAN_DHCP6 for ipv6.
I have one WAN interface, and one LAN interface, there is also a openvpn interface.
Hardware is 2 x intel i350 network ports, and a braswell chipset.The problem is when I run through the wizard and select the options for my need's the traffic is not correctly going to the right queues.
I have tried both wizard's one for dedicated link and the for multi wan/lan.
To try and keep diagnosis simple I am sticking to HSFC queues and not adjusting to FAIRQ after the wizard has ran for this issue.The queue status screen shows the vast majority of traffic on the default queue with a small amount of packets in the qACK queue. All other queues remain hard fixed at 0.
The options passed onto the wizard are.
HSFC for LAN and WAN, speed of internet connection, and priorities as follows, priorities not mentioned mean they disabled/default.
msn, git, irc, dns, remote desktop, ntp, vnc, icmp high priority
http, steam downloads, battlenet downloads low priority.Tests have run include httpd downloads, steam downloads, dns benchmarks (to flood connection with dns queries).
I disabled my nat rule to force dns connections to the local resolver so dns tests are actually using external dns connections.The results I see are as follows.
A small amount of traffic registered as qACK it is definitely less than the actual ack traffic as measured by other means.
HTTP traffic is all in the default queues for both up and down.
DNS traffic is also all in default.If I examine the counters on the rule page for the individual rules added by the wizard, the TCP based rules appear to increase slightly when a connection is initiated (syn process) but then do not budge during the download.
UDP based DNS rule doesnt match anything at all, it remains fixed on 0.
-
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.