First-time user (dumb) questions…

georgeman

First things first, I believe this REALLY this to be cleared out somewhere, but the shaper in its current form won't properly handle shaping download on multi-LAN, no matter if the wizards pretends to configure it. The reason is that you cannot have a queue that applies to multiple interfaces at the same time.

Then:

Remember you can only shape out of an interface. You cannot shape in because you don't have control over what comes on the wire from outside. Once it reaches the interface there's not much you can do about it.
So, download is shaped out of LAN, and upload out of WAN.
Traffic between LAN interfaces is shaped, but assigned by default to the qLink queue which has pretty much no limit
If the 3400 Kb limit was set on LAN, it would limit the interface speed to that, limiting also traffic between LANs. That's why it is set on qInternet instead
The sum of linkshare values does not need to sum up 100%, it is just a proportional value against the total sum. For example having 3 queues set as 10%/10%/20% will be the same as having them as 25%/25%/50% (I don't know why the wizards sets it up that way anyway, has to do with the way it calculates)
Linkshare is not the allowed bandwidth, it is just the proportion of bandwidth it will get if all queues are requesting bandwidth at the same time. If no other queues are using bandwidth, it will use 100% (unless you cap it with upperlimit)

Regards!

stefano_noffke

@georgeman:

First things first, I believe this REALLY this to be cleared out somewhere, but the shaper in its current form won't properly handle shaping download on multi-LAN, no matter if the wizards pretends to configure it. The reason is that you cannot have a queue that applies to multiple interfaces at the same time.

So, if I understand correctly, pfSense can shape correctly the download traffic on multiple LANs only if you want to split the available download bandwidth separately for each LAN. For example, if you have a total bandwidth of 20 Mbps and three LANs, and you want to assign 10 Mbps to the first LAN, 7 Mbps to the second, and 3 Mbps to the third.
Otherwise, if you need to have the full 20 Mbps to all three LANs, you must assign 20 Mbps to each LAN; this would sum up to 60 Mbps, which is more than you have available. Therefore, pfSense can not handle this traffic correctly.

Is this correct?

@georgeman:

Then:

Remember you can only shape out of an interface. You cannot shape in because you don't have control over what comes on the wire from outside. Once it reaches the interface there's not much you can do about it.

So, download is shaped out of LAN, and upload out of WAN.

Clear

@georgeman:

Traffic between LAN interfaces is shaped, but assigned by default to the qLink queue which has pretty much no limit

I need some clarifications here…
I assumed the traffic between LANs was not shaped because the only firewall rules created were assigned to the WAN interface.
According to what you say, ALL traffic is shaped no matter what the rules are applied to the firewall. So, since there are no rules on the LANs, the default queue is applied to all traffic going out those interfaces.
The default queue is qLink, which is set to have a "20%" of unlimited (not set?) bandwidth; therefore, I suppose that the traffic will be shared equally between users.

Is this correct?

However, I do not understand how the queue "qInternet" works (And I know that it works since I see the activity on the queue status page) since there are no rules applied to the Firewall on the LAN interfaces. All the "Floating" rules created by the wizard are applied to the WAN interface.

How is the traffic assigned to the correct queues?

@georgeman:

If the 3400 Kb limit was set on LAN, it would limit the interface speed to that, limiting also traffic between LANs. That's why it is set on qInternet instead

It makes sense :)

@georgeman:

The sum of linkshare values does not need to sum up 100%, it is just a proportional value against the total sum. For example having 3 queues set as 10%/10%/20% will be the same as having them as 25%/25%/50% (I don't know why the wizards sets it up that way anyway, has to do with the way it calculates)

Linkshare is not the allowed bandwidth, it is just the proportion of bandwidth it will get if all queues are requesting bandwidth at the same time. If no other queues are using bandwidth, it will use 100% (unless you cap it with upperlimit)

Regards!

It is clear now; Those values were confusing me because they were so specific that I thought they meant more than a simple proportion.

Thank you very much!

Stefano

georgeman

@stefano_noffke:

@georgeman:

First things first, I believe this REALLY this to be cleared out somewhere, but the shaper in its current form won't properly handle shaping download on multi-LAN, no matter if the wizards pretends to configure it. The reason is that you cannot have a queue that applies to multiple interfaces at the same time.

So, if I understand correctly, pfSense can shape correctly the download traffic on multiple LANs only if you want to split the available download bandwidth separately for each LAN. For example, if you have a total bandwidth of 20 Mbps and three LANs, and you want to assign 10 Mbps to the first LAN, 7 Mbps to the second, and 3 Mbps to the third.
Otherwise, if you need to have the full 20 Mbps to all three LANs, you must assign 20 Mbps to each LAN; this would sum up to 60 Mbps, which is more than you have available. Therefore, pfSense can not handle this traffic correctly.

Is this correct?

Exactly :)

@stefano_noffke:

@georgeman:

Traffic between LAN interfaces is shaped, but assigned by default to the qLink queue which has pretty much no limit

I need some clarifications here…
I assumed the traffic between LANs was not shaped because the only firewall rules created were assigned to the WAN interface.
According to what you say, ALL traffic is shaped no matter what the rules are applied to the firewall. So, since there are no rules on the LANs, the default queue is applied to all traffic going out those interfaces.
The default queue is qLink, which is set to have a "20%" of unlimited (not set?) bandwidth; therefore, I suppose that the traffic will be shared equally between users.

Is this correct?

However, I do not understand how the queue "qInternet" works (And I know that it works since I see the activity on the queue status page) since there are no rules applied to the Firewall on the LAN interfaces. All the "Floating" rules created by the wizard are applied to the WAN interface.

How is the traffic assigned to the correct queues?

Great question! The queue assignment is based on the firewall states. When a packet goes out of WAN, that state is marked as belonging to the queue. When the response comes back in, before the package goes out of LAN the system applies the queue on LAN that has the same name as the queue that was originally assigned out of WAN (unless there is a explicit queue defined on LAN). This is why the queues on LAN and WAN have the same names, otherwise it wouldn't work this way and you would need to separately identify and match incoming and outgoing traffic.

The same applies the other way around ,you could queue traffic on your LAN rules (in), instead of floating. In some cases there's no other option, for example if you want to shape based on the source IP and you are doing NAT. If you are doing NAT, out of WAN the packets have already been translated so you cannot queue based on the source IP. You would need to do it on LAN instead

Side note: if there is a queueing rule on both LAN (in) and WAN (out), the one on LAN is the one that will ultimately apply for shaping download

I am really glad you seem to have understood it!

Regards!

stefano_noffke

Thank you very much, everything is much clearer now :)

stefano_noffke

I have one other question (for now) :)

In the Firewall Floating Rules, I see some rules have two queue selected (The qAck queue plus one other), while other queues have only one queue selected.

Why?

If I want to create a new rule, how do I choose to apply it to both the Acknowledge queue and another queue or just the other queue?

Thank you!

Stefano

georgeman

The Acknowledge queue will catch the SYN and ACK packets, so it is actually a good idea to have it select only for TCP protocol rules

stefano_noffke

@georgeman:

The Acknowledge queue will catch the SYN and ACK packets, so it is actually a good idea to have it select only for TCP protocol rules

Thank you.

Let me add yet another question :)

When I ran the wizard, I chose fot the VoIP the "Generic" setting. Now, I wanted to fine tune the shaper for our VoIP.

I checked the firewall rules, and I found out that the rule assigning the traffic to the VoIP queue was a generic "Assign all UDP traffic to the VoIP queue". Something like:
Proto: IPv4 UDP
Source: *
Port: *
Destination: *
Port: *
Gateway: *
Queue: qVoIP

Not the best setting I think…

I changed that rule to actually two different rules: (Note: we are using an external service provider to handle our VoIP calls. Let's call it "sip.voip.org" at the address "1.2.3.4")
FIRST: (Outgoing UDP traffic (RTP) to our VoIP service Provider)
Proto: IPv4 UDP
Source: *
Port: *
Destination: 1.2.3.4
Port: 10000-20000
Gateway: *
Queue: qVoIP

SECOND: (Outgoing TCP/UDP SIP Traffic (port 5060))
Proto: IPv4 UDP
Source: *
Port: *
Destination: 1.2.3.4
Port: 5060 (SIP)
Gateway: *
Queue: qACK/qVoIP

Is this a correct configuration? Did I understand it right?

Thank you.

georgeman

Sounds good. Anyway on the second rule you said "proto UDP", so I wouldn't select an acknowledge queue (unless you know what you are doing)

stefano_noffke

@georgeman:

Sounds good. Anyway on the second rule you said "proto UDP", so I wouldn't select an acknowledge queue (unless you know what you are doing)

The second rule is actually "TCP/UDP", my mistake…

GomezAddams

@georgeman:

Sounds good. Anyway on the second rule you said "proto UDP", so I wouldn't select an acknowledge queue (unless you know what you are doing)

What does selecting an ack queue do for UDP traffic (since UDP doesn't have acks)?

georgeman

@GomezAddams:

@georgeman:

Sounds good. Anyway on the second rule you said "proto UDP", so I wouldn't select an acknowledge queue (unless you know what you are doing)

What does selecting an ack queue do for UDP traffic (since UDP doesn't have acks)?

Not really sure. What I can tell you is that some traffic might be catched, depending on the packet flags I guess. To make sure everything works the way I want, I prefer to create two rules: one with acknowledge queue for TCP, and one without for UDP