match in on ovpns9 inet from 172.16.20.0/24 to 192.168.0.240 label "USER_RULE: Queue VideoConferencia" queue qVoIP_ext

The rule above seems to work, since the queue is applied to the state, so the traffic coming back would fall into the right queue.

Limiters are handled via DUMMYNET, which is documented in the FreeBSD man pages for ipfw(8).

Sadly, the traffic shaping/limiting part of pfSense is plain unusable by ordinary users. Lot of effort required into producing working wizards for common scenarios, or even a simple checkbox. People should not have to deal with manual configuration of this thing normally, since they usually end up with completely broken setup, or a setup that has no effect at all. Way too many features, way too complicated and very hard to understand. No amount of convoluted, techblurb docs is going to change this.

@Klaws:

Out of curiosity…why would you want to remove DSCP tags on ingress traffic?

Or, even more mysterious, why would an ISP add DSCP tags to traffic?

Probably nothing, but could be something similar to what my previous ISP was doing – spying on my network so they could justify billing me for having 'too many attached devices'.  Didn't realize back then there was some fine-print stating that they could bill you for having more than 3 'devices' connected to the internet.

If you get a support contract, they will do all that for you, plus you have someone to turn to if things go south.  My company just picked one up.  It's not expensive if you're responsible for the Internet for the whole building.

Oh i should of said it sooner.  The ones i am changing are

net.inet.ip.dummynet.pipe_byte_limit
net.inet.ip.dummynet.hash_size

i change the pipe size to 3145728 and the hash size to 1024, when i reboot the machine they always go back to default.

@georgeman:

Easiest way to shape incoming OpenVPN is to assign the appropriate queue on the allow rule on the WAN interface. The whole tunnel will be shaped

Thank you for your time @georgeman!
I believe that you can't shape incoming openVPN traffic because the traffic has already hit the WAN and won't be processed further, but, I've read somewhere that the outgoing traffic could be shaped because the state created early.
Anyway, with only this rule I couldn't shape the traffic inside the tunnel, I believe that I would need to create rules to the openVPN interface as I did.
The attachment show the RRD graph; I believe it's working although I don't have a feedback yet.

Ps.: Why RRD graphs reset every time you change the traffic shape?

rrdVOIP.png
rrdVOIP.png_thumb

Hi,

i search in the forum if i mistake some tips but i found no answer of my problem.

Anyone use traffic shapping with portal captive here ?

So i don't know if i do wrong or is a bug on pfsense.

Best regards.
Myke.

well.. that was a terrible idea and didn't really work.  after setting up firewall rules to place source and destination traffic into the qIntranet/qDefault.. everything ended up in it, completely ignoring the floating rules.

The traffic that did go to the internet was handled though with WAN floating rules…  I suppose I could remove the queues for LAN1 and LAN2 qInternet entirely, relying only on WAN floating rules for internet traffic and setup just a single qIntranet/qDefault assigned as described above (just dropping the qInternet stuff for those interfaces)?

not really to sure.

Going to need some information to go on with examples of both states: working and not working (after down).

system.log
ps aux
any other pertinent logs

PRTG will give you a free 30 sensor license if you put a link to their site on a public webpage fyi.

Hi @dreamslacker,
    I was looking for the same question, I tried to shape the tunnel as you mentioned, but no packets arrived into the queue. I have not tried to shape LAN -> OPENVPN yet.