FreeSwitch + Traffic Shaping: Prioritizing VOIP originating from pfSense

lsoltero

Hello All,

Short Explanation:

Goal to prioritize VOIP traffic originating from FreeSwitch running on the pfSense router for improved voice performance on congested networks.

For the last week I have been trying to get the pfSense traffic shaper to play nicely with FreeSwitch. Unfortunately, I have not been able to make it work and hence my post. All indications are that this should not be difficult to do. It seems that the default VOIP queues and rules created by the traffic shaper wizard should be easily modified to accommodate FreeSwitch. However, try as I may all traffic between FreeSwitch and our VOIP provider (www.flowroute.com) ends up in the default wan queue.

My hope is that one of you traffic shaper gurus will be able to look at this post and tell me where I am going wrong.

Long Explanation:

A. System Setup

I have installed and configured the FreeSwitch Dev 0.9.7.26 package on an Alix board running pfSense 1.2.3-RELEASE. The system has has 256Mb RAM and 32Gbyte disk using pfSense embedded kernel. An OpenVox AM400MS card has been integrated into the system supporting 2 FXS and 2 FXO modules. OpenZap has been configured to integrate the FXS/FXO channels into FreeSwitch. FreeSwitch has been configured to use flowroute as the external gateway and a DID has been assigned to the system.

A simple dial plan has been created which allows a POTS telephone to make and receive calls through flowroute. X-Lite softphone has also been configured with voicemail and the ability to call local extensions (including the FXS phones), voice mail, and send/receive calls through flowroute. A simple IVR has been setup which allows callers dialing into the system to select a number of options including an extension (FXS or SIP) on the system.

Currently all traffic to/from FreeSwitch occurs through the WAN. In our test environment the X-Lite client is on the WAN and there are no devices on the LAN.

Bottom line… we have a simple PBX running on the pfSense 1.2.3 which is working well.

B. Problem

With the traffic shaper enabled when making calls through FreeSwitch all traffic goes to the qwandef queue and does not get elevated in priority. The goal is to tag traffic originated or destined for FreeSwitch for routing through qVOIPUp and/or qVOIPDown so that it can be tagged for higher priority. Queuing to the VOIP queues would allow the QoS prioritization of VOIP traffic for better voice quality under heavy network demand.

C. FreeSwitch setup

FreeSwitch is bound to the WAN IP address which in our test setup is 192.168.0.12. The pfSense firewall is on our local firewall traffic to/from the internet goes through our corporate firewall (and hence NATed).

Name Type Data State

internal-ipv6 profile sip:mod_sofia@[::1]:5060 RUNNING (0)
internal profile sip:mod_sofia@192.168.0.12:5060 RUNNING (0)
external profile sip:mod_sofia@192.168.0.12:5080 RUNNING (0)
flowroute gateway sip:XXXXXXXXXX@sip.flowroute.com REGED
192.168.0.12 alias internal ALIASED

C. Firewall setup.

For our test setup we focus only on the WAN since there are no devices hooked up to the LAN. Currently there is one WAN firewall rule which is all stars (i.e. totally open)

D. Traffic Shaper

The traffic shaper wizard was run enabling VOIP and using the asterisk profile. All other options were disabled. This created the following queues
qwanRoot, qwandef, qwanacks, qVOIPUp, qVOIPDown, qlanRoot, qlandef, and qlanacks.

The traffic rules were modified to reflect the port requirement for freeSwitch. 6 rules in all are created they are

Queue settings were set to their defaults.

full description of FreeSwitch ports can be viewed here
http://wiki.freeswitch.org/wiki/Firewall

E. Diagnosis

The traffic shaper queues are monitored while making outgoing calls using the FXS channel with an analog POTS phone. The only 2 queues that see any activity are the qwandef and qwanacks which are designated as the default traffic shaper queues. A

We also run tcpdump and notice that indeed connections to floroute from pfsense are on the ports which have been programmed.

Here is a sample of the tcpdump showing that port 5060, 5080 and pfSense ports 16384->32768 are indeed used for the VOIP connections.

18:49:26.145737 IP 216.115.69.144.5060 > 192.168.0.12.5080: SIP, length: 447
18:49:26.147122 IP 192.168.0.12.5080 > 216.115.69.144.5060: SIP, length: 642
18:49:28.776028 IP 192.168.0.12.5080 > 216.115.69.144.5060: SIP, length: 639
18:49:28.875909 IP 216.115.69.144.5060 > 192.168.0.12.5080: SIP, length: 440
18:49:34.120892 IP 216.115.69.144.5060 > 192.168.0.12.5080: SIP, length: 448
18:49:34.122217 IP 192.168.0.12.5080 > 216.115.69.144.5060: SIP, length: 643

18:48:37.699801 IP 67.16.125.60.50702 > 192.168.0.12.17930: UDP, length 32
18:48:37.706998 IP 192.168.0.12.17930 > 67.16.125.60.50702: UDP, length 32
18:48:37.720762 IP 67.16.125.60.50702 > 192.168.0.12.17930: UDP, length 32
18:48:37.733557 IP 192.168.0.12.17930 > 67.16.125.60.50702: UDP, length 32
18:48:37.739745 IP 67.16.125.60.50702 > 192.168.0.12.17930: UDP, length 32
18:48:37.761812 IP 67.16.125.60.50702 > 192.168.0.12.17930: UDP, length 32
18:48:37.764945 IP 192.168.0.12.17930 > 67.16.125.60.50702: UDP, length 32
18:48:37.782428 IP 67.16.125.60.50702 > 192.168.0.12.17930: UDP, length 32
18:48:37.792592 IP 192.168.0.12.17930 > 67.16.125.60.50702: UDP, length 32
18:48:37.800737 IP 67.16.125.60.50702 > 192.168.0.12.17930: UDP, length 32
18:48:37.823686 IP 67.16.125.60.50702 > 192.168.0.12.17930: UDP, length 32

F. Analysis.

Following is a listing of /tmp/rules.debug which has been edited to remove rules which do not apply to the problem. I have added comments where appropriate. Currently I fail to see why the rule set fails to tag freeswitch traffic as VOIP.

System Aliases

loopback = "{ lo0 }"
lan = "{ vr0 }"
wan = "{ vr1 }"
enc0 = "{ enc0 }"
WAN2 = "{ vr2 }"

// define the queues
altq on vr1 hfsc bandwidth 1024Kb queue { qwanRoot }
altq on vr0 hfsc bandwidth 1024Kb queue { qlanRoot }

queue qwanRoot bandwidth 1024Kb priority 0 hfsc { qwandef, qwanacks, qVOIPUp }
queue qlanRoot bandwidth 1024Kb priority 0 hfsc { qlandef, qlanacks, qVOIPDown }
queue qwandef bandwidth 1% priority 1 qlimit 500 hfsc ( default realtime 1% )
queue qlandef bandwidth 1% priority 1 qlimit 500 hfsc ( default realtime 1% )
queue qwanacks bandwidth 25% priority 7 hfsc ( realtime 10% )
queue qlanacks bandwidth 25% priority 7 hfsc ( realtime 10% )
queue qVOIPUp bandwidth 25% priority 7 hfsc ( realtime 32Kb )
queue qVOIPDown bandwidth 25% priority 7 hfsc ( realtime 32Kb )

//
// Here is where we tag new incoming/outgoing connections
//
// my understanding is that all new connections are tagged as "unshaped" and blocked
// then as we flow through the next set of rules either going out or coming in through the wan
// the connections are re-tagged based on whether they match the appropriate rule
// we see that any gaining traffic to/from

block in all tag unshaped label "SHAPER: first match rule"

// these rule tags replies to traffic flowroute->freeswitch qVOIPUp
pass in on $wan proto udp from any to 192.168.0.12 port 5060:5080 keep state tagged unshaped tag qVOIPUp
pass in on $wan proto tcp from any to 192.168.0.12 port 5060:5080 keep state tagged unshaped tag qVOIPUp

// these rules tag traffic from freeswitch -> flow route for qVOIPDown
// we note that only traffic which has previously been tagged as qVOIPDdown is placed in the qVOIPup queue
// since traffic which is originating from freeswitch has not been tagged yet new rules need to be added
// for unshapen traffic originating from the router.
pass out on $wan proto udp from any to any port 5060:5080 keep state tagged qVOIPDown tag qVOIPUp
pass out on $wan proto tcp from any to any port 5060:5080 keep state tagged qVOIPDown tag qVOIPUp

// above comments apply to both of these.
pass in on $wan proto udp from any to 192.168.0.12 port 16384:32768 keep state tagged unshaped tag qVOIPUp
pass out on $wan proto udp from any to any port 16384:32768 keep state tagged qVOIPDown tag qVOIPUp

–--
Here is the output from pfctl -sr | grep vr1 showing that the rules have been modified to accommodate traffic originating from freeswitch

pfctl -sr | grep vr1

pass in on vr1 inet proto udp from any to 192.168.0.12 port 5060:5080 keep state tag qVOIPUp tagged unshaped
pass in on vr1 inet proto tcp from any to 192.168.0.12 port 5060:5080 flags S/SA keep state tag qVOIPUp tagged unshaped

// this rules tags traffic originating from freeswitch headed for flowroute for the qVOIPUp queue
pass out on vr1 proto udp from 192.168.0.12 to any port 5060:5080 keep state tag qVOIPUp tagged unshaped

pass out on vr1 proto udp from any to any port 5060:5080 keep state tag qVOIPUp tagged qVOIPDown

// this rules tags traffic originating from freeswitch headed for flowroute for the qVOIPUp queue
pass out on vr1 proto tcp from 192.168.0.12 to any port 5060:5080 flags S/SA keep state tag qVOIPUp tagged unshaped

pass out on vr1 proto tcp from any to any port 5060:5080 flags S/SA keep state tag qVOIPUp tagged qVOIPDown
pass in on vr1 inet proto udp from any to 192.168.0.12 port 16384:32768 keep state tag qVOIPUp tagged unshaped

// this rules tags traffic originating from freeswitch headed for flowroute for the qVOIPUp queue
pass out on vr1 proto udp from 192.168.0.12 to any port 16384:32768 keep state tag qVOIPUp tagged unshaped

pass out on vr1 proto udp from any to any port 16384:32768 keep state tag qVOIPUp tagged qVOIPDown

Further dow we see

// This is where traffic tagged qVOIPUp is routed through through the firewall. All traffic originating from FreeSwitch and all traffic replying
// to any traffic destined to FreeSwitch should have been tagged qVOIPUp… So… this statement should route it and then terminate.
// However… we never see anything in the VOIP queues so the tagging must be failing.
pass out quick on vr1 all keep state tagged qVOIPUp queue (qVOIPUp, qwanacks) label "let out anything from firewall host itself"

Anything the traffic is actually in the qwandef queue so this is where it gets routed.
pass out quick on vr1 all keep state queue (qwandef, qwanacks) label "let out anything from firewall host itself"
pass out quick on vr0 all keep state tagged qVOIPDown queue (qVOIPDown, qlanacks) label "let out anything from firewall host itself"
pass out quick on vr0 all keep state queue (qlandef, qlanacks) label "let out anything from firewall host itself"
pass out quick on vr2 all keep state label "let out anything from firewall host itself"

the following rules should not matter because we never get to them. The matching pass out quick directives above halt the filtering process.

Anchors for rules that might be matched by queues

anchor qwanRoot tagged qwanRoot
load anchor qwanRoot from "/tmp/qwanRoot.rules"
anchor qlanRoot tagged qlanRoot
load anchor qlanRoot from "/tmp/qlanRoot.rules"
anchor qwandef tagged qwandef
load anchor qwandef from "/tmp/qwandef.rules"
anchor qlandef tagged qlandef
load anchor qlandef from "/tmp/qlandef.rules"
anchor qwanacks tagged qwanacks
load anchor qwanacks from "/tmp/qwanacks.rules"
anchor qlanacks tagged qlanacks
load anchor qlanacks from "/tmp/qlanacks.rules"
anchor qVOIPUp tagged qVOIPUp
load anchor qVOIPUp from "/tmp/qVOIPUp.rules"
anchor qVOIPDown tagged qVOIPDown
load anchor qVOIPDown from "/tmp/qVOIPDown.rules"

finally we see this

User-defined rules follow

pass in quick on $wan reply-to (vr1 192.168.0.1) from any to any keep state queue (qwandef, qwanacks) label "USER_RULE: WAN -> LAN"

G. Conclusion

I can't understand why given the modified pfctl rule set why freeswitch <-> flowroute traffic is not being tagged for qVOIPup.

Can anyone provide insight?

I look forward to your response.

--luis

lsoltero

Hello All,

Got this working… So the following rules which can be added by the traffic shaper gui set the queues for VOIP traffic from LAN <-> WAN.

block in all tag unshaped label "SHAPER: first match rule"
pass in on $lan proto tcp from 192.168.10.0/24 to any port 5060:5080 keep state tagged unshaped tag qVOIPDown
pass out on $wan proto tcp from any to any port 5060:5080 keep state tagged qVOIPDown tag qVOIPUp
pass in on $wan proto tcp from any to 192.168.10.0/24 port 5060:5080 keep state tagged unshaped tag qVOIPUp
pass out on $lan proto tcp from any to 192.168.10.0/24 port 5060:5080 keep state tagged qVOIPUp tag qVOIPDown
pass in on $wan proto udp from any to 192.168.10.0/24 port 5060:5080 keep state tagged unshaped tag qVOIPUp
pass out on $lan proto udp from any to 192.168.10.0/24 port 5060:5080 keep state tagged qVOIPUp tag qVOIPDown
pass in on $lan proto udp from 192.168.10.0/24 to any port 5060:5080 keep state tagged unshaped tag qVOIPDown
pass out on $wan proto udp from any to any port 5060:5080 keep state tagged qVOIPDown tag qVOIPUp
pass in on $wan proto udp from any to 192.168.10.0/24 port 16384:32768 keep state tagged unshaped tag qVOIPUp
pass out on $lan proto udp from any to 192.168.10.0/24 port 16384:32768 keep state tagged qVOIPUp tag qVOIPDown
pass in on $lan proto udp from 192.168.10.0/24 to any port 16384:32768 keep state tagged unshaped tag qVOIPDown
pass out on $wan proto udp from any to any port 16384:32768 keep state tagged qVOIPDown tag qVOIPUp

Nothing special there.

However, as stated previously unless additional rules are added the FreeSwitch process on the box does not have its traffic sent through the Voip queues. The default pfSense configuration sends the traffic through the wan default queues without priority elevation.

/etc/inc/filter.inc needs to be modified to add the following rules.

Setup FreeSwitch Server <-> Provider Traffic Shapper

pass out on $wan proto udp from 192.168.0.12 port 16384:32768 to any keep state tag qVOIPUp
pass out on $wan proto udp from 192.168.0.12 port 5060:5080 to any port 5060:5080 keep state tag qVOIPUp
pass out on $wan proto tcp from 192.168.0.12 port 5060:5080 to any port 5060:5080 keep state tag qVOIPUp
pass in on $wan proto udp from any to 192.168.0.12 port 16384:32768 keep state tag qVOIPUp
pass in on $wan proto udp from any port 5060:5080 to 192.168.0.12 port 5060:5080 keep state tag qVOIPUp
pass in on $wan proto tcp from any port 5060:5080 to 192.168.0.12 port 5060:5080 keep state tag qVOIPUp

Note that this takes care of box <-> wan it does nothing about prioritizing traffic to the LAN. In our setup traffic to the LAN was fast enough not to require queuing so we just send the traffic through the default lan queue. However, a mirror set of rules could be added to also elevate LAN <-> FreeSwitch on pfSense router.

Take care.