| Message ID | 20130711004827.GA5500@localhost |
|---|---|
| State | Accepted |
| Headers | show |
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. The firewalls are now in production, so I don't have the same freedom I did previously. I'll check the patch out sometime after hours. Normally, this weekend would be a good time, but I'm going to be away this weekend. So it might be a few days until I get a chance. Thanks again for all your (and Florian's) great help! -Bill -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 12, 2013 at 03:01:14AM -0400, Bill Fink wrote: > 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! Thanks for testing and reporting back, I have pushed the patch to master. > 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. That's strange. Please, tell me if this happening in the primary and/or the backup. If you are using the cache mode, also dump the caches via -i and -e to see the content. > 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). Expectations depends on the master conntrack, if the master is released, the expectations will be released too. You may be noticing that effect. You can use `conntrack -E` and `conntrack -E exp` to verify this. Regards. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 15 Jul 2013, Pablo Neira Ayuso wrote: > On Fri, Jul 12, 2013 at 03:01:14AM -0400, Bill Fink wrote: > > 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! > > Thanks for testing and reporting back, I have pushed the patch to > master. > > > 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. > > That's strange. Please, tell me if this happening in the primary > and/or the backup. If you are using the cache mode, also dump the > caches via -i and -e to see the content. I'm not using the external cache. The duplicate BGP conntrackd entries seem to have multiplied (this is on the primary with the "conntrackd -i" command): tcp 6 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=61888 dport=179 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=179 dport=61888 [ASSURED] mark=0 [active since 18464s] tcp 6 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=61888 dport=179 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=179 dport=61888 [ASSURED] mark=0 [active since 245497s] tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271387s] tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271447s] tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271508s] tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271568s] tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271628s] tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271689s] tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271749s] tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] [active since 271803s] > > 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). > > Expectations depends on the master conntrack, if the master is > released, the expectations will be released too. You may be noticing > that effect. I wasn't expecting that since I was leaving the ftp control connection open. > You can use `conntrack -E` and `conntrack -E exp` to verify this. I couldn't get filtering to work with expect: [root@sen-fw1 ~]# conntrack -E expect -d aaa.aaa.aaa.ccc conntrack v1.4.0 (conntrack-tools): Illegal option `--dst' with this command Try `conntrack -h' or 'conntrack --help' for more information. [root@sen-fw1 ~]# conntrack -E expect --tuple-dst aaa.aaa.aaa.ccc conntrack v1.4.0 (conntrack-tools): Illegal option `--tuple-dst' with this command Try `conntrack -h' or 'conntrack --help' for more information. But with the help of grep: x100ssd2% nc aaa.aaa.aaa.ccc 21 220 FTP Server ready. gives: [NEW] tcp 6 120 SYN_SENT src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 [UNREPLIED] src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 helper=ftp [UPDATE] tcp 6 60 SYN_RECV src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 helper=ftp [UPDATE] tcp 6 432000 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 [ASSURED] helper=ftp Then doing: USER anonymous 331 Anonymous login ok, send your complete email address as your password PASS bill@ 230- ... 230 Anonymous login ok, restrictions apply. PASV 227 Entering Passive Mode (aaa,aaa,aaa,ccc,175,61). yields: [NEW] 300 proto=6 src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=0 dport=44861 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=aaa.aaa.aaa.bbb master-dst=aaa.aaa.aaa.ccc sport=49840 dport=21 class=0 helper=ftp Not doing anything but waiting, a little while later: [DESTROY] tcp 6 src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 [ASSURED] [UPDATE] tcp 6 433405 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 [ASSURED] mark=0 helper=ftp together with: [DESTROY] 273 proto=6 src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=0 dport=44861 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=aaa.aaa.aaa.bbb master-dst=aaa.aaa.aaa.ccc sport=49840 dport=21 class=0 helper=ftp So that's why the expect goes away. Remember this didn't happen with IPv6 (it didn't go away until the 300 seconds expired). Is the DESTROY/UPDATE on the master ftp connection normal when the ftp control connection hasn't been closed? At least for ftp it's not a big problem in practice since the expectation seems to be used almost immediately after creation for normal ftp transfers. -Thanks -Bill -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bill, On Tue, Jul 16, 2013 at 01:55:03AM -0400, Bill Fink wrote: > On Mon, 15 Jul 2013, Pablo Neira Ayuso wrote: > > > On Fri, Jul 12, 2013 at 03:01:14AM -0400, Bill Fink wrote: > > > 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! > > > > Thanks for testing and reporting back, I have pushed the patch to > > master. > > > > > 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. > > > > That's strange. Please, tell me if this happening in the primary > > and/or the backup. If you are using the cache mode, also dump the > > caches via -i and -e to see the content. > > I'm not using the external cache. The duplicate BGP conntrackd > entries seem to have multiplied (this is on the primary with the > "conntrackd -i" command): > > tcp 6 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=61888 dport=179 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=179 dport=61888 [ASSURED] mark=0 [active since 18464s] > tcp 6 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=61888 dport=179 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=179 dport=61888 [ASSURED] mark=0 [active since 245497s] > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271387s] > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271447s] > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271508s] > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271568s] > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271628s] > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271689s] > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271749s] > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] [active since 271803s] Interesting. Can you apply the following patch? It should help to debug the issue. Basically, it displays the conntrack unique ID. They should have different IDs. > > > 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). > > > > Expectations depends on the master conntrack, if the master is > > released, the expectations will be released too. You may be noticing > > that effect. > > I wasn't expecting that since I was leaving the ftp control > connection open. > > > You can use `conntrack -E` and `conntrack -E exp` to verify this. > > I couldn't get filtering to work with expect: > > [root@sen-fw1 ~]# conntrack -E expect -d aaa.aaa.aaa.ccc > conntrack v1.4.0 (conntrack-tools): Illegal option `--dst' with this command > Try `conntrack -h' or 'conntrack --help' for more information. > > [root@sen-fw1 ~]# conntrack -E expect --tuple-dst aaa.aaa.aaa.ccc > conntrack v1.4.0 (conntrack-tools): Illegal option `--tuple-dst' with this command > Try `conntrack -h' or 'conntrack --help' for more information. > > But with the help of grep: > > x100ssd2% nc aaa.aaa.aaa.ccc 21 > 220 FTP Server ready. > > gives: > > [NEW] tcp 6 120 SYN_SENT src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 [UNREPLIED] src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 helper=ftp > [UPDATE] tcp 6 60 SYN_RECV src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 helper=ftp > [UPDATE] tcp 6 432000 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 [ASSURED] helper=ftp > > Then doing: > > USER anonymous > 331 Anonymous login ok, send your complete email address as your password > PASS bill@ > 230- > ... > 230 Anonymous login ok, restrictions apply. > PASV > 227 Entering Passive Mode (aaa,aaa,aaa,ccc,175,61). > > yields: > > [NEW] 300 proto=6 src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=0 dport=44861 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=aaa.aaa.aaa.bbb master-dst=aaa.aaa.aaa.ccc sport=49840 dport=21 class=0 helper=ftp > > Not doing anything but waiting, a little while later: Can you catch the last event before this one below? I'd like to know in what TCP state the flow was before the destroy event. > [DESTROY] tcp 6 src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 [ASSURED] > [UPDATE] tcp 6 433405 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 [ASSURED] mark=0 helper=ftp > > together with: > > [DESTROY] 273 proto=6 src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=0 dport=44861 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=aaa.aaa.aaa.bbb master-dst=aaa.aaa.aaa.ccc sport=49840 dport=21 class=0 helper=ftp > > So that's why the expect goes away. Remember this didn't happen > with IPv6 (it didn't go away until the 300 seconds expired). > > Is the DESTROY/UPDATE on the master ftp connection normal when > the ftp control connection hasn't been closed? That's not normal. I guess you have tcp pick enabled: cat /proc/sys/net/netfilter/nf_conntrack_tcp_loose shows 1. That allows conntrack to create new entries from the first packet seen (no mater if it's not a tcp syn packet). It seems that conntrack is creating a new TCP established flow for some late packet retransmission. Florian Westphal posted a patch to reduce the default timeout for pickup flows: 6547a22 netfilter: nf_conntrack: avoid large timeout for mid-stream pickup That should mitigate this effect. Still, you'll have to trace traffic from your network to reach the root cause of this. You can gather pcap traces of the BGP's TCP connection, as it seems reproducible with it, to simplify things. I think both things are different manifestations of the same issue. Thanks for the very detailed report. Let me know how it goes with your tracing. Regards. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 16 Jul 2013, Pablo Neira Ayuso wrote: > On Tue, Jul 16, 2013 at 01:55:03AM -0400, Bill Fink wrote: > > On Mon, 15 Jul 2013, Pablo Neira Ayuso wrote: > > > > > On Fri, Jul 12, 2013 at 03:01:14AM -0400, Bill Fink wrote: > > > > > > > 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. > > > > > > That's strange. Please, tell me if this happening in the primary > > > and/or the backup. If you are using the cache mode, also dump the > > > caches via -i and -e to see the content. > > > > I'm not using the external cache. The duplicate BGP conntrackd > > entries seem to have multiplied (this is on the primary with the > > "conntrackd -i" command): > > > > tcp 6 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=61888 dport=179 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=179 dport=61888 [ASSURED] mark=0 [active since 18464s] > > tcp 6 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=61888 dport=179 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=179 dport=61888 [ASSURED] mark=0 [active since 245497s] > > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271387s] > > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271447s] > > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271508s] > > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271568s] > > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271628s] > > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271689s] > > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] mark=0 [active since 271749s] > > tcp 6 ESTABLISHED src=2001:xxxx:xxxx:xxxx::yyyy dst=2001:xxxx:xxxx:xxxx::zzzz sport=49166 dport=179 src=2001:xxxx:xxxx:xxxx::zzzz dst=2001:xxxx:xxxx:xxxx::yyyy sport=179 dport=49166 [ASSURED] [active since 271803s] > > Interesting. Can you apply the following patch? It should help to > debug the issue. Basically, it displays the conntrack unique ID. They > should have different IDs. I tried the debugging patch, but the "conntrackd -i" output wasn't any different (no conntrack unique IDs). > > > > 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). > > > > > > Expectations depends on the master conntrack, if the master is > > > released, the expectations will be released too. You may be noticing > > > that effect. > > > > I wasn't expecting that since I was leaving the ftp control > > connection open. > > > > > You can use `conntrack -E` and `conntrack -E exp` to verify this. > > > > I couldn't get filtering to work with expect: > > > > [root@sen-fw1 ~]# conntrack -E expect -d aaa.aaa.aaa.ccc > > conntrack v1.4.0 (conntrack-tools): Illegal option `--dst' with this command > > Try `conntrack -h' or 'conntrack --help' for more information. > > > > [root@sen-fw1 ~]# conntrack -E expect --tuple-dst aaa.aaa.aaa.ccc > > conntrack v1.4.0 (conntrack-tools): Illegal option `--tuple-dst' with this command > > Try `conntrack -h' or 'conntrack --help' for more information. > > > > But with the help of grep: > > > > x100ssd2% nc aaa.aaa.aaa.ccc 21 > > 220 FTP Server ready. > > > > gives: > > > > [NEW] tcp 6 120 SYN_SENT src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 [UNREPLIED] src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 helper=ftp > > [UPDATE] tcp 6 60 SYN_RECV src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 helper=ftp > > [UPDATE] tcp 6 432000 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 [ASSURED] helper=ftp > > > > Then doing: > > > > USER anonymous > > 331 Anonymous login ok, send your complete email address as your password > > PASS bill@ > > 230- > > ... > > 230 Anonymous login ok, restrictions apply. > > PASV > > 227 Entering Passive Mode (aaa,aaa,aaa,ccc,175,61). > > > > yields: > > > > [NEW] 300 proto=6 src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=0 dport=44861 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=aaa.aaa.aaa.bbb master-dst=aaa.aaa.aaa.ccc sport=49840 dport=21 class=0 helper=ftp > > > > Not doing anything but waiting, a little while later: > > Can you catch the last event before this one below? I'd like to know > in what TCP state the flow was before the destroy event. All the events were listed above in order, so the last event on the master ftp connection before the following DESTROY/UPDATE was the UPDATE to the ESTABLISHED state. > > [DESTROY] tcp 6 src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 [ASSURED] > > [UPDATE] tcp 6 433405 ESTABLISHED src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=49840 dport=21 src=aaa.aaa.aaa.ccc dst=aaa.aaa.aaa.bbb sport=21 dport=49840 [ASSURED] mark=0 helper=ftp > > > > together with: > > > > [DESTROY] 273 proto=6 src=aaa.aaa.aaa.bbb dst=aaa.aaa.aaa.ccc sport=0 dport=44861 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=aaa.aaa.aaa.bbb master-dst=aaa.aaa.aaa.ccc sport=49840 dport=21 class=0 helper=ftp > > > > So that's why the expect goes away. Remember this didn't happen > > with IPv6 (it didn't go away until the 300 seconds expired). > > > > Is the DESTROY/UPDATE on the master ftp connection normal when > > the ftp control connection hasn't been closed? > > That's not normal. I guess you have tcp pick enabled: > > cat /proc/sys/net/netfilter/nf_conntrack_tcp_loose Yes, I have nf_conntrack_tcp_loose set. > shows 1. That allows conntrack to create new entries from the first > packet seen (no mater if it's not a tcp syn packet). It seems that > conntrack is creating a new TCP established flow for some late packet > retransmission. Florian Westphal posted a patch to reduce the default > timeout for pickup flows: > > 6547a22 netfilter: nf_conntrack: avoid large timeout for mid-stream pickup > > That should mitigate this effect. Still, you'll have to trace traffic > from your network to reach the root cause of this. You can gather pcap > traces of the BGP's TCP connection, as it seems reproducible with it, > to simplify things. I think both things are different manifestations > of the same issue. For whatever reason, I can't reproduce this anymore. The expectations now expire after the expected 5 minutes. I'm not sure what's different now. If it happens again, I'll try and get more debugging info. > Thanks for the very detailed report. Let me know how it goes with your > tracing. -Thanks -Bill -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From 586382d9a8389ee553db019fd9be14a8a7c0b8ec Mon Sep 17 00:00:00 2001 From: Pablo Neira Ayuso <pablo@netfilter.org> Date: Thu, 11 Jul 2013 00:43:20 +0200 Subject: [PATCH] conntrackd: simplify expectation filtering This patch simplifies the expectation filtering by looking up for the master conntrack. If it does not exists, then we assume that we don't want this expectation either. This simplification also fixes the current broken expectation filtering, since the master conntrack from expectations has neither reply tuple nor state, however, the filtering code assumes the opposite. This partially reverts (479a37a conntrackd: fix crash with IPv6 expectation in the filtering code) since it was incorrectly setting the reply tuple of the master conntrack. Thanks to Bill Fink for providing feedback to resolve this issue. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> --- include/filter.h | 1 + include/internal.h | 1 + src/cache-ct.c | 11 +++++++++-- src/ctnl.c | 37 +++++++++---------------------------- src/filter.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ src/internal_bypass.c | 6 ++++++ src/internal_cache.c | 11 +++++++++++ 7 files changed, 82 insertions(+), 30 deletions(-) diff --git a/include/filter.h b/include/filter.h index 3c7c8cc..d0acd96 100644 --- a/include/filter.h +++ b/include/filter.h @@ -51,6 +51,7 @@ void ct_filter_set_logic(struct ct_filter *f, enum ct_filter_type type, enum ct_filter_logic logic); int ct_filter_conntrack(const struct nf_conntrack *ct, int userspace); +int ct_filter_master(const struct nf_conntrack *master); struct exp_filter; struct nf_expect; diff --git a/include/internal.h b/include/internal.h index 2ba9714..1a796a7 100644 --- a/include/internal.h +++ b/include/internal.h @@ -40,6 +40,7 @@ struct internal_handler { void (*new)(struct nf_expect *exp, int origin_type); void (*upd)(struct nf_expect *exp, int origin_type); int (*del)(struct nf_expect *exp, int origin_type); + int (*find)(const struct nf_conntrack *master); void (*dump)(int fd, int type); void (*populate)(struct nf_expect *exp); diff --git a/src/cache-ct.c b/src/cache-ct.c index a538215..f86d143 100644 --- a/src/cache-ct.c +++ b/src/cache-ct.c @@ -88,14 +88,21 @@ cache_ct_hash(const void *data, const struct hashtable *table) return ret; } +/* master conntrack of expectations have no ID */ +static inline int +cache_ct_cmp_id(const struct nf_conntrack *ct1, const struct nf_conntrack *ct2) +{ + return nfct_attr_is_set(ct2, ATTR_ID) ? + nfct_get_attr_u32(ct1, ATTR_ID) == nfct_get_attr_u32(ct2, ATTR_ID) : 1; +} + static int cache_ct_cmp(const void *data1, const void *data2) { const struct cache_object *obj = data1; const struct nf_conntrack *ct = data2; return nfct_cmp(obj->ptr, ct, NFCT_CMP_ORIG) && - nfct_get_attr_u32(obj->ptr, ATTR_ID) == - nfct_get_attr_u32(ct, ATTR_ID); + cache_ct_cmp_id(obj->ptr, ct); } static void *cache_ct_alloc(void) diff --git a/src/ctnl.c b/src/ctnl.c index 9e1cfa1..10b5f4c 100644 --- a/src/ctnl.c +++ b/src/ctnl.c @@ -211,35 +211,14 @@ out: return NFCT_CB_CONTINUE; } -static const struct nf_conntrack *exp_get_master_ct(struct nf_expect *exp) -{ - struct nf_conntrack *master = - (struct nf_conntrack *)nfexp_get_attr(exp, ATTR_EXP_MASTER); - - /* The function ct_filter_conntrack needs the source address of the - * reply tuple, emulate it. - */ - switch (nfct_get_attr_u8(master, ATTR_L3PROTO)) { - case AF_INET: - nfct_set_attr_u32(master, ATTR_REPL_IPV4_SRC, - nfct_get_attr_u32(master, ATTR_IPV4_DST)); - break; - case AF_INET6: - nfct_set_attr(master, ATTR_REPL_IPV6_SRC, - nfct_get_attr(master, ATTR_IPV6_DST)); - break; - } - - return master; -} - static int exp_event_handler(const struct nlmsghdr *nlh, enum nf_conntrack_msg_type type, struct nf_expect *exp, void *data) { int origin_type; - const struct nf_conntrack *master = exp_get_master_ct(exp); + const struct nf_conntrack *master = + nfexp_get_attr(exp, ATTR_EXP_MASTER); STATE(stats).nl_events_received++; @@ -247,7 +226,7 @@ static int exp_event_handler(const struct nlmsghdr *nlh, STATE(stats).nl_events_filtered++; goto out; } - if (ct_filter_conntrack(master, 1)) + if (ct_filter_master(master)) return NFCT_CB_CONTINUE; origin_type = origin_find(nlh); @@ -296,12 +275,13 @@ static int dump_handler(enum nf_conntrack_msg_type type, static int exp_dump_handler(enum nf_conntrack_msg_type type, struct nf_expect *exp, void *data) { - const struct nf_conntrack *master = exp_get_master_ct(exp); + const struct nf_conntrack *master = + nfexp_get_attr(exp, ATTR_EXP_MASTER); if (!exp_filter_find(STATE(exp_filter), exp)) return NFCT_CB_CONTINUE; - if (ct_filter_conntrack(master, 1)) + if (ct_filter_master(master)) return NFCT_CB_CONTINUE; switch(type) { @@ -329,12 +309,13 @@ static int get_handler(enum nf_conntrack_msg_type type, static int exp_get_handler(enum nf_conntrack_msg_type type, struct nf_expect *exp, void *data) { - const struct nf_conntrack *master = exp_get_master_ct(exp); + const struct nf_conntrack *master = + nfexp_get_attr(exp, ATTR_EXP_MASTER); if (!exp_filter_find(STATE(exp_filter), exp)) return NFCT_CB_CONTINUE; - if (ct_filter_conntrack(master, 1)) + if (ct_filter_master(master)) return NFCT_CB_CONTINUE; STATE(get_retval) = 1; diff --git a/src/filter.c b/src/filter.c index e21cfde..8fac71b 100644 --- a/src/filter.c +++ b/src/filter.c @@ -407,6 +407,51 @@ int ct_filter_conntrack(const struct nf_conntrack *ct, int userspace) return 0; } +static inline int +ct_filter_master_sanity_check(const struct nf_conntrack *master) +{ + if (master == NULL) { + dlog(LOG_ERR, "no master tuple in expectation"); + return 0; + } + + if (!nfct_attr_is_set(master, ATTR_L3PROTO)) { + dlog(LOG_ERR, "missing layer 3 protocol"); + return 0; + } + + switch (nfct_get_attr_u8(master, ATTR_L3PROTO)) { + case AF_INET: + if (!nfct_attr_is_set(master, ATTR_IPV4_SRC) || + !nfct_attr_is_set(master, ATTR_IPV4_DST)) { + dlog(LOG_ERR, "missing IPv4 address. " + "You forgot to load nf_conntrack_ipv4?"); + return 0; + } + break; + case AF_INET6: + if (!nfct_attr_is_set(master, ATTR_IPV6_SRC) || + !nfct_attr_is_set(master, ATTR_IPV6_DST)) { + dlog(LOG_ERR, "missing IPv6 address. " + "You forgot to load nf_conntrack_ipv6?"); + return 0; + } + break; + } + return 1; +} + +int ct_filter_master(const struct nf_conntrack *master) +{ + if (!ct_filter_master_sanity_check(master)) + return 1; + + /* Check if we've got a master conntrack for this expectation in our + * caches. If there is not, we don't want this expectation either. + */ + return STATE(mode)->internal->exp.find(master) ? 0 : 1; +} + struct exp_filter { struct list_head list; }; diff --git a/src/internal_bypass.c b/src/internal_bypass.c index 1194339..ce2ae46 100644 --- a/src/internal_bypass.c +++ b/src/internal_bypass.c @@ -283,6 +283,11 @@ static int internal_bypass_exp_event_del(struct nf_expect *exp, int origin) return 1; } +static int internal_bypass_exp_master_find(const struct nf_conntrack *master) +{ + return nl_get_conntrack(STATE(get), master) == 0; +} + struct internal_handler internal_bypass = { .init = internal_bypass_init, .close = internal_bypass_close, @@ -309,5 +314,6 @@ struct internal_handler internal_bypass = { .new = internal_bypass_exp_event_new, .upd = internal_bypass_exp_event_upd, .del = internal_bypass_exp_event_del, + .find = internal_bypass_exp_master_find, }, }; diff --git a/src/internal_cache.c b/src/internal_cache.c index ba2d74b..bad31f3 100644 --- a/src/internal_cache.c +++ b/src/internal_cache.c @@ -364,6 +364,16 @@ static int internal_cache_exp_event_del(struct nf_expect *exp, int origin) return 1; } +static int internal_cache_exp_master_find(const struct nf_conntrack *master) +{ + struct cache_object *obj; + int id; + + obj = cache_find(STATE(mode)->internal->ct.data, + (struct nf_conntrack *)master, &id); + return obj ? 1 : 0; +} + struct internal_handler internal_cache = { .flags = INTERNAL_F_POPULATE | INTERNAL_F_RESYNC, .init = internal_cache_init, @@ -391,5 +401,6 @@ struct internal_handler internal_cache = { .new = internal_cache_exp_event_new, .upd = internal_cache_exp_event_upd, .del = internal_cache_exp_event_del, + .find = internal_cache_exp_master_find, }, }; -- 1.7.10.4