Topic: port forward PPTP

[tariqf]

ok got it working all I needed to do was modprobe ip_conntrack_pptp and modprobe ip_nat_pptp. Thanks

[CharlesT]

The problem is in the five lines you added, you should add them as the two above and escape special charachters like \ and ! with a \, so something like this is more likely to work:

Code: [Select]

{
    my $pptpd_status = $pptpd{status} || 'disabled';

    my $target = ($pptpd_status eq 'enabled') ? "ACCEPT" : "denylog";

    $OUT =
    "    /sbin/iptables --replace gre-in 1 -d \\! \$OUTERNET -j denylog\n" .
    "    /sbin/iptables --replace gre-in 2 -j $target";
   
    $OUT .=
    "    /sbin/iptables --new-chain gre-in\n" .
    "    /sbin/iptables --append INPUT -p 47 -j gre-in\n" .
    "    /sbin/iptables --append INPUT -p 47 -j denylog\n" .
    "    /sbin/iptables --append gre-in -d \\! \$OUTERNET -j denylog\n" .
    "    /sbin/iptables --append gre-in -j denylog\n";
}
Not sure if you need the 4th line you added as it seems to duplicate the first one of the original template fragment already, but I am too unfamiliar with iptables syntax.

When I try to implement this and finish it with:

expand-template /etc/rc.d/init.d/masq
/etc/init.d/masq restart

I get :

Enabling IP masquerading: Bad argument `/sbin/iptables' 

[CharlieBrady]

ok got it working all I needed to do was modprobe ip_conntrack_pptp and modprobe ip_nat_pptp.

Where did those modules come from? They're not included in the SME server kernel rpm:

-bash-3.00$ rpm -ql kernel | egrep 'conntrack|nat'
/lib/modules/2.6.9-89.31.1.EL/kernel/drivers/net/natsemi.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/bridge/netfilter/ebt_dnat.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/bridge/netfilter/ebt_snat.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/bridge/netfilter/ebtable_nat.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ip_conntrack.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ip_conntrack_amanda.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ip_conntrack_ftp.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ip_conntrack_irc.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ip_conntrack_proto_sctp.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ip_conntrack_tftp.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ip_nat_amanda.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ip_nat_ftp.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ip_nat_irc.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ip_nat_snmp_basic.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ip_nat_tftp.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/ipt_conntrack.ko
/lib/modules/2.6.9-89.31.1.EL/kernel/net/ipv4/netfilter/iptable_nat.ko
-bash-3.00$
-bash-3.00$ locate ip_conntrack_pptp
-bash-3.00$

[tariqf]

Hi I think it's cos I'm using sme8, I should have mentioned that but we've been using sme8 for about a year now in production so I forgot about sme7!

I have /lib/modules/2.6.18-128.1.14.el5/kernel/net/ipv4/netfilter/ip_conntrack_pptp.ko

the brief notes I made to redo it in future on sme8 boxes is

* mkdir -p /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/
* vim /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/90adjustGRE and put:
{
my $pptpd_status = $pptpd{status} || 'disabled';

my $target = ($pptpd_status eq 'enabled') ? "ACCEPT" : "denylog";

$OUT =
" /sbin/iptables --replace gre-in 1 -d \\! \$OUTERNET -j denylog\n" .
" /sbin/iptables --replace gre-in 2 -j $target";

$OUT .=
" /sbin/iptables --new-chain gre-in\n" .
" /sbin/iptables --append INPUT -p 47 -j gre-in\n" .
" /sbin/iptables --append INPUT -p 47 -j denylog\n" .
" /sbin/iptables --append gre-in -d \\! \$OUTERNET -j denylog\n" .
" /sbin/iptables --append gre-in -j denylog\n";
}
* port forward 1723 to LAN machine which is hosting pptpd e.g. MS server
* then to activate now
modprobe ip_conntrack_pptp
modprobe ip_nat_pptp
*and add these to /etc/rc.local
modprobe ip_conntrack_pptp
modprobe ip_nat_pptp

[CharlieBrady]

Hi I think it's cos I'm using sme8,...

Yes - that makes it off-topic for this forum, and not relevant to this users problem.

[CharlesT]

Yes - that makes it off-topic for this forum, and not relevant to this users problem.

Yes, indeed. I am still using 7.5.1

[tariqf]

Ok did a bit of research and looks to me that gre forwarding will not be possible without a newer kernel above the highest version inside centos4 so it's either use non standard kernel or wait for sme8 release or at your own risk upgrade to sme8 beta

[CharlieBrady]

Ok did a bit of research and looks to me that gre forwarding will not be possible without a newer kernel above the highest version inside centos4 so it's either use non standard kernel or wait for sme8 release or at your own risk upgrade to sme8 beta

Please quote what research leads you to that conclusion. I don't know of any reason that GRE couldn't be forwarded unconditionally with the current kernel.

[tariqf]

 seems to come down to a kernel split at 2.6.10 to do with those modules so you would have a big job back porting any patch to get those modules pre 2.6.10 kernel source... Google it there's loads of people trying to do the same thing in centos 4.

[CharlieBrady]

No, I didn't ask for a summary of your findings - I want the exact URLs which suggested to you that it wasn't possible. I'm not talking about backporting of patches either - just the forwarding of GRE.

[CharlesT]

So, how do I finally get them going? 

[CharlesT]

So, how do I finally get them going? 

When I try to implement this and finish it with:

expand-template /etc/rc.d/init.d/masq

/etc/init.d/masq restart

, this error appears:

Shutting down IP masquerade and firewall rules:         Done!

Enabling IP masquerading: Bad argument `/sbin/iptables'

[CharlesT]

When I try to implement this and finish it with:

expand-template /etc/rc.d/init.d/masq

/etc/init.d/masq restart

, this error appears:

Shutting down IP masquerade and firewall rules:         Done!

Enabling IP masquerading: Bad argument `/sbin/iptables'

After a restart it works once or twice but then:

Feb 15 16:54:17 server pptpd[8490]: CTRL: Client xxx.xxx.xxx.xxx control connection started
Feb 15 16:54:17 server pptpd[8490]: CTRL: Starting call (launching pppd, opening GRE)
Feb 15 16:54:17 server pppd[8491]: Plugin radius.so loaded.
Feb 15 16:54:17 server pppd[8491]: RADIUS plugin initialized.
Feb 15 16:54:17 server pppd[8491]: pppd 2.4.4 started by root, uid 0
Feb 15 16:54:17 server kernel: divert: not allocating divert_blk for non-ethernet device ppp0
Feb 15 16:54:17 server pppd[8491]: Using interface ppp0
Feb 15 16:54:17 server pppd[8491]: Connect: ppp0 <--> /dev/pts/0
Feb 15 16:54:17 server udevd[1156]: udev done!
Feb 15 16:54:47 server pppd[8491]: LCP: timeout sending Config-Requests
Feb 15 16:54:47 server pptpd[8490]: CTRL: EOF or bad error reading ctrl packet length.
Feb 15 16:54:47 server pptpd[8490]: CTRL: couldn't read packet header (exit)
Feb 15 16:54:47 server pptpd[8490]: CTRL: CTRL read failed
Feb 15 16:54:47 server pppd[8491]: Modem hangup
Feb 15 16:54:47 server pppd[8491]: Connection terminated.
Feb 15 16:54:47 server pptpd[8490]: CTRL: Reaping child PPP[8491]
Feb 15 16:54:47 server kernel: divert: no divert_blk to free, ppp0 not ethernet
Feb 15 16:54:47 server pppd[8491]: Exit.
Feb 15 16:54:47 server pptpd[8490]: CTRL: Client xxx.xxx.xxx.xxx control connection finished
Feb 15 16:54:47 server udevd[1156]: udev done!
Feb 15 16:55:01 server su(pam_unix)[8529]: session opened for user qmailr by (uid=0)


So, what is wrong after a while?

[mmccarn]

In the past I used the SME PPTP server instead of the Windows PPTP server in this situation.

I created a single "remoteuser" account on the SME with permission to use PPTP.  All remote users then used that single username/password for remote access, but needed their windows username and password to access resources on the internal Windows server.

At the time (windows 2000 servers / SME 6.x), the connection process and the resulting VPN throughput both seemed faster than VPNs connecting directly to a Windows box.