Hi Sancho,
>Someone can explain me how its possible without a process for copying
>connection tables between each Firewall node?. CASTOR don't know nothing
>about connection between ATHENA and MINOS, only knows that an ACK packet
>cross the wire, not an SYN/ACK handshake.....mmmm, HELP :)
>
>My firewalls have the same policy (Simplified, of course):
>
>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.
Now this scenario is when the first host to send a packet after the
failover is the host that originated the telnet connection. Before
CASTOR has seen traffic go both ways, if a packet from the telnet
server host would hit your firewall, it would get dropped, since
it will have sport==23, not dport, and it will not be part of
an established connection.
This is not a biggie though. TCP can cope with this.
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.
Regards,
Filip
Title: RE: Possible BUG in NetFilter conecction state module (testing HA enviroment)
