<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 28, 2014 at 12:06 PM, Dan Ritter <span dir="ltr"><<a href="mailto:dsr@randomstring.org" target="_blank">dsr@randomstring.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Feb 28, 2014 at 11:16:42AM -0500, John Miller wrote:<br>
><br>
> What should be hit:<br>
> -A RH-Firewall-1-INPUT -s <a href="http://129.64.0.0/255.255.0.0" target="_blank">129.64.0.0/255.255.0.0</a> -p tcp -m state<br>
> --state NEW -m tcp --dport 636 -j ACCEPT<br>
><br>
> What is actually being hit:<br>
> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited<br>
><br>
> Anyone run into this sort of problem before?<br>
<br>
Needs more context. That second rule matches EVERY PACKET<br>
that gets into RH-Firewall-1-INPUT.<br></blockquote><div><br></div><div>Apologies for the lack of context.  The 2nd rule is the last rule in our chain, so we reject everything that's made it that far.<br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, why look at the state of the packets if you're accepting<br>
NEW? You sometimes want to match NEW for mark-and-mangle<br>
purposes, but otherwise I don't see it. Simpler as:<br></blockquote><div><br></div><div>Other folks have wondered the same thing.  These rules predate my tenure here, so I can only guess as to their intent.  I also don't see much reason for matching on NEW for traffic we want to accept.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
# accept LDAP from 129.64<br>
-A RH-Firewall-1-INPUT -s <a href="http://129.64.0.0/16" target="_blank">129.64.0.0/16</a> -p tcp --dport 636 -j ACCEPT<br>
<br></blockquote><div><br></div><div>Did this over the weekend.  Definitely allows through a bunch of RST-flagged packets (presumably being declared as INVALID); inconclusive so far if SYN-flagged stuff is still being blocked.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Do you have matching rules for counting packets? If not, add<br>
them.<br>
</blockquote><div><br>I'm logging, but hadn't turned on packet counting.  Certainly can't do any harm to do so.  Thanks for the idea!<br> </div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Does it go away with a flush or reboot? If so, there's something<br>
adding rules after the first time they're set up.<br>
<br></blockquote><br></div><div class="gmail_quote">I don't believe so.  Only a small fraction of packets actually get rejected, so if a flush fixes things, they're broken again before I notice anything.<br><br>John<br>
</div></div></div>