sip, as a protocol, has its quirks. You may need to understand "invite" and "re-invite," as this drives which side establishes the session, and this drives how the pf rule set can instrument queuing.
I don't use vonage, but I do use a voip wholesaler, voicenetwork.ca, with TRIXBOX CE behind my pf.
in a NO re-invite sip configuration, the following works well.
Code:
table <VSP> const { sipgw.voicenetwork.ca }
#...
altq on outside priq bandwidth 1024Kb queue {q0,q1,q4,q5vpn,q6voip,q7}
queue q7 priority 7
queue q6voip priority 6
queue q5vpn priority 5
queue q4 priority 4
queue q1 priority 1 priq(default)
queue q0 priority 0
#
nat on outside inet proto udp tagged OKSIPOUT -> (outside:0) static-port
#
pass in log quick on inside inet proto udp \
from (inside:network) to <VSP> tag OKSIPOUT \
keep state queue(q6voip,q7)
#
pass out log quick on outside inet proto udp \
tagged OKSIPOUT keep state queue(q6voip,q7)
#
In a YES re-invite sip configuration, then add...
Code:
#
rdr on outside inet proto udp \
from <VSP> to (outside:0) port 5060 \
tag OKSIPIN -> <inside_sip_endpoint>
#
pass in log quick on outside inet proto udp \
tagged OKSIPIN keep state queue(q6voip,q7)
#
pass out log quikc on inside inet proto udp \
tagged OKSIPIN keep state queue(q6voip,q7)
#
The point being with a re-invite enabled, or VSP initiated SIP streams, sip topologies, the udp stream is being initiated by the VSP side; consequently, pf has to rule-catch this inbound stream and attach it to a queue for the reply stream BEFORE pf's default state and queue attaches.
/S