|For an overview over all existing Virtual private network (VPN)-related articles in the OpenWrt wiki, please visit overview|
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.
|Packages Name||Size in Bytes||Description|
|kmod-gre||10832||Generic Routing Encapsulation support|
|kmod-mppe||5111||Kernel modules for Microsoft PPP compression/encryption|
|kmod-ppp||23177||Kernel modules for PPP support|
|kmod-pppoe||6989||Kernel module for PPPoE (PPP over Ethernet) support|
|kmod-pppox||2480||Kernel helper module for PPPoE and PPTP support|
|luci-proto-ppp||3622||Support for PPP/PPPoE/PPPoA/PPtP|
|ppp||104784|| This package contains the PPP (Point-to-Point Protocol) daemon.
|ppp-mod-pppoe||9128||This package contains a PPPoE (PPP over Ethernet) plugin for ppp.|
|ppp-mod-pptp||16083||This package contains a PPtP plugin for ppp.|
|kmod-nf-nathelper-extra||54232||This package contains a net filter modules for PPtP.|
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
This howto concentrates on configuring the client side running OpenWrt. There is a different guide to configure the pptp-server
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
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.
/etc/config/network file, replacing
server with the parameters given by your VPN provider.
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.
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 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
tc you configure one thing per invocation and you would write a shell script which is executed at every boot or at every ifup.
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.
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
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.
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.
|Minimum PPTP support||slhc ppp_generic ppp_async|
|Encryption or compression||sha1 arc4 ppp_mppe_mppc|
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:
|lcp-echo-failure n||keep-alive, maximum number of echo attempts before considering the link to be dead|
|lcp-echo-interval n||keep-alive, time between each echo attempt in seconds|
|idle n||terminated tunnel after n seconds of inactivity, set to 0 to disable|
|refuse-eap||refuse to authenticate using EAP, needed with some recent servers, try it if you see EAP responses in debug log|
|persist||do not exit after a connection is terminated; instead try to reopen the connection|
|mppe required,no40,no56||forces 128-bit encryption|
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.
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.
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.
Add this to properly specify the account and password in chap-secrets (see below).
Instruct pppd to load the generic options provided by the pptp package.
You need to add this line in case you use PPTP to access the Internet.
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:
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
|call name| obtain options from file /etc/ppp/peers/''name|
|updetach||wait until the connection is made and then detach process from terminal|
To stop the tunnel, kill the pppd process:
To test a tunnel and send debug output to the console, enter from the command prompt:
pppd call peername debug dump nodetach
|debug||display what is happening during negotation|
|dump||display the pppd options and where they came from|
|nodetach||do not detach the process from terminal once link is started|
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
. 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
and add the required networks through route add for the link in question.
Consider the example, where we have a peer defined in
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
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
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:
... Thu Jan 25 22:05:02 2018 daemon.debug pppd: Echo Request received. Thu Jan 25 22:05:02 2018 daemon.debug pppd: Sent control packet type is 6 'Echo-Reply' Thu Jan 25 22:05:02 2018 daemon.debug pppd: Echo Reply received. Thu Jan 25 22:06:02 2018 daemon.debug pppd: Echo Reply received. Thu Jan 25 22:07:02 2018 daemon.debug pppd: Echo Reply received. Thu Jan 25 22:07:23 2018 daemon.debug pppd: 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: Unsupported protocol 0xad received Thu Jan 25 22:07:23 2018 daemon.debug pppd: 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: 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: Unsupported protocol 0x58c1 received ... Thu Jan 25 22:07:23 2018 daemon.warn pppd: Protocol-Reject for unsupported protocol 0x???? Thu Jan 25 22:07:23 2018 daemon.warn pppd: Protocol-Reject for unsupported protocol 0x???? Thu Jan 25 22:07:23 2018 daemon.warn pppd: Protocol-Reject for unsupported protocol 0x???? Thu Jan 25 22:07:23 2018 daemon.warn pppd: Protocol-Reject for unsupported protocol 0x???? Thu Jan 25 22:07:23 2018 daemon.warn pppd: Protocol-Reject for unsupported protocol 0x???? ...
Add the following lines to /etc/ppp/options.pptp and reconnect and retry…
These example scripts show how to configure iptables rules when a tunnel comes up or goes down.
Several things to note about the scripts:
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
Note that this will not work on White Russian RC6 (see http://forum.openwrt.org/viewtopic.php?pid=40355)
# 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
# ip route add default dev vlan1 table table1 # ip route list table table1 default via 192.168.0.1 dev vlan1
# 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
iptables --append POSTROUTING --table mangle --protocol tcp --dport 80 --jump ROUTE --oif ppp0 --continue