This is a very basic guide about how to connect a pptp-client running on an OpenWrt box with a remote pptp-server over a PPTP tunnel.

IF YOU ARE HAVING PROBLEMS CONNECTING WITH ONE OF YOUR DEVICES RUNNING PPTP AND SUSPECT THAT OpenWrt IS BLOCKING THE CONNECTION (and yes, by default, it does), YOU WANT TO READ PPTP NAT Traversal.

You should read this overview first.

We assume this is preconfigured. This howto concentrates on configuring the client side running OpenWrt.

Go to LuCI → System → Software.

Click on Update lists

Download and install the following packages:

ppp-mod-pptp
kmod-nf-nathelper-extra
luci-proto-ppp

If you are using OpenWrt 18.06, include

kmod-ipt-raw

opkg

opkg update
opkg install ppp-mod-pptp kmod-nf-nathelper-extra

If LuCI support is desired, additionally install the protocol package:

opkg install luci-proto-ppp

(Added August 2018)

Go to LuCI → Network → Interfaces. Click on Add new interface button.

• Specify a name for this interface. eg. VPN
• Change the Protocol to PPtP

Press Submit button.

• Enter VPN server URL or IP address
• Enter username
• Enter password

Press Save & Apply button.

Go to LuCI → Network → Firewall

Scroll down to Zones and press the Add button to create a new zone.

For LEDE 17/OpenWrt 18, use the following settings (Required changes to default values are highlighted bold):

• Name: eg. VPN_FW
• Input: reject
• Output: accept
• Forward: reject
• Masquerading: ticked
• MSS clamping: ticked
• Covered networks: Choose only the VPN network interface created earlier (eg. VPN)

Press Save & Apply button.

Go to LuCI → Network → Firewall

Scroll down to Zones and edit the lan zone (usually at top of the list of zones).

Go to 'Inter-Zone Forwarding'.

Change 'Allow forward to destination zones' from wan to the newly created VPN firewall zone (eg. VPN_FW)

Press Save & Apply button.

The Zones should look like this image:

Some VPN providers may require you to specify extra PPTP parameters. They can be added to this file:

/etc/ppp/options.pptp

If you are using OpenWrt 18.06, install this package:

kmod-ipt-raw

For OpenWrt 18.06, append the following to /etc/firewall.user file.

iptables -t raw -A OUTPUT -p tcp -m tcp --dport 1723 -j CT --helper pptp

After completing all changes, power cycle the router for it to connect to the VPN provider.

Go to LuCI → Network → Interfaces

Uptime and IPv4 address provided by VPN provider should be visible for the VPN interface if it is working.

Visit myip.com or whatsmyipaddress.com to verify you are connected to the desired VPN endpoint.

At time of writing, I've observed one issue whereby if the router loses connection, the VPN cannot be re-established as it may not be able to resolve VPN server's URL because of what looks like DNS issues. Temporary workarounds include power cycling the router, or restarting both wan and VPN interfaces.

This howto concentrates on configuring the client side running OpenWrt. There is a different guide to configure the pptp-server pptpd: basic

(Retired instructions for very early versions of OpenWrt)

NOTE: As of writing this guide, the pptp client used in OpenWrt is version 1.7.1-3, same version used by many Linux flavors so if the configuration with help of LuCI described bellow does not work for you, it's possible to configure it in the original intended Linux way, adapting instructions. In this case, the tunnel will work normally, but the interface will not show in LuCI, which is perfectly normal.

The configuration described here is all done by adding a VPN interface in LuCI. This automatically makes the configuration UCI compliant and the VPN interface will show up in your /etc/config/network file.

Access your router from any web browser and change to the advanced menu clicking in Administration. Chose ⇒ Network ⇒ Interfaces and give your VPN interface a name in the 'Add entry' field (just vpn will do). Chose PPTP as protocol and LuCI will show the main options for PPTP connection as fields.

Now Create / Assign the firewall zone (usually the name given to the VPN) and fill 'PPTP-Server' (with your server's IP address) and 'Username' and 'Password' all three must be obtained from your VPN provider.

Now you must decide if you'll leave the “Let pppd replace the current default route' enable (default) or not and for that you must understand how it works. Leaving it enable will not create a new default route in your router. Actually PPTP client handles this only after a successful connection. So when the tunnel goes up, the route is defaulted to the VPN and is defaulted back to the original route if the tunnel collapses. If you want all your traffic going through the tunnel just leave it. If you don't, it's better to leave it checked for testing purposes and uncheck it after being sure everything is ok.

The above may be or may be not all you need. It will depend on your VPN provider's requirements. You'll have to enable the tunnel and check the log to see if it goes up and stays that way. If you already know what you need, add the corresponding options using the 'Additional Field' menu. Keep-Alive, for example, is advisable and supported by many VPN providers, but just for you to know, the number you put in this field is actually the number of attempts that will be made to reconnect if the tunnel brakes and not the interval between keep-alive packages. Another interesting field is 'Additional pptp options' where everything not listed but supported goes. Common parameters are mppe required and stateless. They must be separated by commas without spaces after the comma.

Now you must click Save & Apply to see if your VPN is working. If everything went fine, it will be “Active' in LuCI's Network / Interfaces menu, and your IP VPN address, the address of your end of the tunnel, will be in the “Addresses' column. Also check your routing table in Status / Routes. The default route is always the one with 0.0.0.0 in 'Target' and 'IPv4 Network' columns. Your VPN gateway will also appear here. This address is your provider's end of the tunnel so it will be different of the one showing in Interfaces menu, but it must be in the same subnet.

Edit /etc/config/network file, replacing vpnusername, vpnpassword and server with the parameters given by your VPN provider.

The buffering option enables ('1') or disables ('0') buffering and reordering of packets. It's optional and the default is already '1' (enabled). If you don't know what buffering and reordering mean either don't use it or leave it enabled. Disabling it will most likely slow your VPN to a crawl!

All other options are UCI standard and information about them can be found in /etc/config/network. In the tested setup the physical interface ifname option automatically defaults to pptp-vpn, no matter how you name it, but feel free to test.

After restarting network service or rebooting your router, and if your VPN handshake and authentication went well, the pptp-vpn interface will show up as enabled in LuCI. You can also check it using CLI with ifconfig. From your router (not your computer), try to ping some wan address to see if everything is fine and skip to the Routing part bellow.

===== Firewall =====

=== Old LuCI instructions (to be removed later) === Go to Network / Firewall / Traffic Control and use “Add entry' to put a 'Source' lan - 'Destination' vpn (the name you gave to it) to allow traffic form your LAN to go to the VPN. Then verify your Network / Firewall settings. Your VPN will be now in the 'Zones' area, but with everything set as 'reject'. Just change 'OUTPUT' to accept and check the 'MASQ' box to enable NAT for the traffic going through the VPN. If you made your VPN your default route as suggested above, just test your settings using any 'my IP' website from a computer browser that uses your router as gateway. If everything works, your IP will be the same of your tunnel endpoint instead of the usual one. If your needs are more complex than route it all through the tunnel, you can now revert your default route to what it was and do some routing work.

: this is unfinished and not yet fully tested

routing

Routing is the process of selecting paths in a network along which to send network traffic. There are a couple of Routing protocols to make this happen more or less automatically. For this, we are going to use static routing. The routing is handled by a component of the Kernel and can be configured by the user space tool ip which is contained in the package iproute2. Analogue to iptables or tc you configure one thing per invocation and you would write a shell script which is executed at every boot or at every ifup.

But since OpenWrt offers uci, we will do the configuration with it. Stuff related to routing is configured in /etc/config/network.

You can of course do this without UCI, read on how:

Routing through your tunnel can be as simple as 'send-it-all', the default if you use LuCI to create the interface, or as complex as you want. Advanced routing is not the purpose of this howto, but if all you want is to do simple source based routing, that is, route traffic through your VPN based in the hosts IP addresses, here is how.

First you need to install the ip package (formerly iproute2). It allows you, among other things, to enable more than one routing table and to create rules to apply them, without any additional firewall rules. For this to work, host's IP must be always the same. You can configure it manually in the host or designate one in your DHCP using it's MAC address or host name.

Now use opkg or LuCI to install ip and create a new routing table. To do that edit /etc/iproute2/rt_tables. It should look like this:

#
# reserved values
#
255  local
254  main
253  default
10   vpn
0    unspec
#
# local
#
#1   inr.ruhelp

Only the line 10 vpn was added and both, the number and the name are for you to chose, just don't mess with the tables already there unless you really know what you're doing. Save the file and add one ore more host rules in terminal. Supposing you want to route two hosts with addresses 192.168.1.20 and 192.168.1.30 (could be any addresses) use

ip rule add from 192.168.1.20 table vpn
ip rule add from 192.168.1.30 table vpn

Now add a default route to your new table and flush the route cache using

ip route add default via <ip_of_the_far_end_of_your_tunnel> dev <pptp_iface_name> table vpn
ip route flush cache

Now all the traffic from hosts using the alternate routing table will go through the VPN. You can traceroute from a VPN routed host to check it. The table you created will survive reboots (it's written), but the route and rules won't so you must add them in some way. Search documentation for the proper way to do that or wait until this part of the howto is finished.

You can do a lot using only ip package routing manipulation. For even more complex routing rules, it can also be coupled with iptables marking rules: iptables marks the packets using PREROUTING and mangle table, and ip routes them according to the marking. Just google for information about it.

If the interface is not up you must check your router's log (in LuCi or using the command logread in CLI) to see what went wrong and troubleshoot accordingly.

Setting up PPTP client with OpenWrt 18.06 also requires the following (Added August 2018):

opkg install kmod-ipt-raw

Append the following to /etc/firewall.user

iptables -t raw -A OUTPUT -p tcp -m tcp --dport 1723 -j CT --helper pptp

Retrieved from: https://bugs.openwrt.org/index.php?do=details&task_id=1646

PPTP failing with OpenWrt 18.06.1 on BT Home Hub 5A: https://bugs.openwrt.org/index.php?do=details&task_id=1809

• The PPTP Client Project Homepage: http://pptpclient.sourceforge.net/
• The IProute2 Project Homepage: http://www.policyrouting.org

How to configure your router as a PPTP client to connect to a PPTP server such as MS VPN.

If your service provider needs you to use PPTP for internet access, see the simpler obsolete.faq answer How do I configure PPTP for internet access?

Install the pptp, kmod-mppe and kmod-crypto package:

ipkg install pptp kmod-mppe kmod-crypto

While the pptp package is installed already if you are using the White Russian RC5 pptp build of OpenWrt, you still need to install kmod-mppe and kmod-crypto for encryption and compression support.

At minimum, add the following lines to /etc/modules:

slhc
ppp_generic
ppp_async

If you need to use encryption or compression, add the following lines to /etc/modules:

ppp_mppe_mppc
arc4
sha1

then either reboot or load the modules this once:

insmod slhc
insmod ppp_generic
insmod ppp_async
insmod ppp_mppe_mppc
insmod arc4
insmod sha1

See ticket #412.

This file is provided by the pptp package, and works as-is. It sets the options for all tunnels initiated from your router.

There's no need to change the file now, but there are several options you can change later if you like, see the manual page for pppd:

Make the /etc/ppp/peers directory and create a file named after the peer:

mkdir -p /etc/ppp/peers
cd /etc/ppp/peers
touch peer_name
chmod 600 peer_name

Substitute peer_name above with a descriptive one for the link you are trying to establish.

The file created defines the link with the VPN server and there are a few necessary options. Edit and add the following to your peer-file:

pty "pptp hostnameOrIp --nolaunchpppd"

Here we instruct pppd to launch pptp to communicate with the VPN server. Substitute hostnameOrIp with the DNS hostname or IP-address of the VPN server you want to connect to.

mppe required,stateless

Require that the connection be encrypted, using stateless encryption. Most tunnel servers require encryption, so try this first, and if you get a warning suggesting that the server doesn't want MPPE, then remove this line.

name DOMAIN\\Username

Define the username for the VPN-connection (the password is stored in chap-secrets, see below). Substitute DOMAIN with the Windows Domain your user belongs to or remove DOMAIN\\ if none is required. Also substitute Username above with the user you want to use to connect with the VPN server.

remotename peer_name

Add this to properly specify the account and password in chap-secrets (see below).

file /etc/ppp/options.pptp

Instruct pppd to load the generic options provided by the pptp package.

replacedefaultroute

You need to add this line in case you use PPTP to access the Internet.

ipparam name

This is optional. Substitute name with the one chosen for the peer-file. This is used as a parameter to the ip-up and ip-down script executed upon connection and tear down of the link. Hence, you can write that script to behave differently depending on which peer we are connecting to or disconnecting from.

Any other pppd/pptp options not considered generic (usable by all PPTP connections) should go below the above options in the peer-file. To enable on demand “dialling” for example; add persist, demand and idle 3600, to make the router disconnect after one hour of inactivity and bring it back up again once the link is required.

The /etc/ppp/chap-secrets file contains a list of usernames and passwords for use by pppd.

For the bin and pptp builds of OpenWrt, the file will start out being a symbolic link to a template in /rom, so remove the link, copy the template, and make sure it is chmod 600.

Add the following to the /etc/ppp/chap-secrets file:

DOMAIN\\Username peer_name Password *

There are four fields separated by spaces:

• substitute DOMAIN\\Username. It is important that this match the name in the /etc/ppp/peers/peer_name file above. So, if no DOMAIN\\ was used, do not enter one here either.

• substitute peer_name with whatever you used for remotename in the /etc/ppp/peers/peer_name file.

• substitute Password with the password given to you by the owner of the PPTP server. If the password contains blanks or special characters, enclose it in double-quotes, “like this”.

• the asterisk tells pppd that this tunnel may use any IP address. Normally the PPTP server determines the address.

Anyway, in many cases this is still not enough to get PPTP-internet work. Due to critical bug in pppd, it create route to your pptp-server through self-established interface (ppp0). This way it gets not route to the VPN server (loop) and breaks the connection in some minutes. To prevent this, you have to delete this route upon the connection (see ip-up). If your VPN-server lies behind your default gateway (not in your subnet), you also MUST add additional route to VPN-server. This case quite common and very few routers have an ability to define a route to VPN-server.

So for this mentioned to work, you need to add following lines to your /etc/ppp/ip-up:

DG=10.188.0.17 #this is your default gateway
/sbin/route del -host $5 dev ppp0 #we delete "stupid" pppd route
/sbin/route add -host $5 gw $DG dev vlan1 #we add route to vpn-server in case you need it

The pppd command is used to start a tunnel. The syntax is pppd call peername, where peername is one of the peer files in /etc/ppp/peers:

pppd call peername updetach

To stop the tunnel, kill the pppd process:

killall pppd

To test a tunnel and send debug output to the console, enter from the command prompt:

pppd call peername debug dump nodetach

The output of a successful connection may look as follows:

root@ap1:~# pppd call peername debug nodetach
using channel 2
Using interface ppp1
Connect: ppp1  /dev/pts/2
sent [LCP ConfReq id=0x1   ]
rcvd [LCP ConfReq id=0x0         ]
sent [LCP ConfRej id=0x0     ]
rcvd [LCP ConfAck id=0x1   ]
rcvd [LCP ConfReq id=0x1    ]
sent [LCP ConfNak id=0x1 ]
rcvd [LCP ConfReq id=0x2    ]
sent [LCP ConfAck id=0x2    ]
sent [LCP EchoReq id=0x0 magic=0xeae657f6]
rcvd [CHAP Challenge id=0x0 , name = "VPNSERVER"]
sent [CHAP Response id=0x0 , name = "DOMAIN\\Username"]
rcvd [LCP EchoRep id=0x0 magic=0x71251209]
rcvd [CHAP Success id=0x0 "S=09F4D2BD2B89C41308C4853687110838FB1D1DE3"]
sent [CCP ConfReq id=0x1 ]
sent [IPCP ConfReq id=0x1  ]
rcvd [CCP ConfReq id=0x4 ]
sent [CCP ConfNak id=0x4 ]
rcvd [IPCP ConfReq id=0x5 ]
sent [IPCP ConfAck id=0x5 ]
rcvd [CCP ConfNak id=0x1 ]
sent [CCP ConfReq id=0x2 ]
rcvd [IPCP ConfRej id=0x1 ]
sent [IPCP ConfReq id=0x2 ]
rcvd [CCP ConfReq id=0x6 ]
sent [CCP ConfAck id=0x6 ]
rcvd [CCP ConfAck id=0x2 ]
MPPC/MPPE 128-bit stateful compression enabled
rcvd [IPCP ConfNak id=0x2 ]
sent [IPCP ConfReq id=0x3 ]
rcvd [IPCP ConfAck id=0x3 ]
local IP address 192.168.0.2
remote IP address 192.168.0.1
Script /etc/ppp/ip-up started (pid 872)
Script /etc/ppp/ip-up finished (pid 872), status = 0x0

If problems arise, from here search the pppd and pptp documentation and forums, since there is already tons of information available.

The file /etc/ppp/ip-up is a shell script which is executed when the tunnel is started. It is nice to be able to configure iptables or routing once the tunnel is up and remove that configuration once the tunnel is taken down.

note: In Kamikaze both ip-up and ip-down are provided. Instead put your scripts in /etc/ppp/ip-up.d and /etc/ppp/ip-down.d respectfully. Make sure they are marked executable.

Create the files and set execute permission if they do not already exist:

touch /etc/ppp/ip-up
chmod 755 /etc/ppp/ip-up
touch /etc/ppp/ip-down
chmod 755 /etc/ppp/ip-down

Edit the files and add the following preamble. #!/bin/sh is required as the first line, to enable execution of the script. The other text, is good as a reminder of the parameters used when pppd calls these scripts.

#!/bin/sh
# parameters
# $1 the interface name used by pppd (e.g. ppp3)
# $2 the tty device name
# $3 the tty device speed
# $4 the local IP address for the interface
# $5 the remote IP address
# $6 the parameter specified by the 'ipparam' option to pppd

It is the sixth parameter which is defined by ipparam in the peer-file above. It is a useful parameter to distinguish the scripts behaviour depending on which tunnel or PPP connection we are bringing up or down.

A generic structure for the ip-up and ip-down script shall check the $6 parameter to match with an appropriate code section through a case branch as follows:

case "$6" in
 peer-name1)
  
  ;;
 peer-name2)
  
  ;;
  *)
esac
exit 0

Substitute peer-name1, with the value given to ipparam above in the peer-file. Since we are configuring the first VPN link, you probably do not peer-name2, it is included here as a template when adding another link. For now, remove it. Also, remove >, these will be replaced with actual commands below.

When you use commands in these scripts, be sure to either use their full path or add `/usr/sbin` and `/sbin` to the PATH first. pppd intentionally restricts the PATH available to the scripts for security reasons.

To update your firewall rules when the tunnel is brought up or torn down, we need to add a few commands to the ip-up and ip-down scripts created above. Also note, all these commands you can add to something like /etc/init.d/S70routes (create it). Though you have no ppp0 interface upon S70routes execution, it will work nevetherless. In this case you also do not need to remove these rules in ip-down. You can just add these lines to your S70routes:

iptables -A FORWARD -t filter -i br0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -t filter -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.168.0/24 -d 0/0 -j MASQUERADE

Where 192.168.168.0/24 is your internal subnet (LAN). This, though not delicate, works for common case.

To allow outgoing communication with the tunnel add the following to ip-up:

iptables -A forwarding_rule -o $1 -j ACCEPT

Likewise, if we want to allow incoming traffic from the tunnel add to ip-up:

iptables -A forwarding_rule -i $1 -j ACCEPT

To enable masquerading (NAT) to the network beyond the tunnel add to ip-up:

iptables -t nat -A postrouting_rule -o $1 -j MASQUERADE

Masquerading does not require

iptables -A forwarding_rule -i $1 -j ACCEPT

as described above. It is only required if the other end of the tunnel will send traffic to our network. Incoming traffic requires the other end of the tunnel to know about our local network topology either through static routes or by other means (routing protocols such as RIP and OSPF).

When adding (inserting) into the iptables ruleset, we need a corresponding removal in ip-down when the tunnel is taken down. Simply add the same command as above into ip-down substituting -A with -D:

iptables -D forwarding_rule -o $1 -j ACCEPT
iptables -D forwarding_rule -i $1 -j ACCEPT
iptables -t nat -D postrouting_rule -o $1 -j MASQUERADE

This howto assumes you will not use the tunnel as a default route. Instead each relevant network will be added to the static routing table of the OpenWrt router. Other means, such as routing protocols could likely be used. Please update this Wiki if you have any good ideas regarding this.

To add a network to the routing table for the tunnel we again go to the ip-up script and add the route. The general syntax is:

route add -net  netmask  $1

Subsititue ' with one you want to reach through the VPN-link. Also, ' should be replaced with the appropriate value.

For example, to make network 192.168.0.0 with a netmask of 255.255.255.0 reachable, add:

route add -net 192.168.0.0 netmask 255.255.255.0 $1

Again, a corresponding route delete command should be added to the ip-down script. To delete a network from the routing table, replace add with del and also remove $1 at the end of the command, since it is not needed.

To continue the example above, deleting the route added by ip-up for the 192.168.0.0/255.255.255.0 network:

route del -net 192.168.0.0 netmask 255.255.255.0

If entered in ip-down for the appropriate link, the 192.168.0.0/24-network will be removed from the static routing table when the link is taken down.

(It should be possible to direct all packets into the tunnel, if that's what you want. But be careful; if you direct the tunnel's packets as well, you'll end up with a routing loop and nothing will work. To avoid this, add a static route for your tunnel server using the network interface. Then add a default route that directs everything else to the tunnel network interface. The static host route takes priority over the default route, avoiding the loop. – JamesCameron, PPTP Linux maintainer.)

To connect instantly as the router boots, add the pppd call peername command to a start script in

/etc/init.d/

. If a connection cannot be made with the VPN-server as the WAN link may not be active yet, either experiment with a sleep prior to calling pppd or come up with a better solution (see on demand dial below as well).

pppd supports bringing a link up when it is needed. This requires that the static routes are already in place, prior to establishing the connection. Hence, it wont help adding them to ip-up. Instead these routes need to be entered in the start script.

Edit the start script in

/etc/init.d/

and add the required networks through route add for the link in question.

Consider the example, where we have a peer defined in

/etc/ppp/peers

called peer1. Then, when establishing the link in demand dial mode, we sleep for a bit, then add the static routes in question.

pppd call peer1 persist demand idle 3600
sleep 2
route add -net 192.168.0.0 netmask 255.255.255.0 ppp0

Here we can not use a parameter for the link (normally $1 in the ip-up and ip-down scripts). We have to make sure the routes are entered for the correct link, since we are in a start script we can be quite certain no other ppp-links have been brought up. Type ifconfig in a console to ensure that the correct interface is used. When using PPPoE it is likely a ppp0 interface already exists. Then, the pppd call command will bring up the next one, ppp1 in this case. Hence, update the start script to reflect the correct interface name.

Once an IP packet is sent to the router destined for the VPN ppp interface, the link is brought up. After 3600 (the idle option above) seconds of inactivity, the link is brought down anew and it will revert to the behaviour of waiting for a packet to arrive destined for the VPN link.

If you want the other end of the VPN-connection to be able to route packets back to the local (OpenWrt) network you will have to add the appropriate static routes to the VPN-server or use a better solution such as a routing protocol.

To add static routes to a pppd server, use the ip-up and ip-down scripts on the server.

In Windows, you can define static routes for a VPN connection by administering the VPN-user in question. Choose the Dial-in tab and tick the checkbox next to Apply Static Routes. Click the Static Routes … button to add the necessary routes for traffic to flow in the opposite direction.

The OSPF, RIP and other routing protocols are provided by Quagga. The OSPF and RIP protocols are commonly implemented and also by Microsoft Windows®. The routing protocol can be made responsible to handle the routing table updates when a pptp link is brought up or taken down. Please see the relevant documentation for Quagga or other routing daemons you may need to use.

if you cannot connect, and you get some error like:

rcvd [CCP ConfReq id=0x1 ]
sent [CCP ConfNak id=0x1 ]
rcvd [LCP TermReq id=0x3 "MPPE required but peer negotiation failed"]
LCP terminated by peer (MPPE required but peer negotiation failed)

you have to add a line in the /etc/ppp/options.pptp

mppe required,no40,no56,stateless

if you get an error like this:

Received bad configure-ack:  02 06 00 00 00 00 05 06 92 64 55 28

you propably stumbled into LCP ConfNak id=0x1 <mru 1500> To fix this you need to edit

/lib/network/pptp.sh

Find the lines at the end of the file, which set the mtu and delete them.

Unsupported protocol 0x???? received / Protocol-Reject for unsupported protocol 0x????

This is related to (MPPC) compression which is used by “Routing and RAS” on windows based VPN servers.

if you get errors like this:

• Protocol-Reject for unsupported protocol 0x????
• Unsupported protocol 0x???? received

...
Thu Jan 25 22:05:02 2018 daemon.debug pppd[14687]: Echo Request received.
Thu Jan 25 22:05:02 2018 daemon.debug pppd[14687]: Sent control packet type is 6 'Echo-Reply'
Thu Jan 25 22:05:02 2018 daemon.debug pppd[14687]: Echo Reply received.
Thu Jan 25 22:06:02 2018 daemon.debug pppd[14687]: Echo Reply received.
Thu Jan 25 22:07:02 2018 daemon.debug pppd[14687]: Echo Reply received.
Thu Jan 25 22:07:23 2018 daemon.debug pppd[14668]: rcvd [proto=0xad] dc 2f 51 d3 90 6a ac 6d ce 17 ef 62 35 fb 91 24 20 9e 90 b0 72 75 6c 64 6e 6e ec 10 07 ff 73 6a ...
Thu Jan 25 22:07:23 2018 daemon.warn pppd[14668]: Unsupported protocol 0xad received
Thu Jan 25 22:07:23 2018 daemon.debug pppd[14668]: sent [LCP ProtRej id=0x2 00 ad dc 2f 51 d3 90 6a ac 6d ce 17 ef 62 35 fb 91 24 20 9e 90 b0 72 75 6c 64 6e 6e ec 10 07 ff ...]
Thu Jan 25 22:07:23 2018 daemon.debug pppd[14668]: rcvd [proto=0x58c1] 05 a9 35 62 0d 0d 85 8b 71 ab 6b df 50 40 54 c9 a6 1d 7e d0 e6 82 42 46 d6 40 74 60 10 c6 3a 2c ...
Thu Jan 25 22:07:23 2018 daemon.warn pppd[14668]: Unsupported protocol 0x58c1 received
...
Thu Jan 25 22:07:23 2018 daemon.warn pppd[14668]: Protocol-Reject for unsupported protocol 0x????
Thu Jan 25 22:07:23 2018 daemon.warn pppd[14668]: Protocol-Reject for unsupported protocol 0x????
Thu Jan 25 22:07:23 2018 daemon.warn pppd[14668]: Protocol-Reject for unsupported protocol 0x????
Thu Jan 25 22:07:23 2018 daemon.warn pppd[14668]: Protocol-Reject for unsupported protocol 0x????
Thu Jan 25 22:07:23 2018 daemon.warn pppd[14668]: Protocol-Reject for unsupported protocol 0x????
...

Add the following lines to /etc/ppp/options.pptp and reconnect and retry…

nopcomp
noaccomp

These example scripts show how to configure iptables rules when a tunnel comes up or goes down.

Several things to note about the scripts:

1. the iptables and route commands were entered in full path format, if this isn't done the scripts silently fail with a 127 exit code reported by pppd,
2. logging is done to to `/var/log/ppp` using echo,
3. incoming connections aren't enabled, add iptables rules if you need them,
4. change the 10.0.0.0/8 remote subnet according to your needs.

Improvements are welcome.

#!/bin/sh
# parameters
# $1 the interface name used by pppd (e.g. ppp3)
# $2 the tty device name
# $3 the tty device speed
# $4 the local IP address for the interface
# $5 the remote IP address
# $6 the parameter specified by the 'ipparam' option to pppd

logfile=/var/log/ppp
echo "`date` $0 $1 $2 $3 $4 $5 $6" >> $logfile

case "$6" in
 peer-name1)
  A="/usr/sbin/iptables -t filter -I FORWARD -o $1 -j ACCEPT"
  B="/usr/sbin/iptables -t nat -A POSTROUTING -o $1 -j MASQUERADE"
  C="/sbin/route add -net 10.0.0.0 netmask 255.0.0.0 $1"
  $A
  echo " $? $A" >> $logfile
  $B
  echo " $? $B" >> $logfile
  $C
  echo " $? $C" >> $logfile
  ;;
  *)
esac
exit 0

#!/bin/sh
# parameters
# $1 the interface name used by pppd (e.g. ppp3)
# $2 the tty device name
# $3 the tty device speed
# $4 the local IP address for the interface
# $5 the remote IP address
# $6 the parameter specified by the 'ipparam' option to pppd

logfile=/var/log/ppp
echo "`date` $0 $1 $2 $3 $4 $5 $6" >> $logfile

case "$6" in
 peer-name1)
   A="/usr/sbin/iptables -t filter -D FORWARD -o $1 -j ACCEPT"
   B="/usr/sbin/iptables -t nat -D POSTROUTING -o $1 -j MASQUERADE"
   C="/sbin/route del -net 10.0.0.0 netmask 255.0.0.0 $1"
   $A
   echo " $? $A" >> $logfile
   $B
   echo " $? $B" >> $logfile
   $C
   echo " $? $C" >> $logfile
   ;;
  *)
esac
exit 0

How can I route only certain ports through the tunnel, and use my regular WAN interface for the rest of my traffic? – BjörnLindström

• use prerouting packet marking and policy routing, according to the Linux Advanced Routing & Traffic Control HOWTO, for example:

Note that this will not work on White Russian RC6 (see http://forum.openwrt.org/viewtopic.php?pid=40355)

• create a new routing table and add a rule to use it for packets marked with a 1:

# mkdir /etc/iproute2
# echo 201 table1 >> /etc/iproute2/rt_tables
# ip rule add fwmark 1 table table1
# ip rule ls
0:  from all lookup local
32764:  from all fwmark        1 lookup table1
32766:  from all lookup main
32767:  from all lookup default

• set routes on the new table (here just a default route, probably should copy other entries from main routing table):

# ip route add default dev vlan1 table table1
# ip route list table table1
default via 192.168.0.1 dev vlan1

• Add netfilter rules to mark packets (here on TCP 80):

# iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark 1
# iptables -t mangle -L PREROUTING -v
Chain PREROUTING (policy ACCEPT 5543K packets, 3265M bytes)
pkts bytes target     prot opt in     out     source               destination
   20  3924 MARK       tcp  --  any    any     anywhere             anywhere            tcp dpt:80 MARK set 0x1

References:

• http://lartc.org/howto/lartc.netfilter.html
• http://forum.openwrt.org/viewtopic.php?pid=40355

• the iptables ROUTE target extension can also do this, but it is not in the OpenWrt kernel. It isn't in any of the kmod-ipt-* packages. The module would be called ipt_ROUTE. Using this method, to redirect port 80 to exit via a PPTP tunnel interface:

iptables --append POSTROUTING --table mangle --protocol tcp --dport 80 --jump ROUTE --oif ppp0 --continue

References:

• http://www.netfilter.org/projects/patch-o-matic/pom-extra.html