ip_conntrack_pptp and inbound PPTP/GRE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux