Pablo, On Thu, 11 Jul 2013, Pablo Neira Ayuso wrote: > On Thu, Jul 11, 2013 at 12:08:20AM +0200, Pablo Neira Ayuso wrote: > > On Wed, Jul 10, 2013 at 05:58:15AM -0400, Bill Fink wrote: > > > Almost there. With the above patch, I now successfully get > > > IPv6 expectations on the backup firewall. Unfortunately they're > > > not quite right. On the backup firewall, the expectation src-IP > > > is the same as the dst-IP (either IPv4 or IPv6). > > > > > > Primary firewall: > > > > > > [root@sen-fw1 linux-3.7.3-101.fc17.x86_64]# conntrack -L expect > > > 251 proto=6 src=192.168.218.199 dst=192.168.28.198 sport=0 dport=54705 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=192.168.218.199 master-dst=192.168.28.198 sport=56877 dport=21 class=0 helper=ftp > > > conntrack v1.4.0 (conntrack-tools): 1 expectations have been shown. > > > > > > Backup firewall: > > > > > > [root@sen-fw2 linux-3.7.3-101.fc17.x86_64]# conntrack -L expect > > > 245 proto=6 src=192.168.28.198 dst=192.168.28.198 sport=0 dport=54705 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=192.168.218.199 master-dst=192.168.28.198 sport=56877 dport=21 class=0 helper=ftp > > > conntrack v1.4.0 (conntrack-tools): 1 expectations have been shown. > > > > > > This was an unfortunate side affect of the patch to fix the > > > conntrackd segfault problem. If I use Florian's version > > > of the fix segfault patch rather than Pablo's then all is > > > good. > > > > Thanks for the information, however, we still need to get working back > > the filtering support. > > > > Could you give a try to the following patch, please? > > > > It applies on top of conntrack-tools master branch, thanks. > > There are still some downsides in the previous solution, please, give > a try to this patch instead. It appears to work pretty well and does fix the src-IP issue! I did notice a couple of other things but they're not necessarily related to these patches. I noticed that my long lived BGP tcp connection was getting some duplicate conntrackd ct entries (both IPv4 and IPv6). The duplicate ct entry occurred 60 seconds after the original, and once I saw a second duplicate ct IPv4 entry, again with about a 60 second separation. And on the expectation entries, they seem to have a lifetime of 300 seconds. The IPv6 expectation entries are deleted after the 300 seconds as expected, but the IPv4 expectation entries actually go away in a minute or less. I don't know if that is expected behavior or not. Note I was leaving the ftp control connection open the entire time. Also it may have just been my imagination, but it seemed if I queried it more often with "conntrack -L expect" it would stick around somewhat longer (but would go away within the minute). As I mentioned in my previous e-mail, I will be away for the weekend. -Thanks -Bill -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
