WAN AckQueue on VOIP Shaping
-
I think I have the configurations correct for prioritizing hosted VOIP Traffic (to our provider's subnets), but am having trouble wrapping my head around something.
Floating rule #1
Action: Match
Interface: LAN
Source: *
Destination: Provider subnet
Ackqueue/Queue: qACKph/qVOIPFloating rule #2
Action: Match
Interface: WAN
Source: Provider subnet
Destination: *
Ackqueue/Queue: qACKph/qVOIPWhen viewing the Queue Status, I can see the traffic being pushed towards the LAN-qVOIP. However, the corresponding traffic on the WAN is placed in the WAN-qACKph. Is this correct? Can somebody clarify this for me?
-
I am using priq with my voip and these are my settings. The voipservers entry is an alias for all my upstream provider addresses. I don't use the ackqueue in my voip setup.
-
VoIP uses UDP, not TCP, so there is no ACK. Activity in your ACK queue is likely other traffic on your network using the WAN. You should change your VoIP rules to stop directing the non-existent ACK traffic to the ACK queue.
-
That's the thing - there IS no other traffic (or, it's rare). A quick packet capture shows that it is indeed UDP traffic while phones are in use, and I'll adjust the rules accordingly. But because of this, there's no need to specify an AcknowledgeQueue?
I also found this on list archives (https://forum.pfsense.org/index.php?topic=26073.10;wap2):
Packets moving through the firewall are either part of an existing connection state or not. There is a firewall rule which does not appear in pfsense's UI that allows packets that are part of an existing connection. Packets that match this rule will not be evaluated against any of the rules you have created, which is why you have to reset your states sometimes after creating a new rule before packets will be matched to it.
When classifying packets/traffic to queues, you want to do this on the floating interface. When allowing, denying or routing packets you want to make rules on a specific physical/logical interface. Every packet will be evaluated against firewall rules on both the logical interface it came in on, as well as the floating interface. Because packets moving through the firewall in any direction will be evaluated by the floating rules, there are two dropdown menus corresponding to ackqueue and queue. If a packet matches a rule on the floating interface and is part of an existing connection, it will be put into the ackqueue, otherwise queue.
So let's use the simple example of connecting to a web site and see how it will be queued. I type google.com into my web browser and hit enter. A packet destined to google's IP address on port 80 enters the firewall on the LAN interface. pfsense first compares said packet to its state table and sees no existing connection, so the packet is now checked against the LAN firewall rules for a match. It matches my default pass rule, so now the packet is evaluated on the floating interface rules.
On the floating interface, the packet matches a rule which states that any packet destined to port TCP/80 goes into ackqueue 'ackbulk' and queue 'bulk' respectively. Because this packet constitutes a new connection, as determined earlier, it will be queued into the bulk queue, and then leave the firewall via that queue on a randomly selected port, say port 10321 for example.
Now google.com responds with a packet. This packet comes from the IP address which we sent our original packet to, TCP port 80, and is destined to pfsense TCP port 10321. pfsense recognizes this as an existing connection and accepts it, bypassing evaluating it against the other WAN firewall rules (ignoring NAT for the sake of this example). The packet is then evaluated against our floating rules, matches the same rule that our initial outgoing packet matched, but is this time queued according to the acqueue, 'ackbulk', because it is recognized as a response to an existing connection.
Subsequent packets to google.com that are part of the same connection will be recognized as being from the source of that connection and will thus enter the bulk queue, while all responses will enter the ackbulk queue.
We could do the same example in reverse, where a host on your LAN is accepting new connections from the internet, say a web server. Connection requests from the internet to your web server on port 80 will enter the corresponding queue, while responses from your web server will be classified into the matching ackqueue.
So ackqueue and queue don't necessarily have anything to do with the direction of the packet from pfsense's perspective, only whether the packet is from the source or destination IP when evaluated against the connection state table.
So, for sake of understanding, the "response" from my VOIP provider is being classified as an Ack packet and thus being placed into my Ack Queue? And to alleviate this, I would only need to eliminate using the Ack Queue (which would not be necessary with UDP being specified)?
-
No, I don't believe so. First off, that post reply is describing any stateful firewall such as pfSense. Also, from what I understand, floating rules are evaluated before all others which contradicts what this thread reply said. I'm fairly sure pfSense isn't failing to recognize ACK packets as its a basic part of TCP.
Can I see a screenshot of your floating rules page?
-
Is it classifying the UDP response (to my initial connections) as ACK?
If nothing else, this is forcing me to consider how our phone systems work. Thanks for answering, btw.
edit: The first 3 rules are for IPSEC - and don't apply to the relevant interfaces.
-
In your two VoIP rules, change the protocol from any to UDP, and get rid of the qACK queue redirect.
-
I doubt that any udp packet is being classified as ack, it is probably something else in that queue.
Just curious but what method of traffic shaping are you using?
When I was initially setting my voip stuff up I tried HFSC but had issues getting it right. I switched to PRIQ and things went much smoother. PRIQ is so much easier to config.
My needs are VOIP over everything else and it seems your needs are similar. You might want to run the wizard again and try PRIQ. If you are using PRIQ already then I typed that for nothing :)Do you have a local pbx and you are trunking to an upstream provider or is your pbx itself hosted elsewhere? Not that it makes a huge difference, just wondering. FWIW once I got traffic shaping working I noticed a huge jump in call quality, so it is worth it to keep at it. No more weird dropouts and stuttering.
-
Why is qACK named qACKph? Did you rename it after creation or did you manually create all your queues?
-
I'll make those changes to UDP and eliminating the qAckph soon enough.
We originally used the wizard, and then went back in and created the queues manually (trying to understand how this all works), so renamed the queue.
I originally had Firewall rules under specific instances, but wanted to move them to Floating so that we don't have any confusion with Gateway policy routing, etc.
And I'm using PRIQ - was going to look into HFSC but it's probably not worth the effort.
As far as VOIP needs are concerned, we're actually using a hosted solution so the PBX is offsite (with the vendor). All I need to do is provide the phone with power and an internet connection, and the rest is cloud-managed. Because of this, part of me thinks that limiting to just UDP traffic might get actual call traffic, but I would think that there's more than that. (edit: This is why I have all traffic to the subnet hitting the queue).
-
For the record, we're using RingCentral which is exactly the same type of cloud-based VoIP provider you're likely using. All I have are a bunch of phones and an Internet connection. My VoIP queues are busy when people are on the phones, and everything works well. We have two IPs that our phones talk to, and I have a pair of floating rules that move traffic from the RingCentral IP alias to their respective queues.
If you've been playing around and trying various things, including manually creating your shaper and queues, I might suggest blowing it all away and starting off fresh with a simple PRIQ queue with VoIP support only. Create an alias for your upstream cloud IP address(es) and then use that alias as your generic VoIP provider in the Voice Over IP section of the wizard.
-
Out of curiosity, could I see your floating rules? You also don't have ackQueues and UDP only?
-
Here you go, and yes I don't have any VoIP traffic using an ACK queue.
-
I assume you are using Jive based on your alias.
According to their docs their phones need tcp traffic, so maybe that acks were to your provider. https://wiki.getjive.com/display/COREMAN/2.0+Network+Requirements+and+Best+PracticesI agree with KOM you should blow your config away and start again. I would do it real basic and make sure it works, then massage the rules if needed. I would only worry about sip and rtp traffic at this point which is udp so no ack queue is needed.
-
Thanks for all of your help.
-
