[Pacemaker] Statefull firewall cluster Active/Pasive with conntrackd issues

[Dominik Klein]

netfilter is smarter than you think it is. It can distinguish between
packet flows forming an "allowed flow" and actually invalid packets.
That's default behaviour.

This only works if there's no helper module needed. So with the likes of
NAT or FTP connections, this will not work without conntrackd.

Unfortunately, I don't have a reference link at hand on that, but I fell
for the same thing before and this is the short version of the answer I
got in #netfilter.

hth
Dominik

On 05/11/2011 02:03 AM, CeR wrote:
> Hi there!
> 
> I'm working on a statefull firewall HA cluster (active/pasive) with
> conntrackd as a ms resource. I'm sure some of you guys remember me from
> the IRC channel :P
> 
> Some questions:
> 
> I'm doing some failback/failover test with the connection tracking systems. 
> 
> CASE A: One of that test do the next:
> 
> 1) Initialisation of a connection with a big file transfer with SCP
> across the cluster.
> 2) "halt" the primary node. All resources moves to another node. That
> works really fine.
> 3) The file transfer still working. Transparent to the end user.
> 
> CASE B: I want to be sure that the failback/failover is thanks to
> conntrackd flow's-state-replication, so
> 
> 1) Stop the conntrackd resource. All go fine.
> 2) Start the file transfer across the cluster.
> 3) Failover the node that has the IPVs. All resources moves to another
> node. 
> 4) The file transfer still working. Transparent to the end user.
> ¿¿¿¿¿¿?????? WTF
> 
> 
> In the CASE B, without the conntrackd MS resource running, I supposed
> that the new node being owner of IPVs will not have any knowlege about
> the state of the flow (you know, NEW, ESTABLISHED,etc..). And this mean
> the firewall has to block the transference.
> But still transfering and the iptables rule being aplied.
> 
> Chain FORWARD (policy DROP 42 packets, 3336 bytes)
>  pkts bytes target     prot opt in     out     source              
> destination         
>  741K 1075M ACCEPT     tcp  --  eth0   eth2    10.0.0.128          
> 192.168.100.100     tcp spts:1024:65535 dpt:22 state NEW,ESTABLISHED 
> 37498 2400K ACCEPT     tcp  --  eth2   eth0    192.168.100.100    
>  10.0.0.128          tcp spt:22 dpts:1024:65535 state ESTABLISHED 
> 
> 
> Any idea?
> 
> Regards!