Simple limiter blocks traffic selectively (some sites blocked, others load)
-
This should not be hard.
I set up a standard limiter at 25% of our bandwidth: 512k, one for in ,one for out.
Enable limiter and its children: check!
Bandwidth 512 Kbit/s, schdule: none
Mask: NoneJust the same for out.
Firewall rules on the LAN interface:
pass/LAN/any/source (alias called 'slow') advanced: in512/out512I also have CODELQ enabled on the WAN and LAN. About the easiest traffic limiter configuration evar. Yay.
Except… users in the "slow" group can get to most HTTPS sites (not all), and so far as I've tested, no port 80/HTTP sites. There is a selective availability within the HTTPS group - for example Amazon doesn't work, but google does. Very, very odd. I can see no reason why this should be so, but if I disable the rule, all access works.
Enable the rule... jammed.
Anyone else see anything like this or have any hints? Running 2.2.1 i386.
-
Updates to my issue. Pictures always help sell a problem:
this shows the overall traffic shaper that applies to everyone
shows the limiters created: one for DHCP address handouts and one for the random collection of windows servers that would otherwise crush the network with their incessant patching of critical security flaws that are discovered at a rate of about 10 an hour on windows servers.
All four of the limiters are identical except direction. They create four shared 512kbps (out of 2mbps total LAN), one in and one out for the server group and for dynamic DHCP pool supplicants.
shows the whole of the LAN rules (WAN rules are only default). The Lan rules are only to apply the limiters to each of the two groups.
shows the very simple rule: basically just applying the limiter to an alias, which is either one C-class (Dynamic DHCP lessees) or a couple of C-classes (windows servers on the network).
shows the limiter info - everything appears to dump into a single bucket - even if they are different IP blocks. That's OK, but perhaps there can only be one catch-all limiter? (If so, perhaps the interface should check)?
But I still don't understand why limited traffic has weirdly, selectively limited web access. It isn't zero - as noted in the OP, most SSL sites work. Most non-SSL sites don't, but it isn't universal. Putting a machine on a static address, which means these rules don't apply instantly fixes the problems. Disabling the rule that puts them in the limiter pool instantly fixes the problem.
But the limiter is really a good thing and it will be bad here if it doesn't work…
Thanks for any insights or help. In the mean time, I'll try to create a single limiter with C-class size pools.
-
Just re-verified with another person's computer. This is very easy to replicate:
They were in an IP block that was sent to the "slow" limiter and could reach, for example, google.com and gmail.com and download email to the client on their iPad, but could not get the DHL (dhl.com) site to load.
Disabling the rule that applied the limiter to the alias for the Dynamic DHCP group restored access to dhl.com.
Creating a static mapping into a non-limited IP block restored access to dhl.com.
The limiter blocked dhl.com, but not google.com.
That is certainly not a documented feature.
-
A little more testing. I updated the limiter rules to no avail. Any computer in the subjected to the limiter cannot get to port 80 sites. 443 seems to work fine. Email (587 etc.) works fine. 80, not so much. Pinging the remote servers works fine from the limited client.
There are NO other rules, not LAN, not WAN, not floating. It is just a traffic limiter, that's all I'm trying to do and there seems to be a bug in it that is blocking 80.
Updated limiter configuration. Now just one for your limiting convenience.
The limiter. Very simple but now with /24 pipes to achieve almost the same intent as two limiters, but with just one.
This is the only non-as-shipped rule. Seriously - no floating or WAN rules at all.
Details of the only rule. Such basic!
And the diagnostic output. It is doing the right thing. No indication of problems.
despite setting logging for the one limiter rule, I haven't found anything relevant in the logs.
-
Simple question. Do You have transparent proxy w/ Squid3 enable?
-
Yes, transparent proxy with squid-2.7.9_4-i386 (not 3) was enabled.
And while I thought I had tested and ruled it out earlier, I tried again today and found out I hadn't, thank you for the suggestion:
| Limiter | Squid 2 | Limited | Normal |
| YES | YES | NO 80 | NORMAL |
| YES | NO | NORMAL | NORMAL |
| NO | YES | NORMAL | NORMAL |
| NO | NO | NORMAL | NORMAL |Note that even in the first case, with squid on, traffic that isn't subject to the limiter rule has no trouble reaching port 80, even going through squid. Squid appeared to be working properly for traffic not subject to the limiter rule.
-
I think I remember reading that there is an issue with limiters in conjunction with Squid.
-
@KOM:
I think I remember reading that there is an issue with limiters in conjunction with Squid.
Sarcastic? There are many posts about squid3+limiters problem…
Squid3 with limiters actually doesn't work... seems a compatibility issue
-
Yes, transparent proxy with squid-2.7.9_4-i386 (not 3) was enabled.
I thought for months that I really need squid. But after I changed my mind my life become really better.
-
Sarcastic? There are many posts about squid3+limiters problem…
And I don't pay them much attention since a) I don't use limiters, and b) I don't use transparent proxy is a terrible idea. I don't try to be sarcastic when I'm genuinely trying to help people for free on my personal time.
-
It's basically the same problem as in here…
https://forum.pfsense.org/index.php?topic=91299.0Sam
