Wrong interface in floating rule generated by shaper wizard?
So I set up a simple shaper config using the wizard. 25mb down 25mb up. I put 24mb/HSFC for down and 20mb/PRIQ for up. Checked 'prioritize voip' box and selected 'asterisk/vonage'. I made a test call but saw nothing of note in the queue (since I was listening to voicemail, the sound would be only in one direction.) Puzzled, I looked at the two floating rules (one for UDP port 5060-5069 and the other for UDP port 10000-20000). I was surprised to see that the rule listed the 'choose on which interface packets must come in to match this rule' showed WAN for both rules, not LAN. Give that this is supposed to be shaping (prioritizing really) outbound traffic, this seems backward, no? I changed both rules to specify LAN and made another call. Drilled down into the voicemail menus and started listening to saved messages. Within a matter of seconds, the qVoIP was showing 40kb/sec and ramping up to about 70kb/sec (which are in the right ballpark.) Sounds like a bug? Should I open a bug against this?
Doesn't the wizard generate rules on WAN, but with direction out? It should work, considering the VoIP packets are indeed going out of WAN.
Anyway, shaping on LAN will work, considering you do not have multi-wan load balance, it is properly configured and no other rules are in conflict
The packets enter the queue in question via an interface. For outbound packets, that interface is the LAN. My point was: the rules the wizard generates say 'if the packet entered via the WAN interface, put them in qVoIP'. By definition, outbound packets enter the LAN, not the WAN, so no outbound VoIP packets ever get queued. If I change the interface in the two floating rules associated with the shaper queues, outbound packets do in fact enter qVoIP, and all works well. I don't see how the current behavior can be correct. To clarify: when I say 'so no outbound packets ever get queued', I am describing actual, observed behavior.
The rule the wizard generates should say "if the packet leaves the WAN interface, put it in the queue", since the rule direction should be "out".
The shaper internals were explained by ermal at some point. It is based on the fact that queues are tied to the firewall states. It is more or less as follows:
- A packet comes in on LAN
- All rules for LAN, direction IN get applied. If there is a rule with a queue, the state gets marked as belonging to that queue on LAN. If no queues are defined, it is not marked
- All NAT and internal processing takes place
- Packet is matched against WAN rules, direction OUT. If a queueing rule applies, the state is marked as belonging to that queue. Otherwise it is not marked again (note that as this point the state might have already been marked by the LAN rule)
- Packet goes out of WAN
- Response comes back in WAN. Let's assume there are no queueing on WAN, direction IN, so no further processing regarding queues
- NAT or whatever needs to be done internally
- Before going out of LAN, packet is queued on whatever queue was previously set for that state (assuming no additional queuing on LAN, direction OUT)
- Packet goes out of LAN
The queues are tied to the firewall states. This is why the LAN and WAN queues have the same names. So when tagging a packet going out on WAN, the response will get into the corresponding queue on LAN, when it arrives
I have verified myself this flow, and seems correct
Well, I'm stumped. I tried it the way you said. Zero traffic in the qVoIP queue. I then put it back to LAN and zero there also. I remember the last time I used pfsense (a couple of years ago), I had the same experience. Not trying to be a jerk here, but the default wizard does not generate the rules it says it does. Did you actually try this with voip traffic? I seem to recall that last time I ended up scrapping the default rules and just prioritizing everything udp from the asterisk server. I need to poke at this more when I am fresh…
Mmm, re-reading your first post I can see that you are using different schedulers on LAN and WAN, why don't you try with, let's say, both as HFSC?
Not sure about the wizard rules since I don't usually use it (I prefer to create the rules manually), but I can tell you that queueing out of WAN works for shaping download. There must something else that is forcing the floating rule not to match the traffic
Interesting. I happened to remember my pbx is set up to set diffserv/tos bits on RTP and SIP packets, so I deleted the shaper and created a new one with 'generic(lowdelay)', and the 2 floating rules were replaced by 1. I just tried making another call, and lo and behold queueing. This is probably one of the most frustrating things about using pfsense. I really love the thing, but there are some aspects that are black juju, and it is more than a little frustrating. You google for stuff like this and find literally a score of different articles, many with incomplete, wrong or contradictory advice. Sigh…