Moving Traffic into the right queue
-
Hi everyone…
I’ve been using pfsence (2.1.5) 64 bit for the past 2 months, running it as a VM on my esxi host. I love it because the flexibility I got with source based routing and multiple VPN tunnels.
Well, I ventured into the QoS arena and I got stuck pretty quick and I wonder if anyone could offer me some advise. One of my computers at home is used to connect to a remote ftp server and download a rather large files. When it happens, it practically eats up all the bandwidth, which I’d like to control by reducing its traffic priority.
I ran the wizard and trying to use what it produced. I used the PRIQ scheduler which created 4 queues. During the wizard run, I picked the ‘penalty box’ specifying the ip address of the ftp client, thinking to limit the traffic that way. Long story short, the traffic from that pc goes in the wrong queue. It always ends up in qLink - the default queue. I looked at the floating rules and try to make small changes - to no avail.
I attached my FW rules. The two rules filtering traffic for 192.168.1.222 are setup for WAN and outbound. I reset states - made no difference.
All the other queues for DNS, etc seem to work fine, these queues are getting traffic.
Thanks for any pointers..
-
What action do you have in your floating rules, PASS, MATCH, REJECT or BLOCK?
-
Thanks for coming back so promptly.
I have MATCH for both.
-
Good. It looks like it should be working. Even though it's on the Floating screen, do you have a specific interface selected for the rule? Please show the rule edit screen of your ftp rule.
-
I have the WAN interface selected for both rules. Please see attached.
I read a lot of posts here on traffic shaping, trying to get the gist of it and for earlier version of pfsense people were saying they needed to add a second fw rule on the LAN interface. Today, I only have a floating rule.
-
I'm pretty sure a floating rule on WAN out will already be NAT translated so you can't match on source 192.168.1.222 there.
It gets tricky. I have found that if you don't care about queuing ALL traffic from that host on FTP, assign the queue on LAN in.
If you DO care about leaving some FTP unqueued (or queued differently) then you have to get creative.
If you have multiple public IPs you could make sure the outgoing FTP traffic always got translated to a specific IP and use that as the source address on WAN out.
You could also create a rule above your more general rules on LAN that passes the traffic from src 192.168.1.222 dest any port 21. In advanced, mark it with something like WAN_QFTP. Then you could put a floating match rule on wan out that matches src any dest any tagged with WAN_QFTP and puts it in the right queue.
There's lots of flexibility with pf but it certainly adds to the complexity when you start using it.
-
Derelict:
thanks for the very constructive feedback - I'll try it later when I'm back home. -
One additional quick question;
the shaper creates a qACK for the TCP acknowledgements. How do the ACK packets end up in that queue ? I see no floating or any other rule that moves these packets into qACK. And yet, the queue is working as expected.
-
Derelict:
Thanks for your suggestion, I did what you described and it's working perfect !!!! ;D
I created rules on the LAN side of the interface to catch and mark the packets and the corresponding floating rule to move them in the right queue. I added extra rules to try and test different scenarios and this approach seems very reliable.
Thanks everyone for guiding me to a solution..
PS: I also got the answer to my previous question on the how qACK gets filled - we specify this queue per floating rule at the bottom of the rule page..
-
I'm pretty sure a floating rule on WAN out will already be NAT translated so you can't match on source 192.168.1.222 there.
I also wondered if this was the problem, but I don't have a clear picture on the packet flow through the system and what gets applied when.
-
There are diagrams in the 2.1 book. I'm not exactly sure where floating rules come in.
Here's one paste. I am operating on the assumption that a floating rule on WAN out pushes the firewall rules on WAN back into the path and that's the proper order. LAN rules, then floating on WAN out for outbound states.

