Hi there, It's seems that I wasn't using the needed modules. Typical human error. ----------------- root@fw2:~# cat /proc/sys/net/netfilter/nf_conntrack_tcp_loose cat: /proc/sys/net/netfilter/nf_conntrack_tcp_loose: No existe el fichero o el directorio root@fw2:~# modprobe nf_conntrack_ipv4 root@fw2:~# cat /proc/sys/net/netfilter/nf_conntrack_tcp_loose 1 root@fw2:~# ---------------- Avoiding mistakes by editing /etc/modules: ---------------- root@fw2:~# cat /etc/modules | grep nf nf_conntrack nf_conntrack_ipv4 nf_conntrack_netlink nfnetlink nf_defrag_ipv4 ----------------- My kernel (debian squeeze): ---------------- root@fw2:~# uname -r 2.6.32-5-amd64 ----------------- And now I'm applying the IRC suggestion: ----------------- root@fw2:~# cat /etc/sysctl.conf | grep nf_conntrack_tcp_loose net.netfilter.nf_conntrack_tcp_loose = 0 ------------------ Thanks you. 2011/5/18 Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> > > Hi, > > On 12/05/11 19:15, CeR wrote: > > Hi there. > > I'm working on a active/pasive HA cluster with corosync/pacemaker. > > For testing purposes, i did these test: > > > > 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 (pacemaker) moves to another > > node. That's ok. > > 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. Conntrack is not working any more. > > 2) Start the file transfer across the cluster. > > 3) Failover the node that has the IPVs. All resources moves to another > > node (pacemaker). > > 4) The file transfer still working. Transparent to the end user. > > ççç?????? WTF > > That's completely possible in several cases: > > * your rule-set is not stateful. > * your stateful rule-set is malformed. > * you forget to enable strict tracking. > > Your testcases A and B are a good idea indeed, because you can really > test if you configured conntrackd correctly. > > > In the CASE B, without the conntrackd 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 as it where > > an ESTABLISHED connection: > > > > 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? Is this the standard behaviour of netfilter tools? > > > > In the IRC channel, i got this: > > [18:32] <fw> sysctl net.netfilter.nf_conntrack_tcp_loose > > [18:33] <fw> its probably one. Âit must be 0 to disable pickup of > > established connections. > > Yes, this is indeed a good clue. > > > But in fact, i haven' t "net.netfilter.nf_conntrack_tcp_loose" nor > > "net.ipv4.netfilter.ip_conntrack_tcp_loose" > > What kernel version are you using? If it's too old you may find > net.ipv4.netfilter.ip_conntrack_loose instead. > > Here it is: > > # ls /proc/sys/net/netfilter/nf_conntrack_tcp_loose > /proc/sys/net/netfilter/nf_conntrack_tcp_loose > # uname -a > Linux 2.6.39-rc2-09922-g0f08190 #58 SMP PREEMPT Sun May 15 17:35:57 CEST > 2011 i686 GNU/Linux > # lsmod | grep nf_conntrack > nf_conntrack_netlink  Â13579 Â0 > nfnetlink        2086 Â7 nfnetlink_log,nf_conntrack_netlink > nf_conntrack_ipv4    8841 Â0 > nf_conntrack      45970 Â2 nf_conntrack_netlink,nf_conntrack_ipv4 > nf_defrag_ipv4      867 Â1 nf_conntrack_ipv4 > > Please, take the time to read the documentation: > > http://conntrack-tools.netfilter.org/testcase.html > http://conntrack-tools.netfilter.org/manual.html > > Thanks. -- /* Arturo Borrero Gonzalez || cer.inet@xxxxxxxxxxxxx */ /* Use debian gnu/linux! Best OS ever! */ -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
