PPTP connection tracking and Poptop on same box

PPTP connection tracking and Poptop on same box

[Menno Smits]

Hi,

I'm experiencing some frustrating problems using PPTP connection
tracking/NAT with Poptop on the same box.

I'm using kernel 2.4.21 with the latest PPTP (and related) POM patches
from CVS. I'm using Poptop v1.1.4.

Without ip_nat_pptp and friends loaded connections to Poptop work
flawlessly.

When ip_nat_pptp etc is loaded connection tracking and NAT _through_
the box to external servers works great.

However, when the PPTP NAT+conntrack modules are loaded, connections
to Poptop running on the Linux box are highly unreliable.  Connections
to Poptop are difficult to establish and generally take several
attempts before they work.  Sometimes you get lucky and the connection
works first go. Other times it can take 10s of attempts. Once a
connection is established it seems to function and remain that way.

There seems to be two types of errors I get from Poptop and pppd when
a connection attempt fails. They seem to be fairly interchangable.

The first is the "Operation not permitted" error:

Sep  2 12:25:47 host pptpd[19967]: CTRL: Client 10.233.0.1 control 
connection started
Sep  2 12:25:47 host pptpd[19967]: CTRL: Starting call (launching pppd, 
opening GRE)
Sep  2 12:25:47 host pppd[19968]: pppd 2.4.2b3 started by root, uid 0
Sep  2 12:25:47 host pppd[19968]: Using interface ppp1
Sep  2 12:25:47 host pppd[19968]: Connect: ppp1 <--> /dev/pts/2
Sep  2 12:25:47 host pptpd[19967]: GRE: Bad checksum from pppd.
Sep  2 12:25:47 host pptpd[19967]: GRE: xmit failed from decaps_hdlc: 
Operation not permitted
Sep  2 12:25:47 host pptpd[19967]: CTRL: PTY read or GRE write failed 
(pty,gre)=(5,6)
Sep  2 12:25:47 host pptpd[19967]: CTRL: Client 10.233.0.1 control 
connection finished
Sep  2 12:25:47 host pppd[19968]: Terminating on signal 2.
Sep  2 12:25:47 host pppd[19968]: Modem hangup
Sep  2 12:25:47 host pppd[19968]: Connection terminated.
Sep  2 12:25:47 host pppd[19968]: Exit.

The second is the "LCP: timeout sending Config-Requests" error:

Aug 26 11:07:38 host pptpd[16915]: CTRL: Client 10.233.0.8 control 
connection started
Aug 26 11:07:38 host pptpd[16915]: CTRL: Starting call (launching pppd, 
opening GRE)
Aug 26 11:07:38 host pppd[16916]: pppd 2.4.2b3 started by root, uid 0
Aug 26 11:07:38 host pppd[16916]: Using interface ppp1
Aug 26 11:07:38 host pppd[16916]: Connect: ppp1 <--> /dev/pts/1
Aug 26 11:07:38 host pptpd[16915]: GRE: Bad checksum from pppd.
Aug 26 11:08:08 host pppd[16916]: LCP: timeout sending Config-Requests
Aug 26 11:08:08 host pppd[16916]: Connection terminated.
Aug 26 11:08:08 host pppd[16916]: Exit.
Aug 26 11:08:08 host pptpd[16915]: GRE: 
read(fd=5,buffer=804d960,len=8196) from PTY failed: status = -1 error = 
Input/output error
Aug 26 11:08:08 host pptpd[16915]: CTRL: PTY read or GRE write failed 
(pty,gre)=(5,6)
Aug 26 11:08:08 host pptpd[16915]: CTRL: Client 10.233.0.8 control 
connection finished

Some other possibly relevant details:

The MTU and MRU on PPTP PPP intefaces is set quite low (750) to avoid
"out of order packet" issues commonly experienced with Poptop.

TCPMSS is set to 706 for all TCP traffic going through PPTP interfaces
for similar reasons. This is done with the following rules:

TCPMSS     tcp  --  ppp+   *       0.0.0.0/0            0.0.0.0/0
tcp flags:0x06/0x02 TCPMSS set 706
TCPMSS     tcp  --  *      ppp+    0.0.0.0/0            0.0.0.0/0 
   tcp flags:0x06/0x02 TCPMSS set 706

During my testing generally only _one_ host is used for anything to do
with PPTP (either PPTP NAT thru the firewall or PPTP connection to the
firewall). I would of course like multiple clients working both thru
and connecting to the firewall box.

I've primarily been testing with WinXP and Win2k clients.

I've tested this with a totally clear firewall (just ACCEPT policies
on the default chains) with the PPTP conntrack modules loaded and the
problem still occurs.

A possibly useful observation:
I've found that when I'm having troubles connecting from a Windows
client to Poptop, connecting to a Windows 2000 PPTP server,
disconnecting, and then trying Poptop again causes things to work in
straight away or with 1 retry. I suspect the whole problem here is
timing related (hence the intermittent nature).  I'm guessing that
once the Windows client has successfully connected somewhere the
timing of packet transmissions during future connections changes in
our favour wrt the Linux config. I know this sounds "out there" but
this is repeatable behaviour.

I've googled around extensively and hunted through the netfilter
mailing list archives and have found some posts describing similar
problems but no conclusive answers. I've tried with and without
LOCAL_NAT compiled in.

Is there a way to get PPTP NAT and Poptop to co-exist happily on the
same box?

I would really like to get this working and am happy to try patches,
test various scenarios, provide packet dumps or whatever is required.

Any help or pointers would be greatly appreciated.

The PPTP NAT modules seem really close to being fully functional. It
would be fantastic to iron out the last remaining issues.

Thanks,
Menno

Re: PPTP connection tracking and Poptop on same box

[Jeff Hall]

I experienced some of these problems also trying to get 2.4.20 working
with PoPToP and making outgoing connections from PCs behind the PoPToP
server. Take a look at my messages dated March 2,3,20,21 and
April 8 of this year in the netfilter-devel archives. With the patches
in those messages I have multiple sessions connecting to a PoPToP server
running on my firewall server and can make at least one outgoing
connection from a PC behind that server (I didn't test making multiple
outgoing connections but I believe that will also worked based on some
tests I ran months ago). I also successfully tested running a PPTP client
on the PoPToP server.

I have not (at least knowingly) modified the connection MTU, MRU, or
TCPMSS and while I occassionally get the 'out of order' messages from
pptpd the connection seems to recover. I'm using PoPToP v 1.1.3-2 with a
patch to generate unique call ids.

Hope this helps.

Jeff Hall

  On Tue, 2 Sep 2003, Menno Smits wrote:

  > Hi,
  >
  > I'm experiencing some frustrating problems using PPTP connection
  > tracking/NAT with Poptop on the same box.
  >
  > I'm using kernel 2.4.21 with the latest PPTP (and related) POM patches
  > from CVS. I'm using Poptop v1.1.4.
  >
  > Without ip_nat_pptp and friends loaded connections to Poptop work
  > flawlessly.
  >
  > When ip_nat_pptp etc is loaded connection tracking and NAT _through_
  > the box to external servers works great.
  >
  > However, when the PPTP NAT+conntrack modules are loaded, connections
  > to Poptop running on the Linux box are highly unreliable.  Connections
  > to Poptop are difficult to establish and generally take several
  > attempts before they work.  Sometimes you get lucky and the connection
  > works first go. Other times it can take 10s of attempts. Once a
  > connection is established it seems to function and remain that way.
  >
  > There seems to be two types of errors I get from Poptop and pppd when
  > a connection attempt fails. They seem to be fairly interchangable.
  >
  > The first is the "Operation not permitted" error:
  >
  > Sep  2 12:25:47 host pptpd[19967]: CTRL: Client 10.233.0.1 control
  > connection started
  > Sep  2 12:25:47 host pptpd[19967]: CTRL: Starting call (launching pppd,
  > opening GRE)
  > Sep  2 12:25:47 host pppd[19968]: pppd 2.4.2b3 started by root, uid 0
  > Sep  2 12:25:47 host pppd[19968]: Using interface ppp1
  > Sep  2 12:25:47 host pppd[19968]: Connect: ppp1 <--> /dev/pts/2
  > Sep  2 12:25:47 host pptpd[19967]: GRE: Bad checksum from pppd.
  > Sep  2 12:25:47 host pptpd[19967]: GRE: xmit failed from decaps_hdlc:
  > Operation not permitted
  > Sep  2 12:25:47 host pptpd[19967]: CTRL: PTY read or GRE write failed
  > (pty,gre)=(5,6)
  > Sep  2 12:25:47 host pptpd[19967]: CTRL: Client 10.233.0.1 control
  > connection finished
  > Sep  2 12:25:47 host pppd[19968]: Terminating on signal 2.
  > Sep  2 12:25:47 host pppd[19968]: Modem hangup
  > Sep  2 12:25:47 host pppd[19968]: Connection terminated.
  > Sep  2 12:25:47 host pppd[19968]: Exit.
  >
  > The second is the "LCP: timeout sending Config-Requests" error:
  >
  > Aug 26 11:07:38 host pptpd[16915]: CTRL: Client 10.233.0.8 control
  > connection started
  > Aug 26 11:07:38 host pptpd[16915]: CTRL: Starting call (launching pppd,
  > opening GRE)
  > Aug 26 11:07:38 host pppd[16916]: pppd 2.4.2b3 started by root, uid 0
  > Aug 26 11:07:38 host pppd[16916]: Using interface ppp1
  > Aug 26 11:07:38 host pppd[16916]: Connect: ppp1 <--> /dev/pts/1
  > Aug 26 11:07:38 host pptpd[16915]: GRE: Bad checksum from pppd.
  > Aug 26 11:08:08 host pppd[16916]: LCP: timeout sending Config-Requests
  > Aug 26 11:08:08 host pppd[16916]: Connection terminated.
  > Aug 26 11:08:08 host pppd[16916]: Exit.
  > Aug 26 11:08:08 host pptpd[16915]: GRE:
  > read(fd=5,buffer=804d960,len=8196) from PTY failed: status = -1 error =
  > Input/output error
  > Aug 26 11:08:08 host pptpd[16915]: CTRL: PTY read or GRE write failed
  > (pty,gre)=(5,6)
  > Aug 26 11:08:08 host pptpd[16915]: CTRL: Client 10.233.0.8 control
  > connection finished
  >
  > Some other possibly relevant details:
  >
  > The MTU and MRU on PPTP PPP intefaces is set quite low (750) to avoid
  > "out of order packet" issues commonly experienced with Poptop.
  >
  > TCPMSS is set to 706 for all TCP traffic going through PPTP interfaces
  > for similar reasons. This is done with the following rules:
  >
  > TCPMSS     tcp  --  ppp+   *       0.0.0.0/0            0.0.0.0/0
  > tcp flags:0x06/0x02 TCPMSS set 706
  > TCPMSS     tcp  --  *      ppp+    0.0.0.0/0            0.0.0.0/0
  >    tcp flags:0x06/0x02 TCPMSS set 706
  >
  > During my testing generally only _one_ host is used for anything to do
  > with PPTP (either PPTP NAT thru the firewall or PPTP connection to the
  > firewall). I would of course like multiple clients working both thru
  > and connecting to the firewall box.
  >
  > I've primarily been testing with WinXP and Win2k clients.
  >
  > I've tested this with a totally clear firewall (just ACCEPT policies
  > on the default chains) with the PPTP conntrack modules loaded and the
  > problem still occurs.
  >
  > A possibly useful observation:
  > I've found that when I'm having troubles connecting from a Windows
  > client to Poptop, connecting to a Windows 2000 PPTP server,
  > disconnecting, and then trying Poptop again causes things to work in
  > straight away or with 1 retry. I suspect the whole problem here is
  > timing related (hence the intermittent nature).  I'm guessing that
  > once the Windows client has successfully connected somewhere the
  > timing of packet transmissions during future connections changes in
  > our favour wrt the Linux config. I know this sounds "out there" but
  > this is repeatable behaviour.
  >
  > I've googled around extensively and hunted through the netfilter
  > mailing list archives and have found some posts describing similar
  > problems but no conclusive answers. I've tried with and without
  > LOCAL_NAT compiled in.
  >
  > Is there a way to get PPTP NAT and Poptop to co-exist happily on the
  > same box?
  >
  > I would really like to get this working and am happy to try patches,
  > test various scenarios, provide packet dumps or whatever is required.
  >
  > Any help or pointers would be greatly appreciated.
  >
  > The PPTP NAT modules seem really close to being fully functional. It
  > would be fantastic to iron out the last remaining issues.
  >
  > Thanks,
  > Menno
  >
  >
  >
  >
  >

Re: PPTP connection tracking and Poptop on same box

[Menno Smits]

Hi Jeff,

Thanks for your quick reply.

Jeff Hall wrote:
> I experienced some of these problems also trying to get 2.4.20 working
> with PoPToP and making outgoing connections from PCs behind the PoPToP
> server. Take a look at my messages dated March 2,3,20,21 and
> April 8 of this year in the netfilter-devel archives. With the patches
> in those messages I have multiple sessions connecting to a PoPToP server
> running on my firewall server and can make at least one outgoing
> connection from a PC behind that server (I didn't test making multiple
> outgoing connections but I believe that will also worked based on some
> tests I ran months ago). I also successfully tested running a PPTP client
> on the PoPToP server.

I've read those posts before but I went over them again just to make 
sure I hadn't missed anything.

I checked the patches in your posts against a POM patched 2.4.20 kernel 
I used to use here which exhibits the same problems as my 2.4.21 kernel. 
I can't even find where your patches to ip_conntrack_pptp.c could be 
applied! (even when trying to apply the patch manually). Key lines which 
surround your changes simply don't exist in my tree. I was using POM out 
of CVS from a few months ago in that kernel. What POM version are you 
using? Which POM patches are you using?

I'm thinking I might try a vanilla kernel with the bare minimum of 
patches to support PPTP conntrack. Knowing what POM version and patches 
you're using would be useful for me so I can try and duplicate your setup.

> I have not (at least knowingly) modified the connection MTU, MRU, or
> TCPMSS and while I occassionally get the 'out of order' messages from
> pptpd the connection seems to recover. I'm using PoPToP v 1.1.3-2 with a
> patch to generate unique call ids.

Actually the MTU/MRU/TCPMSS stuff was to deal with "GRE: Discarding 
duplicate packet" problems not 'out of order packet" problems like I 
originally stated (it was a while ago). I removed these workarounds 
today just to make sure that these had nothing to do with the problems 
I'm having. Connection attempts seemed to behave in just the same way 
(unreliably), and I started getting lots of "GRE: Discarding duplicate 
packet" messages when a connection did establish and data was transferred.

Today I also made sure that the pptpd version I'm using (1.1.4) has the 
callid patch and it definitely does. I modified it to log the callids 
its using and it uses different ids for each connection, so no issue 
there. Besides, that only becomes important once you have multiple 
clients involved and so far in my testing there's only one.



Menno

Re: PPTP connection tracking and Poptop on same box

[Jeff Hall]

  On Thu, 4 Sep 2003, Menno Smits wrote:

  > Hi Jeff,
  >
  > Thanks for your quick reply.
  >
  > Jeff Hall wrote:
  > > I experienced some of these problems also trying to get 2.4.20 working
  > > with PoPToP and making outgoing connections from PCs behind the PoPToP
  > > server. Take a look at my messages dated March 2,3,20,21 and
  > > April 8 of this year in the netfilter-devel archives. With the patches
  > > in those messages I have multiple sessions connecting to a PoPToP server
  > > running on my firewall server and can make at least one outgoing
  > > connection from a PC behind that server (I didn't test making multiple
  > > outgoing connections but I believe that will also worked based on some
  > > tests I ran months ago). I also successfully tested running a PPTP client
  > > on the PoPToP server.
  >
  > I've read those posts before but I went over them again just to make
  > sure I hadn't missed anything.
  >
  > I checked the patches in your posts against a POM patched 2.4.20 kernel
  > I used to use here which exhibits the same problems as my 2.4.21 kernel.
  > I can't even find where your patches to ip_conntrack_pptp.c could be
  > applied! (even when trying to apply the patch manually). Key lines which
  > surround your changes simply don't exist in my tree. I was using POM out
  > of CVS from a few months ago in that kernel. What POM version are you
  > using? Which POM patches are you using?
  >
I started with the 20030107 POM but then added individual patches I
needed from the CVS archives. I tried to detail them as clearly as possible
in the March 2nd and 3rd memos. I'm afraid that is the best I can do now
after 6 months.  I'll send you the fully patched sources I'm using in a
personal message. I hope you find them useful. I'll send you anything
dated newer than when I ran the 20030107 POM against the 2.4.20 base.
  > I'm thinking I might try a vanilla kernel with the bare minimum of
  > patches to support PPTP conntrack. Knowing what POM version and patches
  > you're using would be useful for me so I can try and duplicate your setup.
  >
  > > I have not (at least knowingly) modified the connection MTU, MRU, or
  > > TCPMSS and while I occassionally get the 'out of order' messages from
  > > pptpd the connection seems to recover. I'm using PoPToP v 1.1.3-2 with a
  > > patch to generate unique call ids.
  >
  > Actually the MTU/MRU/TCPMSS stuff was to deal with "GRE: Discarding
  > duplicate packet" problems not 'out of order packet" problems like I
  > originally stated (it was a while ago). I removed these workarounds
  > today just to make sure that these had nothing to do with the problems
  > I'm having. Connection attempts seemed to behave in just the same way
  > (unreliably), and I started getting lots of "GRE: Discarding duplicate
  > packet" messages when a connection did establish and data was transferred.
  >
I consistently receive one "GRE: Discarding duplicate packet" message per
connection. But it never causes any problem so I've never pursued the cause.
I see on Sourceforge that the single message problem is due to an initial-
zation error in pptpgre.c (see the diff 1.4 vs 1.3). I've never had a problem
with multiple "duplicate..." errors. Possibly they are due to the kernel
delivering GRE packets to the wrong pptpd process.
  > Today I also made sure that the pptpd version I'm using (1.1.4) has the
  > callid patch and it definitely does. I modified it to log the callids
  > its using and it uses different ids for each connection, so no issue
  > there. Besides, that only becomes important once you have multiple
  > clients involved and so far in my testing there's only one.
  >
  >
  >
  > Menno
  >
  >
Good luck.

Re: PPTP connection tracking and Poptop on same box

[Wim Ceulemans]

[-- Attachment #1: Type: text/plain, Size: 4672 bytes --]

Hi

I had some problems with GRE not passing through to a server behind the 
firewall.
I then used kernel 2.4.22 and the latest pom snapshot 
(patch-o-matic-20030831) with iptables 1.2.8
and gre passed through.

However, after testing I notice now that although PPTP connections to a 
win2000 server behind the
firewall work, that the connection is not reliable. After 3 to 4 minutes 
the connection is closed for
some unknown reason and people have to re-establish the connection.

Anyone experiencing this problem also?

Regards
Wim

Jeff Hall wrote:

>  On Thu, 4 Sep 2003, Menno Smits wrote:
>
>  > Hi Jeff,
>  >
>  > Thanks for your quick reply.
>  >
>  > Jeff Hall wrote:
>  > > I experienced some of these problems also trying to get 2.4.20 working
>  > > with PoPToP and making outgoing connections from PCs behind the PoPToP
>  > > server. Take a look at my messages dated March 2,3,20,21 and
>  > > April 8 of this year in the netfilter-devel archives. With the patches
>  > > in those messages I have multiple sessions connecting to a PoPToP server
>  > > running on my firewall server and can make at least one outgoing
>  > > connection from a PC behind that server (I didn't test making multiple
>  > > outgoing connections but I believe that will also worked based on some
>  > > tests I ran months ago). I also successfully tested running a PPTP client
>  > > on the PoPToP server.
>  >
>  > I've read those posts before but I went over them again just to make
>  > sure I hadn't missed anything.
>  >
>  > I checked the patches in your posts against a POM patched 2.4.20 kernel
>  > I used to use here which exhibits the same problems as my 2.4.21 kernel.
>  > I can't even find where your patches to ip_conntrack_pptp.c could be
>  > applied! (even when trying to apply the patch manually). Key lines which
>  > surround your changes simply don't exist in my tree. I was using POM out
>  > of CVS from a few months ago in that kernel. What POM version are you
>  > using? Which POM patches are you using?
>  >
>I started with the 20030107 POM but then added individual patches I
>needed from the CVS archives. I tried to detail them as clearly as possible
>in the March 2nd and 3rd memos. I'm afraid that is the best I can do now
>after 6 months.  I'll send you the fully patched sources I'm using in a
>personal message. I hope you find them useful. I'll send you anything
>dated newer than when I ran the 20030107 POM against the 2.4.20 base.
>  > I'm thinking I might try a vanilla kernel with the bare minimum of
>  > patches to support PPTP conntrack. Knowing what POM version and patches
>  > you're using would be useful for me so I can try and duplicate your setup.
>  >
>  > > I have not (at least knowingly) modified the connection MTU, MRU, or
>  > > TCPMSS and while I occassionally get the 'out of order' messages from
>  > > pptpd the connection seems to recover. I'm using PoPToP v 1.1.3-2 with a
>  > > patch to generate unique call ids.
>  >
>  > Actually the MTU/MRU/TCPMSS stuff was to deal with "GRE: Discarding
>  > duplicate packet" problems not 'out of order packet" problems like I
>  > originally stated (it was a while ago). I removed these workarounds
>  > today just to make sure that these had nothing to do with the problems
>  > I'm having. Connection attempts seemed to behave in just the same way
>  > (unreliably), and I started getting lots of "GRE: Discarding duplicate
>  > packet" messages when a connection did establish and data was transferred.
>  >
>I consistently receive one "GRE: Discarding duplicate packet" message per
>connection. But it never causes any problem so I've never pursued the cause.
>I see on Sourceforge that the single message problem is due to an initial-
>zation error in pptpgre.c (see the diff 1.4 vs 1.3). I've never had a problem
>with multiple "duplicate..." errors. Possibly they are due to the kernel
>delivering GRE packets to the wrong pptpd process.
>  > Today I also made sure that the pptpd version I'm using (1.1.4) has the
>  > callid patch and it definitely does. I modified it to log the callids
>  > its using and it uses different ids for each connection, so no issue
>  > there. Besides, that only becomes important once you have multiple
>  > clients involved and so far in my testing there's only one.
>  >
>  >
>  >
>  > Menno
>  >
>  >
>Good luck.
>
>  
>


-- 
Wim Ceulemans
R&D Engineer

Secure Internet Communication with aXs Guard

Able NV
Leuvensesteenweg 282 - B-3190 Boortmeerbeek - Belgium
Phone: + 32 15 50.44.00 - Fax: + 32 15 50.44.09
E-mail: wim.ceulemans@able.be



--
Security check on this e-mail has been done by aXs GUARD
(http://www.axsguard.com)

Re: PPTP connection tracking and Poptop on same box

[Jeff Hall]

Inactivity timeout?

On Thu, 4 Sep 2003, Wim Ceulemans wrote:

> Hi
>
> I had some problems with GRE not passing through to a server behind the
> firewall.
> I then used kernel 2.4.22 and the latest pom snapshot
> (patch-o-matic-20030831) with iptables 1.2.8
> and gre passed through.
>
> However, after testing I notice now that although PPTP connections to a
> win2000 server behind the
> firewall work, that the connection is not reliable. After 3 to 4 minutes
> the connection is closed for
> some unknown reason and people have to re-establish the connection.
>
> Anyone experiencing this problem also?
>
> Regards
> Wim
>
> Jeff Hall wrote:
>
> >  On Thu, 4 Sep 2003, Menno Smits wrote:
> >
> >  > Hi Jeff,
> >  >
> >  > Thanks for your quick reply.
> >  >
> >  > Jeff Hall wrote:
> >  > > I experienced some of these problems also trying to get 2.4.20 working
> >  > > with PoPToP and making outgoing connections from PCs behind the PoPToP
> >  > > server. Take a look at my messages dated March 2,3,20,21 and
> >  > > April 8 of this year in the netfilter-devel archives. With the patches
> >  > > in those messages I have multiple sessions connecting to a PoPToP server
> >  > > running on my firewall server and can make at least one outgoing
> >  > > connection from a PC behind that server (I didn't test making multiple
> >  > > outgoing connections but I believe that will also worked based on some
> >  > > tests I ran months ago). I also successfully tested running a PPTP client
> >  > > on the PoPToP server.
> >  >
> >  > I've read those posts before but I went over them again just to make
> >  > sure I hadn't missed anything.
> >  >
> >  > I checked the patches in your posts against a POM patched 2.4.20 kernel
> >  > I used to use here which exhibits the same problems as my 2.4.21 kernel.
> >  > I can't even find where your patches to ip_conntrack_pptp.c could be
> >  > applied! (even when trying to apply the patch manually). Key lines which
> >  > surround your changes simply don't exist in my tree. I was using POM out
> >  > of CVS from a few months ago in that kernel. What POM version are you
> >  > using? Which POM patches are you using?
> >  >
> >I started with the 20030107 POM but then added individual patches I
> >needed from the CVS archives. I tried to detail them as clearly as possible
> >in the March 2nd and 3rd memos. I'm afraid that is the best I can do now
> >after 6 months.  I'll send you the fully patched sources I'm using in a
> >personal message. I hope you find them useful. I'll send you anything
> >dated newer than when I ran the 20030107 POM against the 2.4.20 base.
> >  > I'm thinking I might try a vanilla kernel with the bare minimum of
> >  > patches to support PPTP conntrack. Knowing what POM version and patches
> >  > you're using would be useful for me so I can try and duplicate your setup.
> >  >
> >  > > I have not (at least knowingly) modified the connection MTU, MRU, or
> >  > > TCPMSS and while I occassionally get the 'out of order' messages from
> >  > > pptpd the connection seems to recover. I'm using PoPToP v 1.1.3-2 with a
> >  > > patch to generate unique call ids.
> >  >
> >  > Actually the MTU/MRU/TCPMSS stuff was to deal with "GRE: Discarding
> >  > duplicate packet" problems not 'out of order packet" problems like I
> >  > originally stated (it was a while ago). I removed these workarounds
> >  > today just to make sure that these had nothing to do with the problems
> >  > I'm having. Connection attempts seemed to behave in just the same way
> >  > (unreliably), and I started getting lots of "GRE: Discarding duplicate
> >  > packet" messages when a connection did establish and data was transferred.
> >  >
> >I consistently receive one "GRE: Discarding duplicate packet" message per
> >connection. But it never causes any problem so I've never pursued the cause.
> >I see on Sourceforge that the single message problem is due to an initial-
> >zation error in pptpgre.c (see the diff 1.4 vs 1.3). I've never had a problem
> >with multiple "duplicate..." errors. Possibly they are due to the kernel
> >delivering GRE packets to the wrong pptpd process.
> >  > Today I also made sure that the pptpd version I'm using (1.1.4) has the
> >  > callid patch and it definitely does. I modified it to log the callids
> >  > its using and it uses different ids for each connection, so no issue
> >  > there. Besides, that only becomes important once you have multiple
> >  > clients involved and so far in my testing there's only one.
> >  >
> >  >
> >  >
> >  > Menno
> >  >
> >  >
> >Good luck.
> >
> >
> >
>
>
> --
> Wim Ceulemans
> R&D Engineer
>
> Secure Internet Communication with aXs Guard
>
> Able NV
> Leuvensesteenweg 282 - B-3190 Boortmeerbeek - Belgium
> Phone: + 32 15 50.44.00 - Fax: + 32 15 50.44.09
> E-mail: wim.ceulemans@able.be
>
>
>
> --
> Security check on this e-mail has been done by aXs GUARD
> (http://www.axsguard.com)
>
>

Re: PPTP connection tracking and Poptop on same box

[Menno Smits]

Jeff Hall wrote:

>   > I checked the patches in your posts against a POM patched 2.4.20 kernel
>   > I used to use here which exhibits the same problems as my 2.4.21 kernel.
>   > I can't even find where your patches to ip_conntrack_pptp.c could be
>   > applied! (even when trying to apply the patch manually). Key lines which
>   > surround your changes simply don't exist in my tree. I was using POM out
>   > of CVS from a few months ago in that kernel. What POM version are you
>   > using? Which POM patches are you using?
>   >
> I started with the 20030107 POM but then added individual patches I
> needed from the CVS archives. I tried to detail them as clearly as possible
> in the March 2nd and 3rd memos. I'm afraid that is the best I can do now
> after 6 months.  I'll send you the fully patched sources I'm using in a
> personal message. I hope you find them useful. I'll send you anything
> dated newer than when I ran the 20030107 POM against the 2.4.20 base.

Thanks for trying to remember. I appreciate that asking you to remember
what obscure patches you used 6 months ago is a bit of an ask :)

I've received the sources and will give them a go.

Some other interesting findings:
I tested connections to Poptop further yesterday. This time I connected
via a 1.5Mbps Internet link rather than the 100Mbps LAN that I've been
using for previous testing. Connections via this link were much more
likely to work! I think the higher latency of the link may have
something to do with it. This re-enforces my statement in the first
message of this thread that the problem might be timing related.

>   > Actually the MTU/MRU/TCPMSS stuff was to deal with "GRE: Discarding
>   > duplicate packet" problems not 'out of order packet" problems like I
>   > originally stated (it was a while ago). I removed these workarounds
>   > today just to make sure that these had nothing to do with the problems
>   > I'm having. Connection attempts seemed to behave in just the same way
>   > (unreliably), and I started getting lots of "GRE: Discarding duplicate
>   > packet" messages when a connection did establish and data was transferred.
>   >
> I consistently receive one "GRE: Discarding duplicate packet" message per
> connection. But it never causes any problem so I've never pursued the cause.
> I see on Sourceforge that the single message problem is due to an initial-
> zation error in pptpgre.c (see the diff 1.4 vs 1.3). I've never had a problem
> with multiple "duplicate..." errors. Possibly they are due to the kernel
> delivering GRE packets to the wrong pptpd process.

I'm not sure what exactly is behind the duplicate packet messages but
lowering the MTU, MRU and TCPMSS definitely makes them go away. It also
seems to improve performance somewhat. At some sites I found that file
transfers would grind to a halt with huge numbers of duplicate packet
messages being logged unless the MTU etc was lowered.

Thanks again.

Menno

Re: PPTP connection tracking and Poptop on same box

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

On Fri, Sep 05, 2003 at 10:21:31AM +1000, Menno Smits wrote:
> Jeff Hall wrote:
> 
> >  > I checked the patches in your posts against a POM patched 2.4.20 kernel
> >  > I used to use here which exhibits the same problems as my 2.4.21 
> >  kernel.
> >  > I can't even find where your patches to ip_conntrack_pptp.c could be
> >  > applied! (even when trying to apply the patch manually). Key lines 
> >  which
> >  > surround your changes simply don't exist in my tree. I was using POM 
> >  out
> >  > of CVS from a few months ago in that kernel. What POM version are you
> >  > using? Which POM patches are you using?
> >  >
> >I started with the 20030107 POM but then added individual patches I
> >needed from the CVS archives. I tried to detail them as clearly as possible
> >in the March 2nd and 3rd memos. I'm afraid that is the best I can do now
> >after 6 months.  I'll send you the fully patched sources I'm using in a
> >personal message. I hope you find them useful. I'll send you anything
> >dated newer than when I ran the 20030107 POM against the 2.4.20 base.
> 
> Thanks for trying to remember. I appreciate that asking you to remember
> what obscure patches you used 6 months ago is a bit of an ask :)

I'm sorry for this whole mess.  Releasing a new version of the
pptp-conntrack-nat patch is on my TODO list for quite some time.  I'll
expect it to be done during the next week.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: PPTP connection tracking and Poptop on same box

[Menno Smits]

  > I'm sorry for this whole mess.  Releasing a new version of the
> pptp-conntrack-nat patch is on my TODO list for quite some time.  I'll
> expect it to be done during the next week.

Great, look forward to it.

Menno

Re: PPTP connection tracking and Poptop on same box

[Philip Craig]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

Hi Harald,

Harald Welte wrote:
> I'm sorry for this whole mess.  Releasing a new version of the
> pptp-conntrack-nat patch is on my TODO list for quite some time.  I'll
> expect it to be done during the next week.

When you do this, you will need the attached patches.  Jeff Hall
posted them to the list on 2003/04/08, but I couldn't find them
in the netfilter CVS anywhere.

natcore-noexpecthelper.patch is related to 25natcore-nohelper.patch
which was applied in 2.4.22.  25natcore-nohelper.patch stopped us
from calling ip_nat_helper->help() when there were no manips, but
we were still calling ip_nat_helper->expect().  This was corrupting
the call IDs in the GRE packets.

pptp-grekeymapdestroy.patch does some more cleaning up when freeing
the unused second expectation.

I now have pptp connection tracking working using linux 2.4.22,
the latest patch from netfilter/patch-o-matic/extra, the latest
files from netfilter-extensions/helpers/pptp, and the attached
two patches.

I have two concerns with the current patches:

25natcore-nohelper.patch fixed the problem where we were doing
NAT for connections even if there was no matching NAT rules.
However, we now have the opposite problem in that we don't do
NAT even if we should.  This is because this patch bases the
decision on the number of manipulations, but it is possible to
match a NAT rule and have no manipulations.

The impact of this is that I cannot guarentee unique call IDs for
local connections when doing masquerading, since they usually have
no manipulations (they will occassionally have a port manip).

The only solution I can see for this problem is to add another
field to ip_nat_info to determine whether a NAT rule was matched.

The second concern is that I believe we choose the NATed call ID
based on the TCP source port prior to source NAT, which means we
may not get a unique call ID.  If you agree this is a problem
then I can try to fix it.

-- 
Philip Craig - philipc@snapgear.com - http://www.SnapGear.com
SnapGear - Custom Embedded Solutions and Security Appliances

[-- Attachment #2: natcore-noexpecthelper.patch --]
[-- Type: text/plain, Size: 644 bytes --]

--- linux-2.4.x/net/ipv4/netfilter/ip_nat_standalone.c	25 Jun 2003 13:50:47 -0000	1.5
+++ linux-2.4.x/net/ipv4/netfilter/ip_nat_standalone.c	5 Sep 2003 05:29:24 -0000	1.6
@@ -121,8 +121,13 @@
 			if (ct->master
 			    && master_ct(ct)->nat.info.helper
 			    && master_ct(ct)->nat.info.helper->expect) {
-				ret = call_expect(master_ct(ct), pskb, 
+				if (master_ct(ct)->nat.info.num_manips) {
+					ret = call_expect(master_ct(ct), pskb, 
 						  hooknum, ct, info);
+				} else {
+					WRITE_UNLOCK(&ip_nat_lock);
+					return NF_ACCEPT;
+				}
 			} else {
 #ifdef CONFIG_IP_NF_NAT_LOCAL
 				/* LOCAL_IN hook doesn't have a chain!  */

[-- Attachment #3: pptp-grekeymapdestroy.patch --]
[-- Type: text/plain, Size: 448 bytes --]

--- linux-2.4.x/net/ipv4/netfilter/ip_conntrack_pptp.c	5 Sep 2003 04:24:24 -0000	1.12
+++ linux-2.4.x/net/ipv4/netfilter/ip_conntrack_pptp.c	5 Sep 2003 05:29:24 -0000	1.13
@@ -124,6 +124,7 @@
 			/* remove only if occurred at same sequence number */
 			if (other_exp != exp && other_exp->seq == exp->seq) {
 				DEBUGP("unexpecting other direction\n");
+				ip_ct_gre_keymap_destroy(exp);
 				ip_conntrack_unexpect_related(other_exp);
 			}
 		}

Re: PPTP connection tracking and Poptop on same box

[Wim Ceulemans]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

Hi

Any news on the PPTP connection tracking problem?

Regards
Wim

Menno Smits wrote:

>  > I'm sorry for this whole mess.  Releasing a new version of the
>
>> pptp-conntrack-nat patch is on my TODO list for quite some time.  I'll
>> expect it to be done during the next week.
>
>
> Great, look forward to it.
>
> Menno
>
>


-- 
Wim Ceulemans
R&D Engineer

Secure Internet Communication with aXs Guard

Able NV
Leuvensesteenweg 282 - B-3190 Boortmeerbeek - Belgium
Phone: + 32 15 50.44.00 - Fax: + 32 15 50.44.09
E-mail: wim.ceulemans@able.be



--
Security check on this e-mail has been done by aXs GUARD
(http://www.axsguard.com)

Re: PPTP connection tracking and Poptop on same box

[Menno Smits]

I haven't seen anything turn up in CVS yet. I imagine Harald hasn't had 
time to do it yet.

You may want to check out Phillip Craig's post on the 17th of Sept to 
netfilter-devel. It lists a set of steps that worked for him with 
currently released code and patches. I've been meaning to try these 
exact steps myself but haven't had time to do it yet.

Menno


Wim Ceulemans wrote:
> Hi
> 
> Any news on the PPTP connection tracking problem?
> 
> Regards
> Wim
> 
> Menno Smits wrote:
> 
>>  > I'm sorry for this whole mess.  Releasing a new version of the
>>
>>> pptp-conntrack-nat patch is on my TODO list for quite some time.  I'll
>>> expect it to be done during the next week.
>>
>>
>>
>> Great, look forward to it.
>>
>> Menno
>>
>>
> 
> 

Re: PPTP connection tracking and Poptop on same box

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 4462 bytes --]

On Tue, Sep 09, 2003 at 06:39:56PM +1000, Philip Craig wrote:
> When you do this, you will need the attached patches.  

I'm finally at home again, being able to test PPTP with multiple
machines.  Expect a new pptp-conntrack-nat.patch later today.

> natcore-noexpecthelper.patch is related to 25natcore-nohelper.patch
> which was applied in 2.4.22.  25natcore-nohelper.patch stopped us
> from calling ip_nat_helper->help() when there were no manips, but
> we were still calling ip_nat_helper->expect().  This was corrupting
> the call IDs in the GRE packets.

mh. this is a real problem.  However, I am now convinced that
25_natcore-nohelper.patch was the wrong way to address the problem
anyway (see below).

> pptp-grekeymapdestroy.patch does some more cleaning up when freeing
> the unused second expectation.

ok, applied to netfilter-extensions CVS repository

> I now have pptp connection tracking working using linux 2.4.22,
> the latest patch from netfilter/patch-o-matic/extra, the latest
> files from netfilter-extensions/helpers/pptp, and the attached
> two patches.

great.  NAT works also?

> 25natcore-nohelper.patch fixed the problem where we were doing
> NAT for connections even if there was no matching NAT rules.
> However, we now have the opposite problem in that we don't do
> NAT even if we should.  This is because this patch bases the
> decision on the number of manipulations, but it is possible to
> match a NAT rule and have no manipulations.
> 
> The impact of this is that I cannot guarentee unique call IDs for
> local connections when doing masquerading, since they usually have
> no manipulations (they will occassionally have a port manip).
> 
> The only solution I can see for this problem is to add another
> field to ip_nat_info to determine whether a NAT rule was matched.

No, this is too complicated.  Let's try to thing again about what we
want to achieve:

1) unique call ID between every (srcip,dstip) tuple.  This is needed
   for distinguishing GRE packets for different calls

This is different to TCP/UDP port numbers in the 'normal' case.  The NAT
core deals with this in the FTP/IRC case for TCP port numbers, because
at the time the number is first used (PORT command, ...), the tuple for
the expectation is alrady complete.

In the PPTP case, however, we only have half the tuple when the CallID
is sent to the PAC, and the full tuple once the CallID from the PAC is
received :(

Thus, my initial solution (until the 25_natcore-nohelper.patch) was to
_always_ mangle the PNS->PAC callID to the TCP source port, independent
of any NAT rules present or not.  This would prevent multiple PPTP Calls
within one PPTP Session, but I've never seen such operation anyway.  The
TCP Source Port (after mangling, see below) has to be unique between two
IP addresses, since the destination port is fixed to 1723

However, there were some problems with running a PPTP daemon on the PPTP
NAT box at the same time, and I never really understand the source of
the problem [most likely because I didn't have enough time].  So I went
for the 'quick fix now, real solution later' approach, that ended up
with the 25_natcore-nohelper.patch.

I am now even more convinced that this is the wrong way to solve the
problem.  Adding your patch would make the behaviour consistent (don't
call expect if the master's help was never called)... but the problem of
non-unique CallID's remains.

So what I'm doing now, is to revert the 25_natcore_nohelper.patch and
see what the real problem with locally NAT'ed connections was/is.

> The second concern is that I believe we choose the NATed call ID
> based on the TCP source port prior to source NAT, which means we
> may not get a unique call ID.  If you agree this is a problem
> then I can try to fix it.

Yes, this is a problem.  If you want to work on a fix, I'd be more to
happy to integrate it.

> Philip Craig - philipc@snapgear.com - http://www.SnapGear.com
> SnapGear - Custom Embedded Solutions and Security Appliances

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: PPTP connection tracking and Poptop on same box

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

Hi again!

After some long debugging about gre keymap entries that hadn't been
automatically freed (and thus free()d at kernel unload time) I found a
bug:

On Tue, Sep 09, 2003 at 06:39:56PM +1000, Philip Craig wrote:

>  			/* remove only if occurred at same sequence number */
>  			if (other_exp != exp && other_exp->seq == exp->seq) {
>  				DEBUGP("unexpecting other direction\n");
> +				ip_ct_gre_keymap_destroy(exp);

This has to be other_exp instead of exp.  Now all four keymap entries
per connection are destroyed as expected.

I'll continue my tests tomorrow.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: PPTP connection tracking and Poptop on same box

[Philip Craig]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

Harald Welte wrote:
> great.  NAT works also?

Actually, I've only tested with NAT.

> However, there were some problems with running a PPTP daemon on the PPTP
> NAT box at the same time, and I never really understand the source of
> the problem [most likely because I didn't have enough time].  So I went
> for the 'quick fix now, real solution later' approach, that ended up
> with the 25_natcore-nohelper.patch.

If I recall correctly, the problem was that local PPTP connections did not
work unless you also had CONFIG_IP_NF_NAT_LOCAL enabled.  This was because
the helper/expect were being called at LOCAL_OUT, but not at LOCAL_IN,
and so the manips were only created for one direction.

Is it possible to change it so that the helper is not called at all
at LOCAL_OUT unless CONFIG_IP_NF_NAT_LOCAL is enabled?

Btw, why do we even have the LOCAL_OUT hook for nat when
CONFIG_IP_NF_NAT_LOCAL is disabled?

>>The second concern is that I believe we choose the NATed call ID
>>based on the TCP source port prior to source NAT, which means we
>>may not get a unique call ID.  If you agree this is a problem
>>then I can try to fix it.
> 
> 
> Yes, this is a problem.  If you want to work on a fix, I'd be more to
> happy to integrate it.

I've attached a patch for this.

-- 
Philip Craig - philipc@snapgear.com - http://www.SnapGear.com
SnapGear - Custom Embedded Solutions and Security Appliances

[-- Attachment #2: pptp-nat-source.patch --]
[-- Type: text/plain, Size: 488 bytes --]

--- netfilter-extensions/helpers/pptp/ip_nat_pptp.c	4 Jul 2003 19:05:57 -0000	1.4
+++ netfilter-extensions/helpers/pptp/ip_nat_pptp.c	22 Sep 2003 04:41:46 -0000
@@ -170,7 +170,7 @@
 			/* save original call ID in nat_info */
 			nat_pptp_info->pns_call_id = ct_pptp_info->pns_call_id;
 
-			new_callid = tcph->source;
+			new_callid = ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u.tcp.port;
 			/* save new call ID in ct info */
 			ct_pptp_info->pns_call_id = ntohs(new_callid);
 			break;

Re: PPTP connection tracking and Poptop on same box

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2500 bytes --]

On Mon, Sep 22, 2003 at 06:06:29PM +1000, Philip Craig wrote:
> Harald Welte wrote:
> >great.  NAT works also?
> 
> Actually, I've only tested with NAT.
> 
> >However, there were some problems with running a PPTP daemon on the PPTP
> >NAT box at the same time, and I never really understand the source of
> >the problem [most likely because I didn't have enough time].  So I went
> >for the 'quick fix now, real solution later' approach, that ended up
> >with the 25_natcore-nohelper.patch.
> 
> If I recall correctly, the problem was that local PPTP connections did not
> work unless you also had CONFIG_IP_NF_NAT_LOCAL enabled.  This was because
> the helper/expect were being called at LOCAL_OUT, but not at LOCAL_IN,
> and so the manips were only created for one direction.
> 
> Is it possible to change it so that the helper is not called at all
> at LOCAL_OUT unless CONFIG_IP_NF_NAT_LOCAL is enabled?
> 
> Btw, why do we even have the LOCAL_OUT hook for nat when
> CONFIG_IP_NF_NAT_LOCAL is disabled?

because of the history...

1) SNAT of locally-originated connections (rules in POSTROUTING).  We
   need to mangle reply packets at NF_IP_PRE_ROUTING.  This case works
   without CONFIG_IP_NF_NAT_LOCAL, and has always been working.

2) DNAT of local packets (rules in OUTPUT).  We need to mangle the reply
   packets at NF_IP_LOCAL_IN.  This was broken for a long time (from
   2.4.0 to 2.4.18).  It was broken in a 'silent' way. 

If I'm not missing something, we could just remove the hook registration
for LOCAL_OUT in case CONFIG_IP_NF_NAT_LOCAL is undefined.  We have to
continue providing the OUTPUT chain, however - for compatibility to
userspace.

I've written a patch. Will test that late today and put it in pom, if it
looks good.

> I've attached a patch for this.

Thanks, applied to CVS (with some additional comment since I tend to
forget stuff like this, not even talking about other people who try to
read that code).

> -- 
> Philip Craig - philipc@snapgear.com - http://www.SnapGear.com
> SnapGear - Custom Embedded Solutions and Security Appliances

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: PPTP connection tracking and Poptop on same box

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

On Mon, Jan 19, 2004 at 12:03:32AM +0000, Antony Stone wrote:
> On Sunday 18 January 2004 11:47 pm, Carl Farrington wrote:
> 
> > From: Antony Stone [mailto:Antony@Soft-Solutions.co.uk]
> >
> > > On Sunday 18 January 2004 11:00 pm, Carl Farrington wrote:
> > > > Does anybody know if there is a workaround for this problem? As soon
> > > > as I insmod ip_nat_pptp , poptop cannot accept any incoming pptp
> > > > connections.
> >
> > > Why do you want to use both of these on the same box?
> 
> > Well, I want to do both. I am putting together a router/gateway box. It
> > performs NAT for all the workstations on the private side of the box
> > (hence the need for ip_nat_pptp since some workstations need to contact
> > outside pptp servers), and also allows access from the outside when
> > users are roaming (hence the need for poptop).
> >
> > Astaro Security Linux (www.astaro.com) is one product which achieves
> > this without problem using poptop, as is win2k rras.
> 
> In that case your simplest solution might be to ask Astaro how they've done 
> it.   Their products are based on Linux / netfilter etc, so should be fully 
> GPL.

If you read the PPTP helper sourcecode, you will find that I wrote it
for astaro.  There's no black magic in ASL, they're using the same code
that is in patch-o-matic.

Carl: Are you sure you are running the latest pptp helper from
patch-o-matic (20031219) ?

> Antony
 

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: PPTP connection tracking and Poptop on same box

[Carl Farrington]

> -----Original Message-----
> From: Antony Stone [mailto:Antony@Soft-Solutions.co.uk]
> Sent: 19 January 2004 00:04
> To: netfilter@lists.netfilter.org
> Subject: Re: PPTP connection tracking and Poptop on same box
> 
> On Sunday 18 January 2004 11:47 pm, Carl Farrington wrote:
> 
> > From: Antony Stone [mailto:Antony@Soft-Solutions.co.uk]
> >
> > > On Sunday 18 January 2004 11:00 pm, Carl Farrington wrote:
> > > > Does anybody know if there is a workaround for this problem? As
soon
> > > > as I insmod ip_nat_pptp , poptop cannot accept any incoming pptp
> > > > connections.
> >
> > > Why do you want to use both of these on the same box?
> 
> > Well, I want to do both. I am putting together a router/gateway box.
It
> > performs NAT for all the workstations on the private side of the box
> > (hence the need for ip_nat_pptp since some workstations need to
contact
> > outside pptp servers), and also allows access from the outside when
> > users are roaming (hence the need for poptop).
> >
> > Astaro Security Linux (www.astaro.com) is one product which achieves
> > this without problem using poptop, as is win2k rras.
> 
> In that case your simplest solution might be to ask Astaro how they've
> done
> it.   Their products are based on Linux / netfilter etc, so should be
> fully
> GPL.
> 
> Antony
> 

It seems this might prove more difficult than one would hope. Source
code is not available from Astaro - they instead claim that any source
code would simply be direct copies from ftp.gnu.org, and that they
release all their patches back to project maintainers. Hmmmm.

Excuse the long url (I felt a http://tinyurl thing might appear
untrustworthy, but here's some talk on it:

http://www.astaro.org/showflat.php?Cat=&Board=UBB2&Number=26110&Forum=Al
l_Forums&Words=GPL&Match=Entire%20Phrase&Searchpage=0&Limit=25&Old=1year
&Main=3557&Search=true#Post26110

Carl

Re: PPTP connection tracking and Poptop on same box

[Antony Stone]

On Sunday 18 January 2004 11:47 pm, Carl Farrington wrote:

> From: Antony Stone [mailto:Antony@Soft-Solutions.co.uk]
>
> > On Sunday 18 January 2004 11:00 pm, Carl Farrington wrote:
> > > Does anybody know if there is a workaround for this problem? As soon
> > > as I insmod ip_nat_pptp , poptop cannot accept any incoming pptp
> > > connections.
>
> > Why do you want to use both of these on the same box?

> Well, I want to do both. I am putting together a router/gateway box. It
> performs NAT for all the workstations on the private side of the box
> (hence the need for ip_nat_pptp since some workstations need to contact
> outside pptp servers), and also allows access from the outside when
> users are roaming (hence the need for poptop).
>
> Astaro Security Linux (www.astaro.com) is one product which achieves
> this without problem using poptop, as is win2k rras.

In that case your simplest solution might be to ask Astaro how they've done 
it.   Their products are based on Linux / netfilter etc, so should be fully 
GPL.

Antony

-- 
The difference between theory and practice is that in theory there is no 
difference, whereas in practice there is.

Re: PPTP connection tracking and Poptop on same box

[Antony Stone]

On Sunday 18 January 2004 11:00 pm, Carl Farrington wrote:

> Does anybody know if there is a workaround for this problem? As soon as
> I insmod ip_nat_pptp , poptop cannot accept any incoming pptp
> connections.

Why do you want to use both of these on the same box?

ip_nat_pptp is only needed for PPTP connections being routed *through* the 
machine.

poptop is only needed for PPTP connections terminating *on* the machine.

I can quite easily imagine that these two functions would not work together, 
because of the unhelpful way in which PPTP embeds IP addresses inside the 
protocol.   If you load ip_nat_pptp then the packets are going to get mangled 
(correctly for routing, but not for terminating here), and if you don't load 
it then you can't route across a NATted connection (but you can run PPTP on 
the box itself).

Seems to me like you need to choose whether you're routing or terminating the 
PPTP connections, and use the correct solution for whichever it is.

Antony.

-- 
I'm pink, therefore I'm Spam.

                                                     Please reply to the list;
                                                           please don't CC me.

PPTP connection tracking and Poptop on same box

[Carl Farrington]

Does anybody know if there is a workaround for this problem? As soon as
I insmod ip_nat_pptp , poptop cannot accept any incoming pptp
connections.

The topic was brought up around September 2003 here:
http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/0122
98.html


cheers,
Carl

PPTP connection tracking and Poptop on same box

[Menno Smits]

Hi,

I'm experiencing some frustrating problems using PPTP connection
tracking/NAT with Poptop on the same box.

I'm using kernel 2.4.21 with the latest PPTP (and related) POM patches
from CVS. I'm using Poptop v1.1.4.

Without ip_nat_pptp and friends loaded connections to Poptop work
flawlessly.

When ip_nat_pptp etc is loaded connection tracking and NAT _through_
the box to external servers works great.

However, when the PPTP NAT+conntrack modules are loaded, connections
to Poptop running on the Linux box are highly unreliable.  Connections
to Poptop are difficult to establish and generally take several
attempts before they work.  Sometimes you get lucky and the connection
works first go. Other times it can take 10s of attempts. Once a
connection is established it seems to function and remain that way.

There seems to be two types of errors I get from Poptop and pppd when
a connection attempt fails. They seem to be fairly interchangable.

The first is the "Operation not permitted" error:

Sep  2 12:25:47 host pptpd[19967]: CTRL: Client 10.233.0.1 control
connection started
Sep  2 12:25:47 host pptpd[19967]: CTRL: Starting call (launching pppd,
opening GRE)
Sep  2 12:25:47 host pppd[19968]: pppd 2.4.2b3 started by root, uid 0
Sep  2 12:25:47 host pppd[19968]: Using interface ppp1
Sep  2 12:25:47 host pppd[19968]: Connect: ppp1 <--> /dev/pts/2
Sep  2 12:25:47 host pptpd[19967]: GRE: Bad checksum from pppd.
Sep  2 12:25:47 host pptpd[19967]: GRE: xmit failed from decaps_hdlc:
Operation not permitted
Sep  2 12:25:47 host pptpd[19967]: CTRL: PTY read or GRE write failed
(pty,gre)=(5,6)
Sep  2 12:25:47 host pptpd[19967]: CTRL: Client 10.233.0.1 control
connection finished
Sep  2 12:25:47 host pppd[19968]: Terminating on signal 2.
Sep  2 12:25:47 host pppd[19968]: Modem hangup
Sep  2 12:25:47 host pppd[19968]: Connection terminated.
Sep  2 12:25:47 host pppd[19968]: Exit.

The second is the "LCP: timeout sending Config-Requests" error:

Aug 26 11:07:38 host pptpd[16915]: CTRL: Client 10.233.0.8 control
connection started
Aug 26 11:07:38 host pptpd[16915]: CTRL: Starting call (launching pppd,
opening GRE)
Aug 26 11:07:38 host pppd[16916]: pppd 2.4.2b3 started by root, uid 0
Aug 26 11:07:38 host pppd[16916]: Using interface ppp1
Aug 26 11:07:38 host pppd[16916]: Connect: ppp1 <--> /dev/pts/1
Aug 26 11:07:38 host pptpd[16915]: GRE: Bad checksum from pppd.
Aug 26 11:08:08 host pppd[16916]: LCP: timeout sending Config-Requests
Aug 26 11:08:08 host pppd[16916]: Connection terminated.
Aug 26 11:08:08 host pppd[16916]: Exit.
Aug 26 11:08:08 host pptpd[16915]: GRE:
read(fd=5,buffer=804d960,len=8196) from PTY failed: status = -1 error =
Input/output error
Aug 26 11:08:08 host pptpd[16915]: CTRL: PTY read or GRE write failed
(pty,gre)=(5,6)
Aug 26 11:08:08 host pptpd[16915]: CTRL: Client 10.233.0.8 control
connection finished

Some other possibly relevant details:

The MTU and MRU on PPTP PPP intefaces is set quite low (750) to avoid
"out of order packet" issues commonly experienced with Poptop.

TCPMSS is set to 706 for all TCP traffic going through PPTP interfaces
for similar reasons. This is done with the following rules:

TCPMSS     tcp  --  ppp+   *       0.0.0.0/0            0.0.0.0/0
tcp flags:0x06/0x02 TCPMSS set 706
TCPMSS     tcp  --  *      ppp+    0.0.0.0/0            0.0.0.0/0
   tcp flags:0x06/0x02 TCPMSS set 706

During my testing generally only _one_ host is used for anything to do
with PPTP (either PPTP NAT thru the firewall or PPTP connection to the
firewall). I would of course like multiple clients working both thru
and connecting to the firewall box.

I've primarily been testing with WinXP and Win2k clients.

I've tested this with a totally clear firewall (just ACCEPT policies
on the default chains) with the PPTP conntrack modules loaded and the
problem still occurs.

A possibly useful observation:
I've found that when I'm having troubles connecting from a Windows
client to Poptop, connecting to a Windows 2000 PPTP server,
disconnecting, and then trying Poptop again causes things to work in
straight away or with 1 retry. I suspect the whole problem here is
timing related (hence the intermittent nature).  I'm guessing that
once the Windows client has successfully connected somewhere the
timing of packet transmissions during future connections changes in
our favour wrt the Linux config. I know this sounds "out there" but
this is repeatable behaviour.

I've googled around extensively and hunted through the netfilter
mailing list archives and have found some posts describing similar
problems but no conclusive answers. I've tried with and without
LOCAL_NAT compiled in.

Is there a way to get PPTP NAT and Poptop to co-exist happily on the
same box?

I would really like to get this working and am happy to try patches,
test various scenarios, provide packet dumps or whatever is required.

Any help or pointers would be greatly appreciated.

The PPTP NAT modules seem really close to being fully functional. It
would be fantastic to iron out the last remaining issues.

Thanks,
Menno