Thanks for your observation. I wish I new what was going on with Suricata Inline Mode and the traffic shaper. The Pfsense is running on a Xeon server with 16MB and Intel I350 network card The hardware is the best and not an issue as far as I can see. I am back the Legacy Mode for Suricata until this matter is resolved.

Best Regards,

Howard

You could simply HFSC shape outbound WAN (uploads) with a 100Mbit upperlimit. If you make a queue for each LAN subnet and give them both the same queue settings it should evenly share the pipe.

Downloads are trickier since you have two LANs. I see in the other thread you're using CARP so I presume you have a pfsync setup so that eliminates the use of limiters due to a bug.

The only way I know of to do this with multi-LAN and HFSC is to place a node between you and the ISP shaping the traffic out one interface and into another node with LAN and OPT1.

Gig-E –- Shaper node --- Gig-E --- WAN --- existing node --- LAN & OPT1

Or you could use a 50Mbit upperlimit on each interface and they would not be able to borrow from each other.

All in all you cannot control how fast traffic arrives from your ISP. Can they rate-limit what they send to you?

@Harvy66:

You set your LAN interface bandwidth to 145Mb? Just asking because many people claim "I set X to Y", but it turns out they actually set "Z" to Y.

So for me to get the speed I want I have the LAN interface set to CODELQ at 186320Kbit/s this is the only way I can get to the speed results I am looking for. If I just type in 150Mb I get no where near 150Mb on a speed test.

PFsense.jpg
PFsense.jpg_thumb
Speedtest.jpg
Speedtest.jpg_thumb

2 queues, 1 lan (download), 1 wan (upload). Set both to 20Mbit.

@linucksrox:

I don't understand this answer. … why would I not be able to use pfsense to limit the rate at which the client is able to download from that server?

You can properly rate limit data leaving your interfaces but not interesting your interfaces. The term "download" is relative. I download from the server, but the server downloads from me. A less ambiguous way to describe the situation is saying you want to rate limit egress from OwnCloud to external clients.

What I have never used is ownCloud.

Limiters are pretty much broken in pfSense 2.2 and later.

@Harvy66:

If you're trying to diagnose why a packet came in the WAN but not out the LAN, it would be nice to know your dropped packet count went up by one instead of it just disappearing with no indication anywhere as to why.

Like I mentioned earlier in the thread, I think queue drops are only logged as such if the queue is the reason for the drop.

Other drops are not, but should they be? I dunno. I would prefer that all the rrdtool graphs in pfSense were more reliable, but since I do not use those graphs for anything important, I kinda don't care…

I would probably use tcpdump to solve the situation you describe, because I am unclear of the semantics involved in the interface/queue stats.

I was also having a problem with my cable connection. I don't have dual WAN but I read the following post which has fixed my problem, it might help with yours, but can read you have done some traffic shaping. Might be worth a look?
https://forum.pfsense.org/index.php?topic=98404.0

Nope! Fair enough :)

Sounds like I have the basics of PRIQ set up correctly, thanks!

so are you using floating rules, lan rules, or both?
right now I'm using floating rules. if this is correct, which interface are you choosing

@Harvy66:

Limiters don't guarantee bandwidth, they limit bandwidth. If you create a limiter that limits your special subnet's bandwidth to 8Mb/s, that doesn't mean they'll always get 8Mb/s, just that they can never exceed it. You also need to place limits on the complement of that subnet.

I personally prefer to use HFSC, which defaults to specifying minimums instead of maximums, although you can also do maximums.

Thanks for the suggestion Mr.Harvy66. Really appreciate it. I will work on HFSC now.  8)

so in the above image, I am allocating 10% of my bandwidth to games, and games have a very high priority, just below qACK

now I have circled in green the 10% bandwidth and the checkbox "Borrow from other queues when available"

in this particular pfsense page, does that checkbox mean, share my 10% bandwidth with the other queues (qP2P and qOthersHigh)

or does that checkbox on that page mean, when I need more than my 10% bandwidth, go borrow from the other queues.

Hi

I also find the removal of L7 a bit sad. Snort's OpenAppID feature is nice, as long as you want to block traffic, but what if you want to use L7 to send specific traffic types to a traffic shaper queue? Then OpenAppID wont work.

One idea might be to replace ipfw-classifyd with something like nDPI (http://www.ntop.org/products/deep-packet-inspection/ndpi/). It's opensource and has the advantage of being able to inspect SSL encrypted traffic as well. I've already created a feature request for it - https://redmine.pfsense.org/issues/5813

@sofakng:

I'm not sure the difference between ALTQ and dummynet, but I would absolutely love for pfSense to support fq-codel regardless of how it's implemented.  (as long as it works correctly… right?)

In pfSense ALTQ is known as traffic-shaping queues, and dummynet is known as limiters.

It won't make 10.3, too late for that, but hopefully gets into 11. We'll get it sooner than later if that happens (post-2.3 regardless).

thanks

I don't want to share the internet between vlans I  want to restrict every users that  don't have speed more than 20 KiloByte  for download and uploada

A large increase of latency is not an inherent characteristic of a saturated link, only a characteristic of a saturated link with too much buffer. You can use something like CoDel to limit buffer bloat to something more reasonable and it has a side-effect of causing streams to be mostly fairly balanced. That may be your 80/20 rule. If you need even more control and if you have a limited number of clients, you could use HFSC, but limiters seem to be easier for most people to grasp.

Even with limiters, give CoDel a try.