Re: conntrackd segfault on EPSV IPv6 ftp command when using ftp ExpectationSync

[Bill Fink <billfink@mindspring.com>]

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