OpenWrt Forum Archive

Topic: PPTPD help or howto.

The content of this topic has been archived on 5 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I have been attempting to, giving up, and reattempting to configure PPTP tunnels between my various locations with no success for months.

Following:
http://nuwiki.openwrt.org/oldwiki/PPTPDHowto

Leads me nowhere as the doc is outdated.

Searching for 'pptpd' shows lots of people with questions and problems, yet no answers.


Here are the steps I have taken:

1. Installed pptpd, kmod-crypto-core, kmod-mppe, kmod-ipt-nathelper.

2. /etc/pptpd.conf
debug
option /etc/ppp/options.pptpd
speed 115200
stimeout 10
#localip & remoteip are not needed, ip management is done by pppd

3. /etc/ppp/chap-secrets
#USERNAME  PROVIDER  PASSWORD  IPADDRESS
user  pptpd   pass        *

4. /etc/ppp/options.pptpd
debug
logfile /tmp/pptp-server.log
172.16.1.1:
auth
name "pptpd"
lcp-echo-failure 3
lcp-echo-interval 60
default-asyncmap
mtu 1482
mru 1482
nobsdcomp
nodeflate
#noproxyarp
#nomppc
mppe required,no40,no56,stateless
require-mschap-v2
refuse-chap
refuse-mschap
refuse-eap
refuse-pap
#ms-dns 172.16.1.1
#plugin radius.so
#radius-config-file /etc/radius.conf

5. /etc/init.d/pptpd enable && /etc/init.d/pptpd start

6. /usr/sbin/iptables -A INPUT -i eth0 -p 47 -j ACCEPT && /usr/sbin/iptables -A INPUT -i eth0 -p tcp --dport 1723 -j ACCEPT

7. No log appears in /tmp.

Current Status:
-----------------
Configs updated. I had to use LUCI to open up WAN to incoming connections. Not sure how to do this using iptables. Step #6 didnt do the trick. Also:
iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 1723 -j ACCEPT
iptables        -A input_rule      -i $WAN -p tcp --dport 1723 -j ACCEPT
iptables        -A output_rule             -p 47               -j ACCEPT
iptables        -A input_rule              -p 47               -j ACCEPT

From the howto doesn't help, as this is meant for firewall.user of WhiteRussian. $WAN is not defined in Kamikaze. Even after opening up WAN to incoming connections, when I try to connect remotely, the connection appears to start initialization, however, it disconnects the PPTPD router completely. Perhaps it is because the PPTPD router is running PPP and PPPoE to connect to the net.
------------------

Yes, sure, I'm probably doing 100 things wrong. However, I'm just going by the one, completely outdated document available for PPTPD and what others have done.

I think the whole community would appreciate it if someone updates the PPTPD HowTo, or post a working configuration with steps documented.

(Last edited by rainkid on 7 Jan 2010, 23:20)

my /etc/pptpd.conf:
debug
option /etc/ppp/options.pptpd
stimeout 10
localip 172.31.253.253
remoteip 172.31.253.100

my /etc/ppp/options.pptpd:
debug
logfile /var/log/pptp-server.log
auth
name "pptp-server"
lcp-echo-failure 3
lcp-echo-interval 60
default-asyncmap
mtu 1482
mru 1482
nobsdcomp
nodeflate
mppe required,no40,no56,stateless
require-mschap-v2
refuse-chap
refuse-mschap
refuse-eap
refuse-pap
ms-dns 172.31.253.253

my /etc/ppp/chap-secrets:
#USERNAME  PROVIDER  PASSWORD  IPADDRESS
user    pptp-server    pass    172.31.253.101

my /etc/ppp/ip-up.d/add-fw.sh:
# ppp0 is pppoe interface
if [ $IFNAME != ppp0 ] ; then
. /lib/firewall/uci_firewall.sh
  addif $IFNAME vpn
fi 

my /etc/config/firewall:
# [...]
config 'zone'
    option 'name' 'vpn'
    option 'network' 'vpn'
    option 'input' 'ACCEPT'
    option 'output' 'ACCEPT'
    option 'forward' 'REJECT'

config 'forwarding'
    option 'src' 'vpn'
    option 'dest' 'wan'

my /etc/firewall.user:
# [...]
iptables    -A input_wan -p tcp --dport 1723 -j ACCEPT
iptables    -A input_wan -p gre -j ACCEPT


It did work. Unfortunately I couldn't make it work with proxy arp, so I needed to set it to another subnet than my LAN, but routed traffic could reach LAN and go through WAN successfully.

I lost this config during some upgrade and haven't got it reset because I don't need it anymore, just kept backed up config that I send here. Used it on Kamikaze 7.09 r12985.

Did you get it to work at last...? I've just switched a router from DD-Wrt to OpenWrt, and am wondering how to setup a PPTP server.

Is this still valid...? http://nuwiki.openwrt.org/oldwiki/PPTPDHowto

I know OpenVPN is recommended more but I would like something that doesn't require additional software on Windows clients.

Is there an up-to-date PPTPD guide...?

loyukfai wrote:

Did you get it to work at last...? I've just switched a router from DD-Wrt to OpenWrt, and am wondering how to setup a PPTP server.

Is this still valid...? http://nuwiki.openwrt.org/oldwiki/PPTPDHowto

I know OpenVPN is recommended more but I would like something that doesn't require additional software on Windows clients.

cannot open this link
http://nuwiki.openwrt.org/oldwiki/PPTPDHowto

I have got pptpd to work using the first steps here, and additional info for the firewall settings from http://blog.netnerds.net/2011/02/openwr … ove-story/

The /etc/firewall.user file should have the following entries:

# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
iptables    -A input_wan -p tcp --dport 1723 -j ACCEPT
iptables    -A input_wan -p gre -j ACCEPT

iptables -A input_rule -i ppp+ -j ACCEPT
iptables -A forwarding_rule -i ppp+ -j ACCEPT
iptables -A forwarding_rule -o ppp+ -j ACCEPT
iptables -A output_rule -o ppp+ -j ACCEPT

Hi, in my case, "pppoe-wan" lies in "ppp+" and above config may open whole router to internet, so here is my solution:

#---PPTPD rule---
iptables    -A input_wan -p tcp --dport 1723 -j ACCEPT
iptables    -A input_wan -p gre -j ACCEPT

iptables -N ppp_vpn
iptables -A input_rule -i ppp+ -j ppp_vpn
iptables -A forwarding_rule -i ppp+ -j ppp_vpn
iptables -A forwarding_rule -o ppp+ -j ppp_vpn
iptables -A output_rule -o ppp+ -j ppp_vpn
iptables -A ppp_vpn -i pppoe-wan -j RETURN
iptables -A ppp_vpn -j ACCEPT

Rule applies only to ppp1, ppp2 and so on, except pppoe-wan.

(Last edited by loknar on 1 Dec 2011, 18:35)

The discussion might have continued from here.