On Fri, Feb 28, 2014 at 12:06 PM, Dan Ritter <[email protected]> wrote:
> On Fri, Feb 28, 2014 at 11:16:42AM -0500, John Miller wrote: > > > > What should be hit: > > -A RH-Firewall-1-INPUT -s 129.64.0.0/255.255.0.0 -p tcp -m state > > --state NEW -m tcp --dport 636 -j ACCEPT > > > > What is actually being hit: > > -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited > > > > Anyone run into this sort of problem before? > > Needs more context. That second rule matches EVERY PACKET > that gets into RH-Firewall-1-INPUT. > 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. > Also, why look at the state of the packets if you're accepting > NEW? You sometimes want to match NEW for mark-and-mangle > purposes, but otherwise I don't see it. Simpler as: > 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. > > # accept LDAP from 129.64 > -A RH-Firewall-1-INPUT -s 129.64.0.0/16 -p tcp --dport 636 -j ACCEPT > > 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. > Do you have matching rules for counting packets? If not, add > them. > I'm logging, but hadn't turned on packet counting. Certainly can't do any harm to do so. Thanks for the idea! > Does it go away with a flush or reboot? If so, there's something > adding rules after the first time they're set up. > > 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. John
_______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
