Multi-LAN inbound traffic shaping
-
Hello everybody
I have a pfSense setup running on an SG48601U (btw a very nice hardware!). We have one WAN and four separated LANs and I got everything running like I wanted, except for the traffic shaper to run a SIP PBX in one of the LANs. We don't have much bandwidth (only 4Mbit, symmetric) of which I'd like to reserve 200kbits for VoIP traffic in both directions.
The problem I ran into is that pfSense doesn't seem to be able to limit the downstream on the WAN interface. I could only do this by shaping the traffic leaving into LAN, but then I cannot put a limit on the sum bandwidth into all four LANs.
I'm aware of the fact that I cannot prevent anybody from flooding our external IP to kill our inbound bandwidth, but in everyday use people on the LAN will simply do downloads which easily saturate the WAN link. And these downloads are TCP, so dropping inbound packets on these connections will effectively throttle them. I've already verified this in a single LAN test setup and it seems to work. I just can't do it with multiple LANs.
Am I missing something or does that really require a separate pfSense device which I insert on the WAN side just for shaping inbound traffic? That unfortunately also requires a second NAT layer, which probably makes configuring NAT exclusions very annoying…
Do you have any suggestions how to accomplish that?
Rainer
-
Hello everybody
I have a pfSense setup running on an SG48601U (btw a very nice hardware!). We have one WAN and four separated LANs and I got everything running like I wanted, except for the traffic shaper to run a SIP PBX in one of the LANs. We don't have much bandwidth (only 4Mbit, symmetric) of which I'd like to reserve 200kbits for VoIP traffic in both directions.
The problem I ran into is that pfSense doesn't seem to be able to limit the downstream on the WAN interface. I could only do this by shaping the traffic leaving into LAN, but then I cannot put a limit on the sum bandwidth into all four LANs.
I'm aware of the fact that I cannot prevent anybody from flooding our external IP to kill our inbound bandwidth, but in everyday use people on the LAN will simply do downloads which easily saturate the WAN link. And these downloads are TCP, so dropping inbound packets on these connections will effectively throttle them. I've already verified this in a single LAN test setup and it seems to work. I just can't do it with multiple LANs.
Am I missing something or does that really require a separate pfSense device which I insert on the WAN side just for shaping inbound traffic? That unfortunately also requires a second NAT layer, which probably makes configuring NAT exclusions very annoying…
Do you have any suggestions how to accomplish that?
RainerYeah, that's a known limitation. Interfaces can't share bandwidth among each other with queues.
I think you can use traffic-shaping limiters to shape ingress (and egress) traffic on WAN.
-
Okay I see.
I wish I could use limiters, but they can only be specified by source/destination IP, as far as I could see. I can't even invert the filter to make a 'catch all' except SIP-Proxy IP limiter or something like that…
Does anybody have experience with a two-pfSense-Box setup for traffic shaping?
-
Okay I see.
I wish I could use limiters, but they can only be specified by source/destination IP, as far as I could see. I can't even invert the filter to make a 'catch all' except SIP-Proxy IP limiter or something like that…
Does anybody have experience with a two-pfSense-Box setup for traffic shaping?
That's one way to use them but I think you can also use firewall rules to assign whatever traffic you choose to the limiter, just like assigning traffic to traffic-shaping queues.
-
Oh, that would make sense! I'll try this and post back if it works…
-
Okay limiters seem to work, at least partly. I created two limiters with 3.8Mbit/s and assigned them to my 'LAN to outside world' rules of all interfaces and added a separate 'SIP PBX to outside world' rule without assigning the limiter queues.
This works well for all connections established from inside any of the LANs. Unfortunately I'm affected by Bug #4326 and therefore all connections established from outside via NAT port forwarding rules cannot be assigned to these limiters without breaking the port forwarding. :-( Well, it's probably already good enough for a while because it will usually be user downloads saturating the bandwidth. anybody knows when 2.4 will be released? apparently this bug is fixed there.
-
I think I have just noticed one more downside of using limiters for limiting inbound traffic bandwidth: limiters don't care about the kind of packets they drop.
My connection seems to be almost half-duplex now. Doing a download will almost stop uploads and the traffic graph in and out lines fluctuate almost perfectly symmetrical, downstream increases, upstream decreases, it looks like the two lines are mirrored at a line at half bandwidth in the graph. My only explanation for this behavior is that ACKs are being dropped in inbound direction, which hinders the traffic flowing in the other direction.
Can anybody confirm this, or is there any other explanation? I double checked the assignment of the limiters and their directions, etc.
Best Regards
Rainer
-
And the story goes on: it seems that the observed 'half-duplex' behavior is actually not a problem of pfSense. It's really the DSL line! I'm observing the same phenomenon when connecting my machine directly to the DSL modem.
No way to do any kind of traffic shaping if we cannot rely on any specific bandwidth, i.e. when downstream bandwidth is dependent on upstream etc. I guess we have to look for another more reliable connection…
Thanks everybody for the good suggestions!