Dialup PPP was about 48kbps with about 220ms delay at best. Toss in about 5% packet loss to mimic overbooked ISP T1 uplink for good measure. Next time some kid bitches about slow internet, show them what it was like in the good old days. Have fun. :) And get off my lawn.

likely same issue as in https://redmine.pfsense.org/issues/5721

pfctl related code is mostly (completely?) unmodified from FreeBSD, so look to the FreeBSD man-pages/forums for a better answer.

@esseebee:

Thanks, Nullity.  I was doing a download speed test when I was noticing the latency. I was also only using stand-alone codel, not the codel active queue.  What do you recommend? I'm still obviously learning about this stuff.

If you have complex needs, like running multiple cloud backups while wanting to watch Netflix and play games, then use HFSC/CBQ/PRIQ/FAIRQ and "codel active queue".

Otherwise "codelq" might work well.

Read http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/ for a great intro into traffic-shaping/QoS. He does a great job demistifying misconceptions and explains the differences between the solutions to fixing download & upload latency/bandwidth problems.

@jonathanbaird:

Hi,

I am not sure wether or not I need to set up Traffic Shaping for what I am doing, but I will go over my setup… We have a PBX installed at a datacentre, which sits behind a pfSense instance. The pfSense instance handles all of our NAT and IPSec VPN tunnels. We have currently around 6 VPN tunnels connected, and clients phones connect to the PBX over these VPN tunnels. Each client has its own PBX insance using 3CX's Multi Tennant.

I am not sure if I need to implement Traffic Shaping or not, as it stands the bandwidth is around 500Mbps down and 750Mbps up so we aren't short of bandwidth, but would traffic shaping still help prioritize VoIP traffic, even though there is not other traffic in and out of this pfSense instance?

I welcome your comments.

regards,

Jonathan.

Unless you are saturating your connection, QoS/traffic-shaping is virtually unneeded.

QoS can give you guarantees that if something were to saturate your connection, the VOIP (is that what PBX is?) will continue to see optimal latency and bandwidth.

@keelingj:

OK, this isn't a viable workaround.  Disabling "upper-limit" allows heavy internet usage to saturate the uplink and cause ping spikes.

If you are not multi-LAN, qInternet is unneeded.

IIRC, qInternet is meant to separate intra-LAN traffic (in a multi-LAN setup) from LAN<->WAN (internet) traffic.

@pteek:

pfSense + a managed switch.

How will this work?

You can search for other posts on the topic. I have no actual experience in this area.

I would assume that you would shape the traffic by IP/port on a single interface within pfSense, then the managed switch would split it off into the seperate LANs.

Thank you for your help. I hope I can find.

Best regards,

Im with muswellhillbilly here.. Not sure what you think you are doing but running same network on both your wan and lan is BROKEN!!!  And it not going to work!

Thanks for the answer!
Follow my topology:

External Users —————WAN <————>  PFSENSE <———> LAN <———> Web Server
                                                                                                                                                    |
                                                                                                                                                            |
                                                                                                                                              Internal Users

I'm using limiter and not the queueing e i don't install suricata or snort.
I created a down and up in Traffic Shaper / Limiter (limiter file attach)
And adding down and up in advanced Wan firewall rule (firewall rule file attach)

I used this same rule in version 2.1.3 and it worked. After upgrading to version 2.2.6, it stopped working. I've looked several posts on the internet and I have not found a solution to this case. As this web server has a high traffic of access, I need a speed limit, while I do not think a solution, the rule is disabled.
It still now a post Bug, from the earliest versions 2.2.x this problem persists. Like much of a help!

Thanks!  ;D

LIMITER.png
LIMITER.png_thumb
LIMITER.png
LIMITER.png_thumb
firewallrule.png
firewallrule.png_thumb

@foonus:

@Nullity:

@mcwtim:

Heh. I did something similar at a past LAN and had a clever fellow keep changing his MAC. Unfortunately for him his PC name was descriptive enough; "Lian Li" that I just walked through a few aisles looking for that type of case until I found him.

lol. The best traffic-shaping is nothing compared to physical confrontation.  :o

This is when you download one of those fake pirated FBI screensavers and put a password lock on the workstation, and see how they grovel to you not to rat them out so they can keep their job when they see it.

BOFH
;)

@sofakng:

I'm still a little confused…

It sounds like pfSense 2.3 might support fq_codel type of queueing/shaping?  …but 2.2.6 applies codel and fairq in the wrong order?

The unfounded, "wrong order" theory was a red herring. Forget about it. :)

We currently have "fair queueing" algorithms (HFSC & FAIRQ), which can use the CoDel de-bufferbloating algorithm. It is not exactly fq_codel, but it is similar. How exactly it differs, I dunno. Documentation on fq_codel's internals is available but the internals of FAIRQ+CoDel are found only in source-code, which I do not yet understand.

We will (after 2.3) get proper fq_codel, but we have to wait for it to be completed and added to the upstream FreeBSD code before we can add it to pfSense. Though, for most ALTQ users, I think this will not be very useful, since fq_codel will be implemented in the limiters (dummynet) section of traffic-shaping will not be a traffic-shaper queueing (ALTQ) algorithm.

I do not know how useful fq_codel (in dummynet/limiters) will be to us ALTQ users. We will just have to wait and see, I suppose…

You dont specify gateway groups or any gateway with floating rules.  For floating rules chose the WAN interfaces , if you have more than one use CTRL to select them all.  DO NOT CHOOSE THE LAN INTERFACE IN A FLOATING RULE.

If you make a LAN interface rule then choose the gateway group.  So you should have specific rules in the LAN interface page to send traffic out SPECIFIC WAN INTERFACES.  Then the last rule which is the any/any rule or any other generic rule , you should choose your WAN GATEWAY GROUP as the interface to send the traffic out on.

This is what I have done and I find it works best for me and what I use the traffic shaping for.

Since, in theory, the max any interface can use is the full bandwidth of the LAGG, you'd want to use 2G there in most cases.

@petek8103:

So I think I got it working, they way I wanted. But is there a way to see traffic inside the queues like a detailed list of active traffic say coming from 192.168.30.50 to x.x..x.x port 80 in queue_high?

Would really help if there is a way to do t see what devices are using what port.

The only way I know of is to use tcpdump's abilities to integrate with pflog, a trick I found in "The Book of pf". You can either search my old posts to find more info or Google "tcpdump pflog".

@Derelict:

Rule should be source LAN Net dest any.

Interface rules match on connections coming into an interface. Connections from LAN hosts will have a source address on LAN net.

Thank you!

If it does technically work on LAGG, it definitely would not be able to have strict guarantees about packet timings without knowing which interface a packet will get scheduled.

@roccor:

Ah crap.. Thanks KOM.  I was waiting on someone who'd know to toss an answer in.  I overlooked that crucial bit of info.

@Null I can try single wans at a time.. I'm likely over-complicating it but I was/am unsure of what all I'd need to manually change by adding in two more WAN interfaces after the fact.

I used the wizard to give me an idea of how the rules & queues were setup, then I manually created my own rules & queues, which really helped demystify pfSense's traffic-shaping setup.