Has anyone encountered a situation where packets dropped by the newnotsyn chain can result in sporadic browsing problems, slowness, and even timeouts? I noticed that of the 3300 hits for newnotsyn in our current log (6 hours worth), over 2700 of them were to/from our proxy servers. And browsing through them, most *appear* to be otherwise valid packets from remote web servers that would have been allowed back to our proxy. A few examples follow: (139.142.66.152 is our proxy) Nov 24 21:55:42 fw kernel: Shorewall:newnotsyn:DROP:IN=eth1 OUT=eth0 SRC=12.158.80.10 DST=139.142.66.152 LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=7567 DF PROTO=TCP SPT=80 DPT=3693 WINDOW=6432 RES=0x00 ACK FIN URGP=0 Nov 24 21:55:45 fw kernel: Shorewall:newnotsyn:DROP:IN=eth1 OUT=eth0 SRC=64.94.110.11 DST=139.142.66.152 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=26811 DF PROTO=TCP SPT=80 DPT=3485 WINDOW=6432 RES=0x00 ACK FIN URGP=0 Nov 24 21:56:03 fw kernel: Shorewall:newnotsyn:DROP:IN=eth1 OUT=eth0 SRC=12.158.80.10 DST=139.142.66.152 LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=17793 DF PROTO=TCP SPT=80 DPT=3599 WINDOW=6432 RES=0x00 ACK FIN URGP=0 So, although the docs indicate I shouldn''t need to, I set NEWNOTSYN=Yes and restarted. So far, things *seem* to have improved. Am I hallucinating? Has anyone else seen this? Is this implying a "broken IP stack" as in the docs, either at the remote end, or local? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Shawn Wright, I.T. Manager Shawnigan Lake School http://www.sls.bc.ca swright@sls.bc.ca
On Thu, 2004-11-25 at 09:07 -0800, Shawn Wright wrote:> Has anyone encountered a situation where packets dropped by the > newnotsyn chain can result in sporadic browsing problems, slowness, and > even timeouts?Haven''t seen it but it doesn''t surprise me either.> > So, although the docs indicate I shouldn''t need to, I set > NEWNOTSYN=Yes and restarted. So far, things *seem* to have > improved. Am I hallucinating? Has anyone else seen this? Is this implying > a "broken IP stack" as in the docs, either at the remote end, or local? >The theory behind disallowing new-not-syn packets works in a perfect network. The internet is far from perfect. I notice that you are running Shorewall 1.4.8 -- I changed the NEWNOTSYN default to "Yes" in 1.4.9 because I believe that a setting of "No" causes too many problems to be the default. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On 25 Nov 2004 at 9:16, Tom Eastep wrote:> On Thu, 2004-11-25 at 09:07 -0800, Shawn Wright wrote: > > Has anyone encountered a situation where packets dropped by the > > newnotsyn chain can result in sporadic browsing problems, slowness, and > > even timeouts? > > Haven''t seen it but it doesn''t surprise me either. > > > > > So, although the docs indicate I shouldn''t need to, I set > > NEWNOTSYN=Yes and restarted. So far, things *seem* to have > > improved. Am I hallucinating? Has anyone else seen this? Is this implying > > a "broken IP stack" as in the docs, either at the remote end, or local? > > > > The theory behind disallowing new-not-syn packets works in a perfect > network. The internet is far from perfect. > > I notice that you are running Shorewall 1.4.8 -- I changed the NEWNOTSYN > default to "Yes" in 1.4.9 because I believe that a setting of "No" > causes too many problems to be the default.Tom, this is clearly my fault for not posting my shorewall.conf, as someone would have surely pointed this change out to me if I had. It''s also my fault for not seeing this comment in the 2.0.10 shorewall.conf file: # I find that NEWNOTSYN=No tends to result in lots of "stuck" # connections because any network timeout during TCP session tear down # results in retries being dropped (Netfilter has removed the # connection from the conntrack table but the end-points haven''t # completed shutting down the connection). I therefore have chosen # NEWNOTSYN=Yes as the default value. However, might I suggest making this change more evident in the docs, perhaps including the above paragraph in the HTML docs, and/or the Upgrade Issues pages? When I upgraded from 1.4.8 to 2.0.10, I didn''t get the new setting because I kept my old configs. I did pore over the Upgrade Issues page, but didn''t notice this change there either. Just a suggestion that might help others in the same boat as me someday... Thanks for all your help! If this really is the problem, perhaps I can finally get some sleep... Shawn Wright, I.T. Manager Shawnigan Lake School swright@sls.bc.ca
On Thu, 2004-11-25 at 09:50 -0800, Shawn Wright wrote:> # NEWNOTSYN=Yes as the default value. > > However, might I suggest making this change more evident in the docs, > perhaps including the above paragraph in the HTML docs, and/or the > Upgrade Issues pages?I''ve added a note in both places. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
I just had a look at my shorewall.conf (2.2.0-Beta1) and noticed a typo; --- shorewall.conf 2004-09-28 07:58:07.000000000 +0930 +++ shorewall.conf.fix 2004-11-26 06:43:13.000000000 +1030 @@ -521,7 +521,7 @@ # A packet is said to be NEW if it is not part of or related to an already # established connection. # -# The NETNOTSYN option determines the handling of non-SYN packets (those with +# The NEWNOTSYN option determines the handling of non-SYN packets (those with # SYN off or with ACK or RST on) that are not associated with an already # established connection. # regards Andrew Braund
On Fri, 2004-11-26 at 06:21 +1030, Andrew Braund wrote:> I just had a look at my shorewall.conf (2.2.0-Beta1) and noticed a typo;Thanks, Andrew. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key