Can i delete all floating rules created by wizard and set the ackqueue and queue in lan rules with specific ports for gaming.. my purpose is to priority all games. games set to prio 5. see pics below

1.png
1.png_thumb

The single best thing you can do to make your internet feel faster and be more reactive to to keep latency low. Codel should help with this. In your situation, a single single default queue plus ACK queue using HFSC should probably work just fine. Possibly adding one or two extra queues for specific bandwidth requirements.

For detailed info about pf's integrated ACK classification you should probably look to OpenBSD's pf documentation.

@MRH:

I'm adding Codelq in 2.3.4-RELEASE-p1 (i386) and the interface shows an error message if no bandwidth is entered.

Is this correct - needs bandwidth?

Yes. It's a fundamental part of traffic-shaping; whichever device is doing the shaping must be the bandwidth bottleneck. So you need to put in a bandwidth that is lower than your internet connection's top-speed.

@chrcoluk:

docteur trigger the crash again and please post the backtrace here, I will then look to see if the issue is raised as a FreeBSD PR.

Thanks. I will do that asap.

Thanks a lot for the advice, I have blocked webmail services via firewall rule already.

@glennmckenna:

thanks for your answer i've created the two aliases but it can't see how link them to the groupes (unless i use static ip)

nor can i see how to limit the aliases

First off,  may we know how you grouping the groups?  is it by interface?

@tman222:

@Nullity:

AFAIK, (our) CoDel simply controls (FAIRQ's) global buffer size, it doesn't add another buffer. Just like when you manually set a queue's maximum depth, except codel dynamically and intelligently controls it.

CoDel could also be applied to each of FAIRQ's per-flow pseudo-queues… but I dunno if it does. I think it's unlikely.

It shouldn't be too hard for some programmer to find proof of these hypotheses in the source-code and present it to us non-programmers.

Who knows? ermal would know, but he's no longer around. :(

Thanks Nullity.  If it's just one giant queue/buffer of buckets controlled by Codel wouldn't the fairness of FAIRQ break down?  In other words, how would the FAIRQ algorithm be able to go round robin and dequeue one packet at a time from each flow?  It seems that if Codel controlled the size of the queue/buffer that contained the buckets (vs. controlling the flow queues), it would no longer be fair as some buckets at the end may be dropped (i.e. the algorithm would never get to them).  I could be completely wrong though.  I looked a little through the source code (findings further up in this thread), and it seemed like that the queue management algorithm chosen (Red, Codel, etc.) is applied per bucket.

Thanks again for all your help and explanation guys, I really appreciate it.

FAIRQ controls the ordering of queued packets, nothing more.

CoDel controls queue depth, nothing more.

That's how I understand it…

Can this feature be available from commercial support?

https://www.reddit.com/r/PFSENSE/comments/3e67dk/flexible_vs_fixed_limiters_troubleshooting_with/

In the former days, pending on many different network layouts or constructions or plain based on many different needs,
late in the 70th and earlier 80th, at SANS USA were defined to have three main types of demilitarized zones (DMZs) and
one separation of one of them. And until theses days "we" will all able to speak about the same thing if we are saying
we have this or that one of DMZ. That makes things much easier and we don´t talk about something on the right site
and all peoples or listeners are looking to left site! So is why I am talking about that in this direction, others may have
also other opinions and knowledge on this and for sure I don´t want to bother with them, but that's how I know it right.

DMZ 1 - A real DMZ (Dual homed or bastion host)
Two routers or firewalls behind each other (router cascade)

DMZ 2 - "Pseudo DMZ"
It is an "exposed host" that lets all traffic unfiltered through

DMZ 3 (a) - Unreal DMZ (One device with a DMZ Port)
One firewall or router with a dedicated port that homes the DMZ subnet, ports can be opened and protocols can be forwarded

DMZ 3 (b) - Unreal DMZ (One device with a own and dedicated hardware DMZ port)
The same as variant (a) but the DMZ port is not connected to the internal switch chip or CPU as the other ports

There will be for sure hundred till thousand  other available constructs and possible ways to march, but they can all and even
pointed to one of that three main types of DMZs. So that we are all talking about the same thing!

If I set up a unreal DMZ, I don´t must open all ports and allow all protocols, I need only to open and forward what the servers
inside of the DMZ are offering as a service, nothing more. And this can be inspected by DPI or usually here in that case with an
IDS/IPS system. Also a proxy can be between the servers and the internet that no one has directly contact to that servers to play
with.

A DMZ is a lazy mans method.

And now the master question here, about what kind of DMZ you are talking here in that case?

You are better off creating a secondary secure subnet\interface and controlling the traffic properly with port triggering\forwarding.

If you someone is demanding a bigger security requirement then others perhaps have a firewall with a dedicated DMZ port is the
base line he should walk on.

@FreeYourMind:

But then again this wouldn`t apply to PRIQ where there is no bandwith sharing but just a priorization of traffic, is that correct?

Thank you

I don't think so because each PRIQ interface is still unaware of any other interface's bandwidth. It's an ALTQ limitation, which all traffic-shaping queue algorithms use (HFSC, PRIQ, CBQ, FAIRQ).

Also, generally, fair queueing is fair per each flow ("connection") so each host could get an unfair amount of bandwidth by having more flows.

The limiter approach I linked is much closer to accomplishing your goals. Though, it may not be able to evenly share beyond a /24 network, so you may need to have both of your LANs in the same /24. Dunno… your problem is a common one but I haven't yet ran into a simple solution that I can link you to. :( Good luck. You'll surely learn some stuff along the way.

Anyone?

I have the same problem. How will I set the rule ? Thanks for your help!

USB Ethernet device uses udav driver which indeed supports altq.
Now the question is: does pfSense support altq on bridges?
I would wonder if it is not the case, according to information found on the internet it should.

So, I've figured out that my floating rule wasn't working as intended, through a back door way.  And I have a solution that may help others.

I ended up creating a LAN rule like this:

Action: Pass
Interface: LAN
Protocol: TCP
Source: Single IP, any port
Dest: Any IP
State Type: Keep
Ack Queue: qAck
Queue: qGames

With this rule, I've homed in on the IP that I really want to make sure gets high priority (for Netflix and Games) and makes sure the Ack packets are getting high priority.  In this mode, the number of Ack packets per second on the WAN side is in the hundreds.  This is what I am expecting, and solves several problems at once.

Hope that's helpful for someone else.

@MLIT:

@Harvy66:

Depends on what layer of "bandwidth" we're talking about. If you assume Ethernet, every 1530 byte Ethernet frame received will result in a 92byte frame sent assuming these frames represent a TCP connection. Nagle is enabled on most systems, so let change that to 92bytes sent for every 3060byte received. That's a 33:1 ratio. 1Gb down will result in 30Mb up of traffic.

This ratio completely changes if you only assume Layer3 data transfers. Then it's 60bytes up for every 3000bytes down, which is a 50:1 ratio or only 20Mb up for 1Gb down. I assumed the worse of the two.

A single ACK can acknowledge several received packets. TCP doesn't acknowledge each packet individually.

It can but only does so in the case of Nagle, which is 2 packets and I addressed above, or you have packet loss. Either way, that doesn't change the fact that you're sending the data. For 99.9999% of network streams, your TCP ingress:egress will typically be either 33:1 or 50:1, depending on what layer you're looking at and what types of layer2s your packets go through.

Have you checked the floating rules?