Re: PPTP connttrack problem - 'unexpecting' performed too early?

[Philip Craig <philipc@snapgear.com>]

Colin Paton wrote:
> Can anyone advise? I'm not 100% sure of the nature of the 'expect' stuff, 
> which is perhaps where my misunderstanding is coming from. I'm wondering if 
> the other end should be 'unexpected' only AFTER GRE reply has been seen, but 
> am not quite sure.

For most protocols, the first packet in the connection will be in a
predetermined direction, so expectations are set up to only expect a
packet in that direction.  But the first packet in a GRE connection
can be sent by either end, so two expectations must be created.

However, once an expectation is matched, a conntrack entry is created
that will match packets in either direction.  So once the first GRE
expectation is matched, the expectation for the other direction can
be deleted immediately.  There is no need to wait for the reply.

An additional complication with GRE is that it uses a different ID
in either direction, so in order to match up the packets in either
direction, a 'keymap' is used.  The pptp helper creates 2 keymaps
for each expectation, for a total of 4 keymaps.  When an expectation
is matched, its 2 keymaps are used for the conntrack entry.  But
the other 2 keymaps are deleted by ip_ct_gre_keymap_destroy when
the other expectation is deleted.

What your change is accomplishing is to keep one of the keymaps for
the other expectation (for ever).  This shouldn't be needed, so if
it fixes things, it is probably because the keymap for the matched
expectation is wrong.

> I enclose a debug log.

Your log doesn't have any debug info from ip_nat_pptp.c or
ip_nat_proto_gre.c.  Have you insmod'ed them?  If you haven't then
that would explain why the keymap is wrong.  If you have, then please
enable debug for them also, and resend the log.

-- 
Philip Craig - SnapGear, A CyberGuard Company - http://www.SnapGear.com