Conntrack PPTP broken in 2.4.22 ?

Conntrack PPTP broken in 2.4.22 ?

[Enrico Demarin]

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

Hi, 
 
I have tried to use the pptp_conntrack patch from the last patch-o-matic
on Linux kernel 2.4.22 , but with that patch applied, apps using
 
getsockopt SO_ORIGINAL_DST stop working  :
 
the perror i get is : 
 
getsockopt(SO_ORIGINAL_DST): No such file or directory
 
 
I am using iptables 1.2.8.
 
 
Any idea why ?
 
Please CC my email as im not subscribed to the list yet.
 
thanks in advance
Enrico
 
 
 

[-- Attachment #2: Type: text/html, Size: 2662 bytes --]

Re: Conntrack PPTP broken in 2.4.22 ?

[Philip Craig]

Enrico Demarin wrote:
> I have tried to use the pptp_conntrack patch from the last patch-o-matic
> on Linux kernel 2.4.22 , but with that patch applied, apps using
>  
> getsockopt SO_ORIGINAL_DST stop working  :
>  
> the perror i get is : 
>  
> getsockopt(SO_ORIGINAL_DST): No such file or directory

The following patch in the netfilter patch-o-matic CVS is meant to fix this:

http://cvs.netfilter.org/~checkout~/netfilter/patch-o-matic/pending/63_getorigdst-tuple-zero.patch?sortby=rev

But unfortunately that patch is broken too, and you'll need to apply the
patch from this message to fix the patch:

http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012382.html

(Btw, check the netfilter-devel archives for this month for some
discussion about what patches you need for pptp conntrack.)

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

RE: Conntrack PPTP broken in 2.4.22 ?

[Enrico Demarin]

The problem goes away with the patches you mentioned. I also tried to
establish a connection from a NATed box behind

The linux firewall to an external PPTP server ( win2k and linux poptop)
: it works , even without the module loaded .

I think at this point I miss the functionality of the pptp_conntrack
module ? When is it necessary to load it ?

- Enrico

> -----Original Message-----
> From: Philip Craig [mailto:philipc@snapgear.com] 
> Sent: venerdì 12 settembre 2003 2.37
> To: Enrico Demarin
> Cc: netfilter@lists.netfilter.org
> Subject: Re: Conntrack PPTP broken in 2.4.22 ?
> 
> 
> Enrico Demarin wrote:
> > I have tried to use the pptp_conntrack patch from the last 
> > patch-o-matic on Linux kernel 2.4.22 , but with that patch applied, 
> > apps using
> >  
> > getsockopt SO_ORIGINAL_DST stop working  :
> >  
> > the perror i get is :
> >  
> > getsockopt(SO_ORIGINAL_DST): No such file or directory
> 
> The following patch in the netfilter patch-o-matic CVS is 
> meant to fix this:
> 
http://cvs.netfilter.org/~checkout~/netfilter/patch-o-matic/pending/63_g
etorigdst-tuple-zero.patch?sortby=rev

But unfortunately that patch is broken too, and you'll need to apply the
patch from this message to fix the patch:

http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/0123
82.html

(Btw, check the netfilter-devel archives for this month for some
discussion about what patches you need for pptp conntrack.)

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

Re: Conntrack PPTP broken in 2.4.22 ?

[Philip Craig]

Enrico Demarin wrote:
> I think at this point I miss the functionality of the pptp_conntrack
> module ? When is it necessary to load it ?

The module basically performs three tasks.

1. NAT of the callid

This ensures that the PPTP callid is unique per client/server pair.
This is only necessary when you have multiple clients that are NATed
to the same source address.  Without it, the server will get confused.

2. Tracking of gre connections

The gre connections are tracked as RELATED connections, which makes
it easy to add a rule to let them through the firewall.

3. NAT of gre connections

This ensures incoming gre packets are forwarded to the correct
internal server/client.

Since you typically only have one internal server, this is just a
convenience which means you don't need to add a gre DNAT rule.

However this is necessary if you have multiple clients that are NATed
to the same source address, so that the firewall knows which client
to forward the gre packet to.

NAT of gre can also be helpful for a single client.  Without it,
packets from the server may be dropped if the client hasn't sent
a packet recently.  This is because you typically don't have a DNAT
rule to forward gre to the client, so the client has to send the gre
packet first to establish the conntrack, and this conntrack will
timeout after 30-180 seconds of inactivity.  You can workaround
this problem by configuring PPP to send LCP echoes to keep the
conntrack active.

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

RE: Conntrack PPTP broken in 2.4.22 ?

[Enrico Demarin]

Thanks for the thorough explanation Craig, The info you sent

should be made part of the "help" section in the kernel configuration of
the GRE / PPTP modules.

Any idea if the PPTP conntrack module will make it into the mainstream
kernel ? 


One more (unrelated?) question : is it possible to disable connection
tracking on a per interface basis ?

- Enrico

> -----Original Message-----
> From: Philip Craig [mailto:philipc@snapgear.com] 
> Sent: lunedì 15 settembre 2003 2.58
> To: Enrico Demarin
> Cc: netfilter@lists.netfilter.org
> Subject: Re: Conntrack PPTP broken in 2.4.22 ?
> 
> 
> Enrico Demarin wrote:
> > I think at this point I miss the functionality of the 
> pptp_conntrack 
> > module ? When is it necessary to load it ?
> 
> The module basically performs three tasks.
> 
> 1. NAT of the callid
> 
> This ensures that the PPTP callid is unique per client/server 
> pair. This is only necessary when you have multiple clients 
> that are NATed to the same source address.  Without it, the 
> server will get confused.
> 
> 2. Tracking of gre connections
> 
> The gre connections are tracked as RELATED connections, which 
> makes it easy to add a rule to let them through the firewall.
> 
> 3. NAT of gre connections
> 
> This ensures incoming gre packets are forwarded to the 
> correct internal server/client.
> 
> Since you typically only have one internal server, this is 
> just a convenience which means you don't need to add a gre DNAT rule.
> 
> However this is necessary if you have multiple clients that 
> are NATed to the same source address, so that the firewall 
> knows which client to forward the gre packet to.
> 
> NAT of gre can also be helpful for a single client.  Without 
> it, packets from the server may be dropped if the client 
> hasn't sent a packet recently.  This is because you typically 
> don't have a DNAT rule to forward gre to the client, so the 
> client has to send the gre packet first to establish the 
> conntrack, and this conntrack will timeout after 30-180 
> seconds of inactivity.  You can workaround this problem by 
> configuring PPP to send LCP echoes to keep the conntrack active.
> 
> -- 
> Philip Craig - philipc@snapgear.com - http://www.SnapGear.com 
> SnapGear - Custom Embedded Solutions and Security Appliances
> 

Re: Conntrack PPTP broken in 2.4.22 ?

[Philip Craig]

Enrico Demarin wrote:
> Any idea if the PPTP conntrack module will make it into the mainstream
> kernel ? 

Eventually yes.  I doubt it has been stable enough yet to
consider it.

> One more (unrelated?) question : is it possible to disable connection
> tracking on a per interface basis ?

Have a look at patch-o-matic/userspace/raw.patch, which adds
a NOTRACK target.

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