All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Craig <philipc@snapgear.com>
To: Charlie Brady <charlieb-netfilter@budge.apana.org.au>
Cc: netfilter@lists.netfilter.org
Subject: Re: ip_conntrack_pptp and inbound PPTP/GRE
Date: Thu, 05 Aug 2004 13:58:02 +1000	[thread overview]
Message-ID: <4111B04A.4090801@snapgear.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0408041734340.21854-100000@e-smith.charlieb.ott.istop.com>

Charlie Brady wrote:
> I've struck a problem with inbound PPTP with CVS pptp conntrack and a 
> patched 2.4.18 kernel.

Which pptp server and client are you using?  Is either on the
iptables machine?

Is there any reason you are still using 2.4.18?  It is quite likely
that this kernel is lacking patches that are required for PPTP
connection tracking.

> ...
> gre      47 170 timeout=30, stream_timeout=180 src=64.230.9.110 \
>  dst=64.230.132.224 version=1 protocol=0x880b srckey=0x0 dstkey=0x1f21\
>  src=64.230.132.224 dst=64.230.9.110 version=1 protocol=0x880b srckey=0x1f21 dstkey=0x0 \
>  [ASSURED] use=1

The low timeouts on this conntrack indicate it is using only
the gre connection tracking and not the pptp connection tracking.
That is, it is not related to the pptp control connection, and
shouldn't have been created if all was working.

> gre      47 566 timeout=600, stream_timeout=432000 src=64.230.132.224 \
>   dst=64.230.9.110 version=1 protocol=0x880b srckey=0x0 dstkey=0x0 \
>   [UNREPLIED] \
>   src=64.230.9.110 dst=64.230.132.224 version=1 protocol=0x880b srckey=0x0 dstkey=0x0 \
>   use=1

This conntrack is related to the pptp connection tracking, but
having both a srckey and dstkey of 0 is very unusual.  I expect that
the keys should be the same as the first conntrack.

> tcp      6 431968 ESTABLISHED \
>   src=64.230.132.224 dst=64.230.9.110 sport=7968 dport=1723 \
>   src=64.230.9.110 dst=64.230.132.224 sport=1723 dport=7968 \
>   [ASSURED] use=2
> ...
> 
> The problem is that after establishing the connection, I have two gre 
> conntrack entries. The first one above sees the tunnel traffic, and the 
> timeout value is continually reset. The second one always stays UNREPLIED 
> and times out after 10 minutes. After the timeout, new incoming GRE 
> packets no longer have state RELATED and are blocked.
> 
> Is this a bug, or am I doing something wrong? If nobody is sure, can 
> someone advise how I can proceed?  I'm in the process of enabling the 
> debugging code in the conntrack module.

Enabling debugging would certainly help figure out what is going
wrong, but it would be preferable to try a later kernel if possible.

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



  reply	other threads:[~2004-08-05  3:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-04 21:50 ip_conntrack_pptp and inbound PPTP/GRE Charlie Brady
2004-08-05  3:58 ` Philip Craig [this message]
2004-08-05 12:35   ` Charlie Brady
2004-08-05 14:41   ` pptp conntrack requirements (was Re: ip_conntrack_pptp and inbound PPTP/GRE) Charlie Brady
2004-08-06  0:50     ` Philip Craig
2004-08-05 13:08 ` ip_conntrack_pptp and inbound PPTP/GRE Les Mikesell
2004-08-05 13:36   ` Charlie Brady

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4111B04A.4090801@snapgear.com \
    --to=philipc@snapgear.com \
    --cc=charlieb-netfilter@budge.apana.org.au \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.