I am noticing an odd issue between squid and my firewall setup on a squid proxy system I put together. Periodically, it seems like the IPFW dynamic rules that get created when squid connects out will expire too early, thus causing inbound packets to hit a deny all established rule that comes after my check-state rule. Has anyone seen anything like this before? It seems like I am missing a sysctl tunable somewhere, or I have something set that ought not be.
Here's what my current
In the above set of rules, it's rule #7 that's the indicator of something wrong. When the issue does happen, I can run
What I am not sure about is whether the problem with with squid, if there's something off about my firewall script design, or something tied to how IPFW operates, presumably a sysctl tunable not set right. I highly suspect the problem is the dynamic rules created for squid's outbound connections are getting reaped too quickly, causing something to go weird between squid's idea fo the connection states and IPFW's idea.
FWIW, I am using the RACK TCP stack and H-TCP algorithm for congestion control. I can post my /etc/sysctl.conf file if needed to help debug this. Squid's version is 4.9, and the base OS is 12.1-RELEASE-p1.
Here's what my current
ipfw show command looks like:
Code:
# ipfw show
00001 9116 3474092 allow ip from any to any via lo0
00002 0 0 deny ip4 from any to 127.0.0.0/8
00003 0 0 deny ip4 from 127.0.0.0/8 to any
00004 0 0 deny ip6 from any to ::1
00005 0 0 deny ip6 from ::1 to any
00006 0 0 check-state :default
00007 3174079 126963855 deny tcp from any to any established
00008 78062 58346526 allow tcp from any to any out via em0 setup keep-state :default
00009 1768 196561 allow udp from any to any out via em0 keep-state :default
00010 0 0 allow sctp from any to any out via em0 setup keep-state :default
00011 391 32960 allow icmp from any to any out via em0 keep-state :default
00012 276 19200 allow ipv6-icmp from any to any out via em0 keep-state :default
00013 0 0 deny log ip from any to any out via em0
00020 0 0 deny ip from any to any in via em0 frag
00021 289 32762 deny { tcp or udp } from any to any 135-139,445 in via em0
00022 0 0 deny udp from any 27036 to any 27036 in via em0
00023 5834 1347938 deny ip4 from any to 224.0.0.0/4 in via em0
00024 0 0 allow icmp from any to any in via em0 icmptypes 0,3,8,9,10,11,12,13,14 keep-state :default
00025 0 0 allow ipv6-icmp from :: to ff02::/16 in via em0 keep-state :default
00026 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 in via em0 keep-state :default
00027 24 4032 allow ipv6-icmp from fe80::/10 to ff02::/16 in via em0 keep-state :default
00028 200 13720 allow ipv6-icmp from any to any icmp6types 1,2,3,4,128,129,133,134,135,136,160,161 in via em0 keep-state :default
00030 45944 3746595 allow tcp from table(ssh-allowed) to any 22 in via em0 setup keep-state :default
00031 61417 60593862 allow tcp from table(squid-allowed) to any 3128 in via em0 setup keep-state :default
00032 0 0 deny log ip from any to any in via em0
65533 15 1240 deny log ip from any to any
65535 0 0 deny ip from any to anyIn the above set of rules, it's rule #7 that's the indicator of something wrong. When the issue does happen, I can run
ipfw show repeatedly and watch the denied packets count climb at a rate of 200-400 per second. If I have firewall_logging="YES" set in /etc/rc.conf, then the HDD activity light blinks very fast or goes solid due to the huge volume of writes to /var/log/security.What I am not sure about is whether the problem with with squid, if there's something off about my firewall script design, or something tied to how IPFW operates, presumably a sysctl tunable not set right. I highly suspect the problem is the dynamic rules created for squid's outbound connections are getting reaped too quickly, causing something to go weird between squid's idea fo the connection states and IPFW's idea.
FWIW, I am using the RACK TCP stack and H-TCP algorithm for congestion control. I can post my /etc/sysctl.conf file if needed to help debug this. Squid's version is 4.9, and the base OS is 12.1-RELEASE-p1.