RE: Possible BUG in NetFilter conecction state module (testing HA
enviroment)Hello,
>>iptables -I FORWARD -p tcp --dport 23 -j ACCEPT
>>iptables -I FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>With the rules of your setup, there is no need to copy any state.
>Remember, ESTABLISHED has nothing to do with tracking SYNs or ACKs,
>it just means the connection tracking code has seen packets go in two
>directions: the first packets that goes from source to dest:23 will
>get the state NEW, but will get through your firewall (CASTOR in
>your case, after the failover) based on your first rule, regardless
>of any bits in the tcp header.
>When the reply comes back, the connection tracking code will mark the
>connection as ESTABLISHED, because it has just seen traffic go both
>ways. And based on this ESTABLISHED state, the packet will get through
>thanks to your second rule.
Wow, you have killed all my supposed knoledgue about netfilter stateful
inspection :))), thanks por the lesson, but the next question will be... and
how can I implement a fully connection-state aware filtering ?.
I could check SYN/ACK bits in filtering rules, but I can't imagine how I can
block TCP sessions that have not had a SYN/ACK handshake before.
>Also, before anyone starts complaining about security implications :-),
>please note that you can write tighter rulesets that check on TCP
>bits in addition to connection tracking state.
Yes, because of that I write "possible", but I expect more than one reply in
this list :)
Thanks for your answer,
Sancho Lerena,
