[squid-users] strange reply denials based on rule ordering

From: Brian J. Murrell <brian_at_interlinx.bc.ca>
Date: Mon, 30 Dec 2013 10:56:37 -0500

Hello,

I've come across a recurring issue where Squid (3.2.1) will deny replies
(TCP_DENIED_REPLY/403) purely based on where in the rule list (which is
all allows with one deny at the end) the rule is.

For example, with the following rule list:

http_reply_access allow redirect
http_reply_access allow jenny_pc
http_reply_access allow jodys_pc
http_reply_access allow kates_phone
http_reply_access allow kate_laptop
http_reply_access allow brians_tablet
http_reply_access allow allowed_content
http_reply_access allow pvr_pc
http_reply_access allow pvrfe_pc
http_reply_access allow linux_pc
http_reply_access allow localhost
http_reply_access allow brian_laptop
http_reply_access allow lab_net
http_reply_access allow brian
http_reply_access allow kate
http_reply_access allow fred
http_reply_access allow plf rpm_content
http_reply_access allow thac rpm_content
http_reply_access allow mandriva rpm_content
http_reply_access allow gpg_keyservers gpg_content
http_reply_access allow ubuntu deb_content
http_reply_access allow flash_downloads deb_content
http_reply_access allow windowsupdate windowsupdatere
http_reply_access allow windowsupdate allowed_wu_content
http_reply_access allow avgupdate app_oct_content
http_reply_access allow dl_sf_net app_oct_content
http_reply_access deny all

I will get:

1388416169.296 22 2001.123.45.678:214:d1ff:fe13:45ac TCP_DENIED_REPLY/403 3692 GET http://af.avg.com/softw/14free/update/x14xplsc_2067ol.bin - FIRSTUP_PARENT/127.0.0.1 text/html

However if I move the rule that should allow that URL (allow avgupdate
app_oct_content) to near the top of the above rule list squid will allow
the content.

I would think that the order of any "allow" rules should not matter as
long as they are all before a deny rule. Is that not the case? Should
what I describe above really happen in any condition?

Cheers,
b.

Received on Mon Dec 30 2013 - 15:56:53 MST

This archive was generated by hypermail 2.2.0 : Tue Dec 31 2013 - 12:00:05 MST