Trying to match ack's
-
The flags S/SA is matching syn's not ack's.
Does anyone know the correct way to match ack's? The easier way would be to match on packet size but PF doesnt support.
I cannot get ack packets out of the default egress queue.
-
right I found the reason, but its a lose-lose situation.
The rules created by the wizard are set as match rules, meaning they not actually moving the traffic to the queue, they just report when the rule hits in the log. My ack rule was the same a match rule.
If I change the rule to pass then packets get routed to the right queue's.
However the pass rule then opens the ports on the internet, so e.g. my catch all ack rule acts as a firewall rule to allow all inbound syn/ack.
I am speculating the answer is to make outbound wan rules instead of floating rules, which I am going to try now.
–edit--
yes adding the rule to LAN (outbound) instead of floating fixes the security issue.
-
You don't match packets, you match states. It's a stateful firewall. Just create a catch-all "matching" floating rule that sets the the queue to your default and the "Ack Queue" to whichever queue you want it to be in.
-
The flags S/SA is matching syn's not ack's.
Does anyone know the correct way to match ack's? The easier way would be to match on packet size but PF doesnt support.
I cannot get ack packets out of the default egress queue.
Jusging from this and your other post you haven't read anything about pfSense traffic-shaping or firewalling fundamentals. Google & the pfSense wiki are good resources.
ACK classification is already integrated in to the firewall rules. When you select the queue to assign the traffic to, there is a separate ACK queue option that will automatically assign related ACK traffic.
What exactly are you trying to accomplish?
-
I already solved it.
I got confused by the incorrect rules added by pfsense into the firewall.
I found out that the match rules whilst matching the traffic, were not moving the traffic to the appropriate queues. If the rules get changed to pass rules then they start working.
I did what you said already and researched how altq works, unfortenatly I have come to a disagreement with the pfSense developers.
Here is what happened for me.
I filled in the traffic shaper wizard.
The answers I provided to the wizard was 1 LAN interface, 1 WAN interface, and speed of my connections (I took some of the speed of course as to make pfSense the bottleneck).
I chose to have dns, teamspeak, icmp and a few other things as high priority and battlenet downloads, steam downloads as low priority.The result was whilst the main altq bandwidth caps worked, the queues were not been allocated, everything just went to the default queue, including my ack rule which I added copying the templates pfSense used.
I then went online, checked PF documentation from FreeBSD (not openbsd this is important as openbsd uses newer code) as well as some blogs, and there was one thing in common with both.
They used 'pass' not 'match' to classify traffic. The one blog I read that mentions 'match' makes a important note that will only work in pf code in openbsd 4.6 and newer, but of course FreeBSD pf is based on openbsd 4.5 code.
I found when I changed the match rules to pass then "boom" as if by magic traffic went into the other queues.
Great right?
No because the pass rules were allowing traffic through the firewall, of course since floating rules take priority over device specific rules.
I ended up moving the rules I wanted to the LAN interface which acts on outbound traffic and is now working for me. I did post a couple of bug reports related to this but they were rejected. The pfSense documentation which is the only source on the entire internet saying to use match rules on the floating interface for traffic shaping simply seems incorrect, based on my own experience and the documentation from FreeBSD itself.
Now also to point out I am not a newbie to PF (and FreeBSD), I do use it on over 30 production servers, it is just the ALTQ aspect I am new to. Some of these servers host websites comfortably within the top 1k alexa list.
So in short the issue was not the TCP flags, it was due to the 'match' been used by PF not moving the traffic to the ALTQ queues.
Also to answer your final question, I simply wanted to prioritise all ack packets for small data, so things like SSH terminals remain smooth when downloading/uploading.
-
Now I do respect there is something else that may make the 'match' rules work, as after all there is people who use them and do get traffic moved as someone posted on the bug report, but instead of me and the developers working together to try and find out what is happening, I had aggressive responses and no motivation from the developers to figure out why it doesnt work in my configuration, they seem to think I have done something unique to myself to break it, when in fact in all likelyhood this problem will occur for anyone who has similar network topology to myself. All I simply did was run the traffic shaper wizard.
In my case I authenticate to my isp via DHCP so no PPPOE interface.
I am ipv4 and ipv6 dual stacked (interestingly the rules were all configured to ipv4 only so ipv6 also doesnt get shaped by the wizard, even if the match rules work).
I have one LAN interface and one OPT interface, the OPT is openvpn. -
I found out that the match rules whilst matching the traffic, were not moving the traffic to the appropriate queues. If the rules get changed to pass rules then they start working.
That's not how the shaper works for any pfSense installation I've ever used, but whatever.
I did what you said already and researched how altq works, unfortenatly I have come to a disagreement with the pfSense developers.
I'm sure they'd love for you to set them straight. You can correct them via https://redmine.pfsense.org/projects/pfsense
-
You don't know pf as well as you seem to think you do.
but yeah, I prefer the simplicity of interface rules over floating rules myself. I only use floating rules when required.
-
You don't know pf as well as you seem to think you do.
but yeah, I prefer the simplicity of interface rules over floating rules myself. I only use floating rules when required.
I acknowledged I am new to the ALTQ side of PF, but also have tried to explain here I didnt just jump in running a abnormal configuration, I simply ran the wizard.
It doesnt take much knowledge to diagnose if the traffic is been sent to queues, as all one has to do is run that type of traffic and watch the status - queues screen.
There was a few things that made it harder to diagnose tho.
As when I navigate to the traffic shaper page it displays a warning about my interfaces not been compatible with ALTQ, so I spent a while thinking the reason the queues were not been used was because my igb device was not compatible, I later found that warning in the GUI to be a red herring and the igb devices are actually working (discussion in another thread, note I am not the only one to get mislead by that message). Then as mentioned in this thread I thought I had misconfigured the TCP flags (for the ack rule). Its only finally I discovered the match rules were the problem and simply changing to pass makes it work. This was not a random thing I messed with, I only made the change "after" reading documentation from others.
-
You don't know pf as well as you seem to think you do.
but yeah, I prefer the simplicity of interface rules over floating rules myself. I only use floating rules when required.
I acknowledged I am new to the ALTQ side of PF, but also have tried to explain here I didnt just jump in running a abnormal configuration, I simply ran the wizard.
It doesnt take much knowledge to diagnose if the traffic is been sent to queues, as all one has to do is run that type of traffic and watch the status - queues screen.
There was a few things that made it harder to diagnose tho.
As when I navigate to the traffic shaper page it displays a warning about my interfaces not been compatible with ALTQ, so I spent a while thinking the reason the queues were not been used was because my igb device was not compatible, I later found that warning in the GUI to be a red herring and the igb devices are actually working (discussion in another thread, note I am not the only one to get mislead by that message). Then as mentioned in this thread I thought I had misconfigured the TCP flags (for the ack rule). Its only finally I discovered the match rules were the problem and simply changing to pass makes it work. This was not a random thing I messed with, I only made the change "after" reading documentation from others.
Matching traffic is primarily a firewall rule issue not a queues issue.
If floating rules did not work, there would be many people reporting problems, but they aren't…
-
I cannot explain why it works for other people, all I can say is what I found in FreeBSD documentation and it didnt work for me with match, it doesnt have to be broken for everyone to be a bug, it can be specific configurations where the issue occurs.
I will play with it some more at the weekend, to try and debug some more, but I am less motivated given that I now have a working configuration and that the developers have no interest in following this up.
The match rules were definitely finding the traffic as it got logged and tallied on the counter whenever it hit. They just were not applying the queue to the rules.
-
We really would like to try to help you if you would just provide the details requested on what you're doing.
-
Matching traffic is primarily a firewall rule issue not a queues issue.
If floating rules did not work, there would be many people reporting problems, but they aren't…
When did I say queues match traffic?
I never said either that it doesnt work full stop, I said 2 things.
1 - The FreeBSD documention does not state to use match rules for traffic classification for shaping purposes. So basically my results match what the developers of PF have documented. But they do not match what the pfSense developers have documented.
2 - It isnt working in my case with my configuration.It is a strange way to decide if something is a bug just based on that it works for many people. It may make it less likely to be a bug if it affects less people but it doesnt make it impossible.
As I said before to you KOM, you have not requested any details of me. I have already provided lots of information.
I provided the following.
step by step process to get to where I am
information on my network setup
information on my wan setup
what options I chose in the wizard
the hardware I am using
I even now have posted screenshots of my floating rules, which would only be requested when someone doubts what I am saying.Also this thread is different to the other thread and we should avoid mixing the 2 up.
This thread was a simply question on the correct syntax to give to PF on how to match ack packets.
I of course asked it as I mistakenly thought they were not been matched due to incorrect flags in the rules before I discovered it was the 'match' issue.
