Go to LuCI → System → Software. Click on Update lists.
Download and install the packages:
Go to LuCI → Network → Interfaces. Click on Add new interface button.
Press Submit button.
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):
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 (e.g. 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
For OpenWrt 18.06, install the package
kmod-ipt-raw, go to LuCI → Network → Firewall → Custom rules and append the following:
iptables -t raw -A OUTPUT -p tcp \ -m comment --comment "!fw3: PPTP connection tracking" \ -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.
SERVER_NAME_OR_IP_ADDRESS with the parameters given by your VPN provider.
# Install packages opkg update opkg install ppp-mod-pptp # Configure firewall uci del_list firewall.@zone.network="pptp" uci add_list firewall.@zone.network="pptp" uci commit firewall service firewall restart # OpenWrt 18.06 opkg install kmod-ipt-raw cat << EOF > /etc/firewall.user iptables -t raw -A OUTPUT -p tcp \ -m comment --comment "!fw3: PPTP connection tracking" \ -m tcp --dport 1723 -j CT --helper pptp EOF uci commit firewall service firewall restart # Configure network uci -q delete network.pptp uci set network.pptp="interface" uci set network.pptp.proto="pptp" uci set network.pptp.username="VPN_USERNAME" uci set network.pptp.password="VPN_PASSWORD" uci set network.pptp.server="SERVER_NAME_OR_IP_ADDRESS" uci commit network service network restart
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?
ipkg install pptp kmod-mppe kmod-crypto
pptp package is installed already if you are using the White Russian RC5
pptp build of OpenWrt, you still need to install
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
slhc ppp_generic ppp_async
If you need to use encryption or compression, add the following lines to
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.
|kmod-gre||Generic Routing Encapsulation support|
|kmod-mppe||Kernel modules for Microsoft PPP compression/encryption|
|kmod-ppp||Kernel modules for PPP support|
|kmod-pppoe||Kernel module for PPPoE (PPP over Ethernet) support|
|kmod-pppox||Kernel helper module for PPPoE and PPTP support|
|kmod-pptp|| PPTP support
|luci-proto-ppp||Support for PPP/PPPoE/PPPoA/PPTP|
|ppp|| This package contains the PPP (Point-to-Point Protocol) daemon.
|ppp-mod-pppoe||This package contains a PPPoE (PPP over Ethernet) plugin for ppp.|
|ppp-mod-pptp||This package contains a PPTP plugin for ppp.|
|kmod-nf-nathelper-extra||This package contains a net filter modules for PPTP.|
(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
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.
|: this is unfinished and not yet fully tested|
See also: 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
tc you configure one thing per invocation and you would write a shell script which is executed at every boot or at every
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.
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
|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|
/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
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).
pppd to load the generic options provided by the
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-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.
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
idle 3600, to make the router disconnect after one hour of inactivity and bring it back up again once the link is required.
/etc/ppp/chap-secrets file contains a list of usernames and passwords for use by
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
Add the following to the
DOMAIN\\Username peer_name Password *
There are four fields separated by spaces:
DOMAIN\\Username. It is important that this match the
/etc/ppp/peers/peer_namefile above. So, if no
DOMAIN\\was used, do not enter one here either.
peer_namewith whatever you used for
Passwordwith 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”.
pppdthat 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
pppd command is used to start a tunnel. The syntax is
pppd call peername, where
peername is one of the peer files in
pppd call peername updetach
|call name|| obtain options from file
|updetach||wait until the connection is made and then detach process from terminal|
To stop the tunnel, kill the
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
|nodetach||do not detach the process from terminal once link is started|
The output of a successful connection may look as follows:
# 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
pptp documentation and forums, since there is already tons of information available.
/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-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
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.
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 NET netmask NETMASK $1
NET with one you want to reach through the VPN-link.
NETMASK 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
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
/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
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 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.
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
if you get an error like this:
Received bad configure-ack: 02 06 00 00 00 00 05 06 92 64 55 28
You probably 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:
routecommands were entered in full path format, if this isn't done the scripts silently fail with a 127 exit code reported by
iptablesrules if you need them,
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