PPTP conntracking saga continued

PPTP conntracking saga continued

[Craig Box]

Hi everyone,

I've been trying to figure out PPTP connection tracking for some time,
and spent half a day battling with old versions of the patches and then
finally got the modules to compile, before reading that Harald has a new
version out due out any day now.  

If I have a standard kernel.org kernel running iptables/netfilter (no
patch-o-matic patches), I can observe the following behaivour:

* I have a DNAT on the firewall machine to send all VPN traffic (1723
TCP/GRE) to an internal Windows PPTP server
* From inside my LAN I can connect out to any other Windows PPTP server
and establish a connection (the GRE replies are matched by the
connection tracking and sent back to the internal machine, not blindly
routed to the Windows server
* If I disconnect there is a 10 min time out in which I can't connect
from any other machine behind my NAT (understandably; the timeout is
counting down in /proc/net/ip_conntrack) - can someone confirm that this
problem is worked around by the PPTP conntrack patches in p-o-m?

- However -

* If I connect _outward_ to a Poptop VPN server, same network, the
initial GRE replies come back and are DNAT'd to the internal Windows
PPTP server, therefore the connection does not create

I am not sure if this is the fault of Poptop or the connection tracking.
I would assume that, because the conntracking handles Windows servers
right, that Poptop is at fault, and people on this list speak of a
connid patch to Poptop that addresses this (although I can find no other
mention of it.)

Strangely enough, reading poptop's website, their FAQ
(http://poptop.sourceforge.net/dox/qna.html) says:

"The only way to distinguish between those two clients is to filter them
by destination call ID number found in the GRE header. In order for the
client NAT firewall to correctly rewrite the PPTP server's replies,
please check Philip Craig's netfilter pptp helper module available from
the Netfilter CVS server. [..] It will be integrated in KernelMod, but
until then, you'll have to build it yourself"

Are they referring to the same thing as Harald's PPTP conntracking
patch?  Is there indeed a new version (that will compile cleanly against
2.4.22) due out soon?  Is poptop at fault, or is connection tracking?

Thanks in advance for any insight you can give me.

(Please CC me replies as I am not currently on the list)

Thanks,
Craig Box
Hamilton, New Zealand

Re: PPTP conntracking saga continued

[Philip Craig]

Craig Box wrote:
> I've been trying to figure out PPTP connection tracking for some time,
> and spent half a day battling with old versions of the patches and then
> finally got the modules to compile, before reading that Harald has a new
> version out due out any day now.  

I have had success with the following:

1. Start with Linux 2.4.22
2. Apply patch-o-matic/pending/63_getorigdst-tuple-zero.patch
3. Apply patch-o-matic/extra/pptp-conntrack-nat.patch
4. Copy in the files from netfilter-extensions/helpers/pptp
5. Apply the patches from:
http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012362.html

> If I have a standard kernel.org kernel running iptables/netfilter (no
> patch-o-matic patches), I can observe the following behaivour:
> 
> * I have a DNAT on the firewall machine to send all VPN traffic (1723
> TCP/GRE) to an internal Windows PPTP server
> * From inside my LAN I can connect out to any other Windows PPTP server
> and establish a connection (the GRE replies are matched by the
> connection tracking and sent back to the internal machine, not blindly
> routed to the Windows server

Yes, because the DNAT rule is only used for packets that are not part
of an existing connection.

> * If I disconnect there is a 10 min time out in which I can't connect
> from any other machine behind my NAT (understandably; the timeout is
> counting down in /proc/net/ip_conntrack) - can someone confirm that this
> problem is worked around by the PPTP conntrack patches in p-o-m?

This is because it is using the generic protocol conntrack, which can
only distinguish between gre connections by IP address, and has a 10
minute timeout.  The pptp conntrack patch will fix this since it can
distinguish between gre connections using the call ID.

> - However -
> 
> * If I connect _outward_ to a Poptop VPN server, same network, the
> initial GRE replies come back and are DNAT'd to the internal Windows
> PPTP server, therefore the connection does not create

This is most likely because the Poptop server is faster than your client,
and it is sending an incoming GRE packet before your client sends the
outgoing packet.  There will be no existing conntrack for the incoming
packet, so it will match the DNAT rule.

> I am not sure if this is the fault of Poptop or the connection tracking.
> I would assume that, because the conntracking handles Windows servers
> right, that Poptop is at fault, and people on this list speak of a
> connid patch to Poptop that addresses this (although I can find no other
> mention of it.)

The Poptop connid bug is only a problem once you try multiple
simultaneous connections.

> Strangely enough, reading poptop's website, their FAQ
> (http://poptop.sourceforge.net/dox/qna.html) says:
> 
> "The only way to distinguish between those two clients is to filter them
> by destination call ID number found in the GRE header. In order for the
> client NAT firewall to correctly rewrite the PPTP server's replies,
> please check Philip Craig's netfilter pptp helper module available from
> the Netfilter CVS server. [..] It will be integrated in KernelMod, but
> until then, you'll have to build it yourself"
> 
> Are they referring to the same thing as Harald's PPTP conntracking
> patch?  Is there indeed a new version (that will compile cleanly against
> 2.4.22) due out soon?  Is poptop at fault, or is connection tracking?

I've never written a netfilter pptp helper, just submitted patches
for existing ones.  Harald's pptp conntracking patch is the only
one that will work, and it will fix the problems you are having.

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

RE: PPTP conntracking saga continued

[Craig Box]

> I have had success with the following:
> 
> 1. Start with Linux 2.4.22
> 2. Apply patch-o-matic/pending/63_getorigdst-tuple-zero.patch
> 3. Apply patch-o-matic/extra/pptp-conntrack-nat.patch
> 4. Copy in the files from netfilter-extensions/helpers/pptp
> 5. Apply the patches from:
>
http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/0123
62.html

Well, the kernel compiled cleanly (which is a first!), even with IPSEC
and MPPE patches.

However, something about NAT and forwarding doesn't go.  The problem
isn't the firewalling ruleset; the machine still forwards (I can ping
between networks that the machine routes between) but it doesn't let me
ping from an internal machine to an internet machine.  I can access the
internet from the machine locally however.

The (two) internet connections are to ADSL routers via PPTP; could this
be part of the problem?

I didn't spend as much time as I'd have wanted to tcpdumping, as in
order to test everything works I really need to run it on a real world
connected machine instead of a proper test environment, and people
needed their internet connection back. I'll experiment again without the
other patches, but is there any known fault here, or is there anything
in the way of debugging information I should post to try and solve this
one?

Craig