So...

I deleted and recreated limiters, etc. from scratch, now BW is throttled as expected. Gotta love computers.

All I had done previously was uncheck "Use this limiter and children" and check "Disable this rule" in the Floating Rules and it seemed to break it for good.

@thondwe said in Two Lans - ones an invisible LAG!?:

so LAGG not supported by queues - fair enough.

Hello,

https://docs.netgate.com/pfsense/en/latest/interfaces/lagg.html

4b0b98a3-f992-4d74-902e-8b455f068515-image.png

Looks like support for ix drivers and ALTQ might be fixed in 2.5.0?

See last comment at end of:
https://redmine.pfsense.org/issues/7378

@tiger-0 said in Access Point Bandwidth Management:

We are hoping to have things less work by limiting the bandwidth per access point instead of the user

Just put limiters on each LAN interface.

@edmond

I am just using PfSense for the PPPoE part. I have an external Freeradius server runnning on Ubuntu 18.04.

You need to add the dictionary as per the "redmine" link in a post before this one.

See https://redmine.pfsense.org/issues/11102

@Modesty How much the protocol is universally used for illegal or legal activities isn't relevant, you're making an assumption of your tenants use which unless you have data, or notices from your ISP could be incorrect. For example, you mention they use Steam, Steam uses the BitTorrent protocol to distribute data between players so they may not be doing anything illegal at all. I would say though that if the legal ramifications are a concern then you should consider having your tenants subscribe to their own service rather sharing yours. Depending on your ISP you might also be breaching your ISPs ToS by providing service to tenants not leaving you in a great defensible position should they be up to no good post gaming.

I have moved over to using QFQ (which I believe is default selected in pfSense UI) for downstream combined with Codel on the child queue. (this seems to match HFSC performance on ALTQ).

fq_codel works awesome for egress, but not so good for ingress on consumer broadband in my experience.

What i did in limiter configuration.

Pipe set the limit as documented, use droptail.
Scheduler set to QFQ
Queue set to Codel. Also on queue configure src-ip and src-ip6 masks, I used /16 for ipv4 and /56 for ipv6. I will probably change ipv6 to /48.

The idea been I dont want a flow for each individual ip, so many would be created, instead to have traffic from same providers in their own flow, /16 will usually cause that, although it will be possible you may have 2 different providers at once in the same /16, in practice this seems rare though. As an example if I used /32 for flow separation and a steam download (32 threads) was competing with a twitch stream, then it would be 32/33 bandwidth allocated to steam and 1/33 allocated to twitch, with /16 it would be 50/50.

Floating rules would be same as documentation. This still is not 100% for me but its working better for ingress than fq_codel. fq_codel I had to reduce flow limit's to 20 but that flooded my console with warnings and I still didnt have as good performance as QFQ.

Also with this system the flows are visible in the diagnostics -> limiter screen whilst fq_codel hides its internal flows. So you can see which flows have packets dropped by the shaper, to determine how well things are working.

yeah I would love cake as well, but sadly I cannot see any information on it been ported to dummynet, it looks like nothing is happening for that. :(

@luiscachog Unfortunately Zoom does not keep (https://assets.zoom.us/docs/ipranges/Zoom.txt) up to date. I have found at least 10 other IPs I had to add. Everyday there seems to be a new IP. I may see if QoS DSCP Marking can be turned on by the host.

Not an emergency, but a real issue, no one has experienced this?

The floating rule should match regardless of interface (think of a router with 5 interfaces trying to duplicate all the shaping rules). There's not a need to tie them to interfaces.

The wizard sets up a default setup. I think I would delete and run the wizard if changing types.

The queues affect outbound traffic for the interface so downloading from the Internet would be LAN outbound and ack would be WAN outbound. The rules get set up differently, for instance I think VOIP UDP traffic doesn't have an interface but has a rule for Source and another for Destination. But POP/SMTP etc. TCP gets set on WAN according to destination port by default.

@Arnaud09

Assumption:
You portforward those 3 services, each to their own isp inside lan ip ?

Then i would put the pfSense wan on your isp routers inside lan on (fixed) ip addr xxx ... Don't use DHCP , and remember to set default gw on the pfsense to your routers inside ip address.

And "portforward" the wanted ports on your isp router, to the routers inside lan on ip addr xxx (the pfSense wan ip).

Now matching (portforwarded) traffic will hit the pfSense Wan interface.

Then you need to do the same portforwarding once more on the pfSense , to portforward the interesting stuff on the WAN to the LAN.

Now you can control access to the pfSense LAN (that would be your service lan) , by putting access rules on your pfSense wan interface (preventing unwanted packages from entering the WAN .. And thereby access the Lan.

Be sure that your ISP router inside lan , and your pfSense inside lan does not have the same ip range or it will never work.

I might have given multiple VIP's a try .. Haven't used those yet.
But that might not be easy for a "Non experienced person"

If you are able to add routes to your ISP Router , things might become a lot easier.

/Bingo

@bobbenheim - I double checked and both limiter and child queue are already set to tail drop.

Here are my settings (120M in, 12M out):

target 5
interval 100
quantum 300
limit 10240
flows 20480

I think I got them from one of the posts here. It has been working ok with these since 2.4.5 came out.

I still think that I had caused a problem with the pfblockerng floating rules located before my limiter floating rules. I have reversed the order and so far the log entries have not shown again.