@Nullity:

The restart likely worked because it reset the states, which you can do without restarting by going to Diagnostics -> States in the pfSense GUI.

That was incorrect of me. I've just restarted the modem and everything was fine. During the configuration I've resetted the states several times on the pfsense machine.

VOIP traffic likely needs to be prioritized with traffic-shaping.

DMZ or port-forwarding is likely a non-issue since these things would only help if the VOIP was non-functioning. Since VOIP is functioning, but not functioning optimally, it likely needs to have the proper bandwidth allocated with traffic-shaping.

@Nullity:

@AbdulCebbar:

@vesikk:

https://forum.pfsense.org/index.php?topic=63531.0

Follow foxale08's guide on that page for what you want. That's what I used to achieve what you are trying to achieve.

That config was working, after one of the pfsense updates there was an alert saying layer 7 limiter won't work anymore. And it didn't work. Now there is no guide to do it in new version.

Limiters have nothing to do with layer 7. foxale08's tutorial should still wor,,k.

Ok it's working but now my nat reflection is broken somehow, is this related?

I'm going off of memory, but I noticed qACK and other realtime queues only have realtime set. You may also need to set the non-realtime bandwidth.

Ok, I have reset them, but same problem still exist:

All traffic goes to qACK, I would have expected to see the Mbps going to qIPTV queues. All traffic is in the interface LAN only? I would expected that all queues on the WAN would have higher speeds comparable with the sum of all LAN's?

Screenshot attached while recording a HD program. No other computers are running as nobody is home at this moment:

1.jpg
1.jpg_thumb

Unfortunately, it will not filter all traffic from my lan

it seems to work but it takes some time to filter traffic ( it needs a few second to reduce traffic ) but in the end it works

since I have no idea if the IP address changes or if it's load balanced, etc

Ask your VoIP provider.  It's not a secret so they should have no trouble telling you the exact IP addresses or ranges they use.  Make an alias and then use the alias as your SIP server.

Why is VOIP different?

Those other options link to rules involving a specific port used by those particular devices.  With a generic provider, you must specify the IP address.  If you know that all your phone traffic uses port 5060 for instance, then you could craft floating rules that trigger on that port instead of needing to use a source/destination IP address.

Sorry SSP, had notify on but somehow missed ur first reply. No, I never did get a response and haven't had time to revisited the issue without something to go on. So glad you took the time to test actual behavior of the dynamic limiter. Odd the limiter screen shows buckets being shared.

If I understood correctly (sorry, TL;DR), your problem is that you are applying the rules on the LAN interface.

In this case, it is best to create floating rules with direction OUT, on each of the WANs. It does not matter how the gateway groups or the routing are configured.

Whatever gets OUT of the specified WAN, will go into the specified queue, period. Of course you will need two "trees" within the shaper, to accomodate each of the WANs

My general advice is to always tag traffic with floating rules direction out on the proper WAN interface

Traffic within the tunnel is seen in and out of the "IPsec" interface as far as the shaper goes, not your WANs.

The wizard is completely broken, I would suggest to configure everything manually.

Best regards!

I'm still around, glad that post is still useful ;D

Not sure about LAGG, but with regular VLANs I found the best way is the following (call it bug or feature, you choose):

Send LAN1 traffic untagged Send LAN2 traffic tagged as some VLAN Send any other LAN network traffic tagged as well

Then, from a shaper standpoint, you will see all the traffic from all the VLANs on the LAN1 (untagged) interface

Yes, I know, some networking purists will complain that you should not send untagged traffic on a trunk, but it works

If you choose to go with something like this, you need at least two separate physical interfaces, one for your LAN VLANs and another for your WAN VLANs

The shaper is messed up in many ways, this is one of them.

This "bug" could easily become a "feature" if you have two physical interfaces and you run your WAN VLANs on one of the them and your LAN VLANs on the other. This "traffic grouping" you see is the only practical way to achieve proper multi-LAN shaping (when you have multiple internal networks, you actually want all the traffic on the same parent queue, from a shaper standpoint)

Prioritize the destination port and/or IP of the VOIP traffic.

Check: https://doc.pfsense.org/index.php/Limiters

@Harvy66:

If you laptop was conencted via wifi, Window may have been load balancing LAN and WIFI, which if they had separate IP addresses, would get different buckets. Just a random thought.

thanx, but limiter has 4 MBit for all pcs, not per single host. and in 99% of time it's working.

and i'm sure that connection was only via wifi, there no physical opportunity to be simultaneously in lan and wifi.
i found another thread in this forum with problem on vmware and shaping. May be it's similar issue.

probably this is due to virtualization on hyper-v 2012 (not R2) and some unusual internal methods of getting w10 image from w8 side. May be a lot of active connections on 80 ports from single host.

another problem is that i can't reproduce it at all, but it was twice.

You might get more help if you post your question in the Traffic Shaping forum.  Honestly, I don't know how you make it past all of the actual Support forums, all broken down by category, and end up posting your problem here in General Discussion.

Yes.  For floating rules, last match wins.  For all other rules, first match wins.  You can change this behaviour with floating rules by editing the rule and checking the Quick checkbox.

@mhertzfeld:

Question.

Since the VPN traffic passes through the WAN to get to the VPN provider, would shapping on the WAN and the interface used for the VPN cause issue?

Would shaping the traffic on the WAN be enough when using CoDel?

If you want to shape all aggregated VPN traffic, shape on the WAN.
If you want to shape individual traffic types within the VPN, shape on the VPN interface, but any shaping done here will additionally be shaped by the WAN. (I'm unacquainted with VPNs, so be wary of my advice.)

I would highly recommend that you upgrade your unit to 2.3.2.

https://doc.pfsense.org/index.php/Limiters

YouTube has some How-To videos, a quick search shows lots of articles on the web about using limiters.

#2 is hard because BitTorrent was designed to avoid filtering and use as much bandwidth as possible (by default).  The only way to avoid it without expensive DPI would be for you to classify every traffic type that you expect to see on your network and block all else.  Even that can be gotten around by using port 80 for your BT port, for example.

Hi guys, sorry I've been a bit flat out and off the air for the last few days.
Firstly, thanks heaps for the help so far :)

To answer "How does a single interface have multiple "links"" and to clarify my goal for Nullity, what I mean by that is that we have one interface for each client, but a single client might have multiple remote sites. In that case, we have multiple MPLS/PrivateIP tails being routed into one interface at the carrier/ISP level.

So I'll have (as a loose example of what's happening, made up subnets etc.), OPT1 having an IP address of 10.1.2.6/29 which is a "hand-off" to our provider. the 10.1.2.1 IP is their side of the handoff.

We'll then have three sites,
Site 1: 20/20Mbit, LAN Range 10.100.1.0/24, WAN side is Hand-off to ISP on 10.1.3.0/29
Site 2: 8/8MBit, LAN Range 10.100.2.0/24, WAN side is Hand-off to ISP on 10.1.3.8/29
Site 3: 25/10MBit LAN Range 10.100.3.0/24, WAN side is Hand-off to ISP on 10.1.3.16/29

On each handoff the first IP is the ISP end, last is the site end.

On the site routers their default route is the ISP end of their handoff, the ISP then has a routing table on the VRF for that client which points everything back at the 10.1.2.6 IP on OPT1 on our router, and points each of the site's subnets back at the relevant router.

On our router we have a static route for each of the site's LAN range (10.100.[1,2,3].0/24) pointing at 10.1.2.1, the ISP then routes that to the router on the relevant site.

So my issue is that I have three sites/links, each with different speeds, terminating on the one interface on our end and I need to do some sort of QoS to each of them so the root queue speed is the issue I guess.

Just thinking out loud… if the interface/root can be set to "100%" (or total of links), then have a second level per site, then the queues under it, that would probably work, but I don't see it letting me create a multi-level hierarchy...