PPTP and NAT

PPTP and NAT

[Boingo]

Hi there,
    I had RH9 (default out of box) installed.  I could
do everything I needed to on iptables except get
outside connections to our internal Win2k PPTP server
to work.  So I went and got the kernel source (2.4.26)
from kernel.org and patched it with CVS patch-o-matic
(CVS date: April 27, 2004).  I only added patches
related to PPTP (ipv4 only).  Recompiled and booted
into the new kernel.
 
    Now even my old port forwards to internal nat'ed
servers wont work.  When restarting iptables I get an
"iptables-restore: line X failed" (with X being the
actual line number).  If I take out that line, then it
errors on a different line.  It continues like this,
until all the line with PREROUTING or POSTROUTING are
removed.  These lines (minus the PPTP ones) all worked
fined before the patch/recompile.  I have included my
iptables file below, external ip is 1.2.3.4 (real ip
changed to protect the innocent).  All the entries in
the nat table worked before the patch.  Can anyone
shed light on this issue?  Thanks in advance for any
help you can provide.
 
 
 
*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -s 192.168.10.0/24 -d 0/0 -j
MASQUERADE
-A POSTROUTING -d 192.168.10.1 -j SNAT --to
192.168.10.3
-A POSTROUTING -d 192.168.10.2 -j SNAT --to
192.168.10.3
-A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 25 -j
DNAT --to-destination 192.168.10.2:25
-A PREROUTING -p udp -m udp -d 1.2.3.4 --dport 47 -j
DNAT --to-destination 192.168.10.1:47
-A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 80 -j
DNAT --to-destination 192.168.10.2:80
-A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 99 -j
DNAT --to-destination 192.168.10.2:99
-A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 110 -j
DNAT --to-destination 192.168.10.2:110
-A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 1723 -j
DNAT --to-destination 192.168.10.1:1723
-A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 1974 -j
DNAT --to-destination 192.168.10.2:1974
-A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 1975 -j
DNAT --to-destination 192.168.10.2:1975
-A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 3389 -j
DNAT --to-destination 192.168.10.1:3389
COMMIT
*mangle
:PREROUTING ACCEPT [92:7225]
:INPUT ACCEPT [92:7225]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [92:7225]
:POSTROUTING ACCEPT [92:7225]
COMMIT
*filter
:FORWARD DROP [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 1.2.3.4 -j ACCEPT
-A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
--dport 25 -j ACCEPT
-A FORWARD -p udp -m udp -d 192.168.10.1 -i eth0
--dport 47 -j ACCEPT
-A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
--dport 80 -j ACCEPT
-A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
--dport 99 -j ACCEPT
-A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
--dport 110 -j ACCEPT
-A FORWARD -p tcp -m tcp -d 192.168.10.1 -i eth0
--dport 1723 -j ACCEPT
-A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
--dport 1974 -j ACCEPT
-A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
--dport 1975 -j ACCEPT
-A FORWARD -p tcp -m tcp -d 192.168.10.1 -i eth0
--dport 3389 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT
-A FORWARD -i eth1 -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i eth0 -m state --state
ESTABLISHED,RELATED     -j ACCEPT
-A FORWARD -p tcp -d 192.168.10.1 --dport 1723 -m
state --state NEW -j ACCEPT
COMMIT

Re: PPTP and NAT

[Luke Deryckx]

You'll also need to recompile iptables to work properly with your newly
patched kernel. I couldn't tell from your message if you had done that or
not. 

When I went through this process I had my kernel source (2.4.25) sym linked
to /usr/src/linux and my iptables source (1.2.7a) symlinked to
/usr/src/iptables when I ran the patch-o-matic. I never was sure if the
patch-o-matic actually changed the iptables source at all or not but that's
how I had it. After building and booting your new kernel, just go into
/usr/src/iptables and run a super easy make & make install.

Note though that on my Redhat 9 machine I needed to modify the Makefile and
change the install location(s) so that the newly patched iptables would
overwrite the old one, and the system could find it.

Luke



On 4/28/04 9:22 AM, "Boingo" <b0ing0@yahoo.com> wrote:

> Hi there,
>   I had RH9 (default out of box) installed.  I could
> do everything I needed to on iptables except get
> outside connections to our internal Win2k PPTP server
> to work.  So I went and got the kernel source (2.4.26)
> from kernel.org and patched it with CVS patch-o-matic
> (CVS date: April 27, 2004).  I only added patches
> related to PPTP (ipv4 only).  Recompiled and booted
> into the new kernel.
> 
>   Now even my old port forwards to internal nat'ed
> servers wont work.  When restarting iptables I get an
> "iptables-restore: line X failed" (with X being the
> actual line number).  If I take out that line, then it
> errors on a different line.  It continues like this,
> until all the line with PREROUTING or POSTROUTING are
> removed.  These lines (minus the PPTP ones) all worked
> fined before the patch/recompile.  I have included my
> iptables file below, external ip is 1.2.3.4 (real ip
> changed to protect the innocent).  All the entries in
> the nat table worked before the patch.  Can anyone
> shed light on this issue?  Thanks in advance for any
> help you can provide.
> 
> 
> 
> *nat
> :OUTPUT ACCEPT [0:0]
> :PREROUTING ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> -A POSTROUTING -o eth0 -s 192.168.10.0/24 -d 0/0 -j
> MASQUERADE
> -A POSTROUTING -d 192.168.10.1 -j SNAT --to
> 192.168.10.3
> -A POSTROUTING -d 192.168.10.2 -j SNAT --to
> 192.168.10.3
> -A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 25 -j
> DNAT --to-destination 192.168.10.2:25
> -A PREROUTING -p udp -m udp -d 1.2.3.4 --dport 47 -j
> DNAT --to-destination 192.168.10.1:47
> -A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 80 -j
> DNAT --to-destination 192.168.10.2:80
> -A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 99 -j
> DNAT --to-destination 192.168.10.2:99
> -A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 110 -j
> DNAT --to-destination 192.168.10.2:110
> -A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 1723 -j
> DNAT --to-destination 192.168.10.1:1723
> -A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 1974 -j
> DNAT --to-destination 192.168.10.2:1974
> -A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 1975 -j
> DNAT --to-destination 192.168.10.2:1975
> -A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 3389 -j
> DNAT --to-destination 192.168.10.1:3389
> COMMIT
> *mangle
> :PREROUTING ACCEPT [92:7225]
> :INPUT ACCEPT [92:7225]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [92:7225]
> :POSTROUTING ACCEPT [92:7225]
> COMMIT
> *filter
> :FORWARD DROP [0:0]
> :INPUT ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> -A INPUT -i eth1 -j ACCEPT
> -A INPUT -i lo -j ACCEPT
> -A INPUT -s 1.2.3.4 -j ACCEPT
> -A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
> --dport 25 -j ACCEPT
> -A FORWARD -p udp -m udp -d 192.168.10.1 -i eth0
> --dport 47 -j ACCEPT
> -A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
> --dport 80 -j ACCEPT
> -A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
> --dport 99 -j ACCEPT
> -A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
> --dport 110 -j ACCEPT
> -A FORWARD -p tcp -m tcp -d 192.168.10.1 -i eth0
> --dport 1723 -j ACCEPT
> -A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
> --dport 1974 -j ACCEPT
> -A FORWARD -p tcp -m tcp -d 192.168.10.2 -i eth0
> --dport 1975 -j ACCEPT
> -A FORWARD -p tcp -m tcp -d 192.168.10.1 -i eth0
> --dport 3389 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT
> -A FORWARD -i eth1 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> -A FORWARD -i eth0 -m state --state
> ESTABLISHED,RELATED     -j ACCEPT
> -A FORWARD -p tcp -d 192.168.10.1 --dport 1723 -m
> state --state NEW -j ACCEPT
> COMMIT

Re: [Fwd: PPTP in 2.4.20]

[Harald Welte]

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

On Sun, Dec 21, 2003 at 07:08:43PM -0700, Gary Thomas wrote:
> Harald,
> 
> I'm in a bit of a pickle here & need to get this working.  The 
> mailing list has not come up with any ideas, so if you have any, 
> I'd sure appreciate them.

Sorry, we've never ever had a single report about this error message.

It basically means that somebody else has already registered for the
SO_GET_ORIGDST socket option.  I have no idea who else could be the
culprit.  Maybe you have loaded (or statically linked into the kernel)
one of the backwards compatibility modules for ipchains or ipfwadm?

Also, please make sure that the kernel and the modules are out of the
same build, otherwise you might experience all kinds of inconsistencies

> Thanks.

> -- 
> Gary Thomas <gary@chez-thomas.org>

Content-Description: Forwarded message - PPTP in 2.4.20
> Subject: PPTP in 2.4.20
> From: Gary Thomas <gary@chez-thomas.org>
> To: netfilter@lists.netfilter.org
> Organization: 
> X-Spam-Score: -8.1 (--------)
> List-Archive: <https://lists.netfilter.org/pipermail/netfilter/>
> Date: 20 Dec 2003 08:32:45 -0700
> X-Spam-Status: No, hits=-6.2 required=5.0
> 	tests=AWL,BAYES_01,KNOWN_MAILING_LIST,USER_AGENT_XIMIAN version=2.55
> X-Spam-Level: 
> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
> 
> I've tried to build kernel 2.4.20, using the patches applied
> via patch-o-matic (thanks, Harald!)  However, I can't get the
> PPTP modules to load.  In particular, when I try to load
> 'ip_conntrack', I get these messages:
> 
> [root@hermes gthomas]# insmod ip_conntrack
> Using /lib/modules/2.4.20-TEST/kernel/net/ipv4/netfilter/ip_conntrack.o
> /lib/modules/2.4.20-TEST/kernel/net/ipv4/netfilter/ip_conntrack.o: init_module: Device or resource busy
> [root@hermes gthomas]# tail /var/log/messages
> Dec 20 07:34:31 hermes kernel: ip_conntrack version 2.1 (4094 buckets, 32752 max) - 312 bytes per conntrack
> Dec 20 07:34:31 hermes kernel: Unable to register netfilter socket option
> 
> Of course, without this module loaded, I can't load any of the 
> other [important for PPTP] ones.
> 
> Any help or ideas greatly appreciated.
> 
> -- 
> Gary Thomas <gary@chez-thomas.org>
> 


-- 
- 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 --]

PPTP and NAT

[Jan Kaastrup]

Hi
Are there anybody who has tried to connect with more than one client to
a poptop VPN server, where the clients come from the same global
ipadress? (doing SNAT)

There seems to be a problem when i do that.
I have solved the problem by putting another virtuel Ipaddress on the
Poptop server and then make the client connect to each individuel
Ipaddress, but it would really be nice if i could use the same.

Does anyone now where the problem is - on the poptop servers firewall
running iptables? or on the clients firewall (also running iptables)? . 
 
Maybe it is the protocol that doesn't allow it, but I am not sure?

Thanks a lot

Regards
Jan K

pptp and nat

[Lane Brooks]

I have a linux firewall/nat server that is working well using iptables.  I also
have a pptp client on this machine (ppp0).  The internal network is
192.169.0/24 on eth0 and the internet is on eth1.  NAT is working fine for
everything except the pptp connection.  The pptp connection works fine from
the firewall machine, but nothing on the internal network can talk through it.
 I used to have ipchains on kernal 2.2, and internal computers could talk fine
through the pptp connection, so I am thinking I need to add something more to
my iptable rules.  Any ideas or help?  My routing table is exactly the same as
that which used to work on ipchains with the older kernel, so I dont think it
is that.

Thanks
Lane Brooks

RE: pptp and nat

[Darrell Dieringer]

Hello,

Others are certain to have more experince with PPTP that I do.
However, if you believe it is a rules-related problem (as in some
packets needed by PPTP are getting blocked), make sure you have a
LOGging line before every DROP rule (or at the end of chains with a
default DROP policy).

There may very well be a PPTP helper module that you need, though.  I
don't know since I haven't tried to use PPTP through netfilter myself.
I only brought up the LOG/DROP scenario since you hadn't mentioned
checking the logs for problems.

D

> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Lane Brooks
> Sent: Monday, September 23, 2002 10:46 PM
> To: netfilter@lists.netfilter.org
> Subject: pptp and nat
>
>
>
> I have a linux firewall/nat server that is working well
> using iptables.  I also
> have a pptp client on this machine (ppp0).  The internal network is
> 192.169.0/24 on eth0 and the internet is on eth1.  NAT is
> working fine for
> everything except the pptp connection.  The pptp connection
> works fine from
> the firewall machine, but nothing on the internal network
> can talk through it.
>  I used to have ipchains on kernal 2.2, and internal
> computers could talk fine
> through the pptp connection, so I am thinking I need to add
> something more to
> my iptable rules.  Any ideas or help?  My routing table is
> exactly the same as
> that which used to work on ipchains with the older kernel,
> so I dont think it
> is that.
>
> Thanks
> Lane Brooks
>
>
>
>