pf+voip

[Швецов Михаил]

Does pf have specific rules for voip, may be example of working pf_rule
with voip?

Because for «standart rules» i have problems with voip.

set skip on lo

match out on pppoe0 from { em1:network } nat-to (pppoe0)

block

pass out

pass in on { em1 }

- after hanging up, the line near 3 minutes still busy (may be keep
state set to no state in rules)

- badly hear person on the phone (quiet)

[Stefan Sperling]

Does pf have specific rules for voip, may be example of working pf_rule with
voip?
Because for «standart rules» i have problems with voip.
set skip on lo
match out on pppoe0 from { em1:network } nat-to (pppoe0)
block
pass out
pass in on { em1 }
- after hanging up, the line near 3 minutes still busy (may be keep state
set to no state in rules)

Assuming your VOIP client is in the em1 network it might run into
problems with NAT traversal if you don't use the static-port option.

static-port
With nat rules, the static-port option prevents pf(4) from
modifying the source port on TCP and UDP packets.

- badly hear person on the phone (quiet)

I don't believe pf could have anything to do with that.

[Ryan Freeman]

Post by Швецов Михаил
Does pf have specific rules for voip, may be example of working
pf_rule with voip?
Because for «standart rules» i have problems with voip.
set skip on lo
match out on pppoe0 from { em1:network } nat-to (pppoe0)
block
pass out
pass in on { em1 }
- after hanging up, the line near 3 minutes still busy (may be keep
state set to no state in rules)
- badly hear person on the phone (quiet)

Hey,

I don't use this anymore, but i still have the blurbs from my pf.conf
that had a pretty much perfect working voip connection:

Queuing: this was originally around 900kbit up when i used it (diff
isp). i also had given the voip queue around 12% i think, left it
there as I was unsure of whether i'd still be using the voip phone
after i left that company, and just knocked it down to 2% ;)

also pre-newqueue, warning! ;)
ext01 and ext02 are aastra phone and obihai voip device, respectively.

--snip--

# hfsc queueing
altq on $ext_if bandwidth 460Kb hfsc queue \
{ voip, ack, dns, game, ssh, www_ftp, std_out }

queue voip bandwidth 2% priority 8 hfsc(realtime 2%)
queue ack bandwidth 15% priority 7 hfsc(realtime 15%)
queue game bandwidth 37% priority 6 hfsc(realtime 40%)
queue dns bandwidth 5% priority 5 hfsc(realtime 5%)
queue ssh bandwidth 15% priority 4 hfsc(realtime 17%) {ssh_im, ssh_bulk}
queue ssh_im bandwidth 90% priority 4 hfsc
queue ssh_bulk bandwidth 10% priority 3 hfsc
queue www_ftp bandwidth 3% priority 2 hfsc(linkshare 3%)
queue std_out bandwidth 15% hfsc(linkshare 5% default)

--snip--

# NAT voip, static-port required to maintain UDP port mappings for SIP proxy
match out on $ext_if from $ext01 to any nat-to ($ext_if) static-port
match out on $ext_if from $ext02 to any nat-to ($ext_if) static-port

# queue voip, to AND from
match inet proto udp to port $rtp_ports scrub(set-tos ef) queue voip
match inet proto udp from port $rtp_ports scrub(set-tos ef) queue voip

--snip--

above here took care of the rest. this was using both a obihai voip
device for hookup of a POTS phone, and an Aastra phone as my primary
voip phone hooked into the company directory etc (all quite easy with
asterisk!)

The above worked enough that I could take business calls including calls
that may have resulted in sales of voip service, without it sounding
like i was on a shitty link with various vocal artifacts etc.
in the end i could pretty much hammer my inet connection as hard as
i wanted while a call was in progress and never really lost anything.

YMMV :) I found my values via hours of tweaking, hammering with
various bandwidth-intensive applications, and hammering more.

I believe we did have a form of STUN or SIP proxy, the phones we
used could be preconfigured to fetch a config from the company server,
which would include things like a STUN or SIP proxy ip.

in my setup, my normal nat line in pf does not use static-port, hence
the added line before that point to catch the voip devices and make
sure they are natted with static-port.

Cheers,

-ryan