Hey Chuck. FYI, this was nothing to do with the rule number or the name of the chain. It was related to an openvz related item… The failed command would not work no matter what rule number or chain name was used. In my case, inserting in INPUT with no rule number is meant to insert before the first rule.
However, with the problem - no matter where an insert was tried, it failed. XT_STATE was not active in the openvz container, due to some previous openvz changes etc… that is what it ended up being… (plus upgrading the kernel for good measure). GK > On 22 Feb 2017, at 2:24 PM, Chuck Tetlow <ch...@tetlow.net> wrote: > > Hi Greg, > > The first rule in my firewall chain does the same thing. Its: > iptables -I acctin 1 -p tcp -m state --state ESTABLISHED -j ACCEPT > > That allows any packets that are part of a established connection (no ACK bit > in the header) to flow through without having to go through the rest of the > rules in the chains. The only reason I do this first - I have a LOT of rules > in the acctin chain. > > And my second rule is: > iptables -I acctin 2 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT > > Which allows any new http packet to flow through. The reason for this - I > block out huge parts of the world with /8, and /16 network blocks. This rule > allows anyone anywhere to see the webpages on my server, but no FTP, SMTP, > POP, IMAP, or SSH. They can still poke around and look for vulnerabilities > in the webpages or CMS - but no hacking attempts via other protocols. > > Try that first rule to get the ESTABLISHED packets flowing. But to be > honest, if the first packets with the ACK bit set flow through - anything > after that (considered ESTABLISHED) should flow through too. So that rule > really shouldn't be needed. > > > Oh BTW - the reason your attempt listed below failed is the chain > name/location. When you use the -I switch to input a rule, you have to > provide the chain name and location. So you provided the chain name "INPUT", > but not where in that chain. As you can see in my inputs above - I told it > to put the rule in the "acctin" CHAIN and slot number 1 or 2. You didn't > provide where in the chain to insert that rule. > > Oh. And just FYI - you tried to use the INPUT chain. That's fine, and will > work. But you'll notice that in Blueonyx - the first (and usually only) > thing that INPUT chain does is call the "acctin" chain. So I usually do all > my changes & inputs in the "acctin" chain instead of the "INPUT" chain. (And > yes - those chain names are case sensitive). > > > > Chuck > > > > > ---------- Original Message ----------- > From: Greg Kuhnert <gkuhn...@compassnetworks.com.au> > To: BlueOnyx General Mailing List <blueonyx@mail.blueonyx.it> > Sent: Wed, 22 Feb 2017 09:16:33 +1100 > Subject: [BlueOnyx:20698] Re: errors and issues > > > Further informational [UTF-8?]update⦠While upgrading the kernel would be > > helpful, it is not the answer. (I have the same kernel version on a box > > that does not have this problem). > > This problem is as follows: related and established traffic is not being > > permitted on the inbound iptables rule. I am not an APF guru, so I tried to > > add a manual rule as a [UTF-8?]workaround⦠> > > > > > iptables -I INPUT -j ACCEPT -m state --state > ESTABLISHED,RELATED > > > > > # iptables -I INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED > > iptables: No chain/target/match by that name. > > > > > I had a chat to Chris, and he had a report of someone once with a similar > > problem but was unable to recall the solution. > > > > > My time is diverted elsewhere today - [UTF-8?]Iâll have a look within the > > next 24 [UTF-8?]hours⦠In the meantime, if anyone has some APF wisdom, > > that might get this in the right direction. > > > > > Greg > > > >> >> >> > On 22 Feb 2017, at 7:14 AM, Greg Kuhnert <gkuhn...@compassnetworks.com.au >> > <mailto:gkuhn...@compassnetworks.com.au>> wrote: >> >> > >> > Hi all. >> > >> >> > I just had a look on [UTF-8?]RCâs boxes. This turned out to be something >> > related to APF. Simple test - turn off APF, and that fixed that VPS. >> > Question is why. Still looking into that. >> > >> >> > On the topic of the [UTF-8?]kernelâs - regardless of this problem, I >> > agree 100% that it is a good idea to upgrade the kernel to the newer >> > [UTF-8?]version⦠but I think this may be related to something >> > [UTF-8?]else⦠>> > >> >> > Stay tuned. >> > >> >> > >> >> > >>> >>> >>> > On 22 Feb 2017, at 2:30 AM, Richard Barker <ad...@probass.com >>> > <mailto:ad...@probass.com>> wrote: >>> >>> > kernal is >>> uname -r 2.6.32-042stab116.2 is June 2016 >>> cuurent is 2.6.32-042stab120.18 Jan 2017 >>> >>> Again only one VPS has the issues but I see what you are saying. >>> Both Maser an Slave node are running 2.6.32-042stab116.2 >>> >>> Not sure which way to turn. >>> >>> On the backup node have this error in Cluster Settings >>> Bypassing any DRBD related tasks as this does not appear to be a cluster >>> ready box. >>> >>> This node was not set up as 'cluster-ready' as /etc/vz does not appear to >>> be a symlink. >>> >>> Oh joy no joy >>> RC >>> >>> > -- >>> >>> > Richard C. Barker Sr. >>> CEO & President >>> 1-813-873-8942 >>> ProBass Networks Inc. >>> www.probassnetworks.net <http://www.probassnetworks.net/> >>> www.probass.net <http://www.probass.net/> >>> *************************************** >>> DISCLAIMER : - >>> This e-mail is confidential and intended only for the use >>> of the individual or entity named above and may contain >>> information that is privileged. If you are not the intended >>> recipient, you are notified that any dissemination, distribution >>> or copying of this e-mail is strictly prohibited. If you have >>> received this email in error, please notify us immediately >>> by return email or telephone and destroy the original message. >>> _______________________________________________ >>> Blueonyx mailing list >>> Blueonyx@mail.blueonyx.it <mailto:Blueonyx@mail.blueonyx.it> >>> http://mail.blueonyx.it/mailman/listinfo/blueonyx >>> <http://mail.blueonyx.it/mailman/listinfo/blueonyx> >> >> _______________________________________________ >> Blueonyx mailing list >> Blueonyx@mail.blueonyx.it <mailto:Blueonyx@mail.blueonyx.it> >> http://mail.blueonyx.it/mailman/listinfo/blueonyx > > > ------- End of Original Message ------- > _______________________________________________ > Blueonyx mailing list > Blueonyx@mail.blueonyx.it > http://mail.blueonyx.it/mailman/listinfo/blueonyx
_______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
