* ip_conntrack_pptp and inbound PPTP/GRE
@ 2004-08-04 21:50 Charlie Brady
2004-08-05 3:58 ` Philip Craig
2004-08-05 13:08 ` ip_conntrack_pptp and inbound PPTP/GRE Les Mikesell
0 siblings, 2 replies; 7+ messages in thread
From: Charlie Brady @ 2004-08-04 21:50 UTC (permalink / raw)
To: netfilter
I've struck a problem with inbound PPTP with CVS pptp conntrack and a
patched 2.4.18 kernel.
...
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
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
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.
Thanks
---
Charlie
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ip_conntrack_pptp and inbound PPTP/GRE
2004-08-04 21:50 ip_conntrack_pptp and inbound PPTP/GRE Charlie Brady
@ 2004-08-05 3:58 ` Philip Craig
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-05 13:08 ` ip_conntrack_pptp and inbound PPTP/GRE Les Mikesell
1 sibling, 2 replies; 7+ messages in thread
From: Philip Craig @ 2004-08-05 3:58 UTC (permalink / raw)
To: Charlie Brady; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ip_conntrack_pptp and inbound PPTP/GRE
2004-08-05 3:58 ` Philip Craig
@ 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
1 sibling, 0 replies; 7+ messages in thread
From: Charlie Brady @ 2004-08-05 12:35 UTC (permalink / raw)
To: Philip Craig; +Cc: netfilter
On Thu, 5 Aug 2004, Philip Craig wrote:
> 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?
poptop 1.1.3, and XP (I think).
> Is either on the iptables machine?
poptop is on the machine in question.
> Is there any reason you are still using 2.4.18?
Vendor supplied kernel.
> It is quite likely that this kernel is lacking patches that are required
> for PPTP connection tracking.
The netfilter code is newer than the orig 2.4.18 kernel. It's possible
that something else is needed, but I'm not prepared to put it down to that
without further investigation.
> > ...
> > 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.
OK. So this was set up by outgoing GRE.
> > 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.
OK.
> > 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.
Possible, but not trivial.
---
Charlie
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ip_conntrack_pptp and inbound PPTP/GRE
2004-08-04 21:50 ip_conntrack_pptp and inbound PPTP/GRE Charlie Brady
2004-08-05 3:58 ` Philip Craig
@ 2004-08-05 13:08 ` Les Mikesell
2004-08-05 13:36 ` Charlie Brady
1 sibling, 1 reply; 7+ messages in thread
From: Les Mikesell @ 2004-08-05 13:08 UTC (permalink / raw)
To: Charlie Brady; +Cc: netfilter
On Wed, 2004-08-04 at 16:50, Charlie Brady wrote:
> I've struck a problem with inbound PPTP with CVS pptp conntrack and a
> patched 2.4.18 kernel.
[...]
> 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.
If this is the kernel used in SMEserver, I think there is a bug in
GRE handling. I've added CIPE vpns and in some cases try to route
a GRE tunnel between two Cisco routers on private LANs through the
CIPE vpn. This worked fine with SME versions before 5.6 but now
GRE packets (only) coming from the inside ethernet and routed through
the CIPE interface are SNAT'ed with the outside ethernet IP which
of course keeps them from working. I always see a conntrack entry
of:
unknown 47 597 src=192.168.254.3 dst=192.168.254.1 [UNREPLIED]
src=192.168.254.1 dst=166.90.87.10 use=1
even though the dst address mentioned was never used and there
is no reason for any association with it (the packets are
static-routed through the CIPE interface address) and I can't
find anything in iptables handling related to this.
The odd thing is that the first remote office upgraded to
5.6 does work but others have the problem above. I just
haven't been able to pin down the difference or anything
between Upgrade5 or Upgrade6 that might cause it.
---
Les Mikesell
les@futuresource.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ip_conntrack_pptp and inbound PPTP/GRE
2004-08-05 13:08 ` ip_conntrack_pptp and inbound PPTP/GRE Les Mikesell
@ 2004-08-05 13:36 ` Charlie Brady
0 siblings, 0 replies; 7+ messages in thread
From: Charlie Brady @ 2004-08-05 13:36 UTC (permalink / raw)
To: Les Mikesell; +Cc: netfilter
On Thu, 5 Aug 2004, Les Mikesell wrote:
> If this is the kernel used in SMEserver,
It's not.
> I think there is a bug in GRE handling.
Quite possible. Report your problem via the bugtracker at contribs.org.
---
Charlie
^ permalink raw reply [flat|nested] 7+ messages in thread
* pptp conntrack requirements (was Re: ip_conntrack_pptp and inbound PPTP/GRE)
2004-08-05 3:58 ` Philip Craig
2004-08-05 12:35 ` Charlie Brady
@ 2004-08-05 14:41 ` Charlie Brady
2004-08-06 0:50 ` Philip Craig
1 sibling, 1 reply; 7+ messages in thread
From: Charlie Brady @ 2004-08-05 14:41 UTC (permalink / raw)
To: Philip Craig; +Cc: netfilter
On Thu, 5 Aug 2004, Philip Craig wrote:
> 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.
Do you happen to know what the prerequisites are? I'll do what digging I
can into what I have, but it could short cut the process if you know
specifics.
Meanwhile I'll grab a 2.4.18 kernel, and apply patch-o-matic, and see how
that matches what I have.
Thanks
---
Charlie
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: pptp conntrack requirements (was Re: ip_conntrack_pptp and inbound PPTP/GRE)
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
0 siblings, 0 replies; 7+ messages in thread
From: Philip Craig @ 2004-08-06 0:50 UTC (permalink / raw)
To: Charlie Brady; +Cc: netfilter
Charlie Brady wrote:
> Do you happen to know what the prerequisites are? I'll do what digging I
> can into what I have, but it could short cut the process if you know
> specifics.
>
> Meanwhile I'll grab a 2.4.18 kernel, and apply patch-o-matic, and see how
> that matches what I have.
The patches were spread out over various kernels up until around 2.4.23.
You should be able to obtain these from the old version of patch-o-matic
(ie not patch-o-matic-ng). Just apply everything in the submitted
directory.
--
Philip Craig - SnapGear, A CyberGuard Company - http://www.SnapGear.com
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-08-06 0:50 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-04 21:50 ip_conntrack_pptp and inbound PPTP/GRE Charlie Brady
2004-08-05 3:58 ` Philip Craig
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
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.