Problem

The idea was to have a separate VPN tunnel tothe office to access office LAN resources without a need to bring up the VPN connection on the workstation. The challenge was a) to find right PPTP options to connect to Windows VPN server and b) to adjust the routing table on the router to route connections to the office LAN through this tunnel.

OpenWRT version Backfire (10.03.1, r29592) running on TP-LINK TP-WR1043ND.

Solution

1. Configure new PPTP interface via LuCI or directly in /etc/config/network

   config 'interface' 'bw116'
       option 'proto' 'pptp'
       option 'auto' '0'
       option 'server' 'xx.yy.zz.116'
       option 'username' 'AB\Cdefg'
       option 'password' '12345'
       option 'defaultroute' '0'
       option 'peerdns' '0'
   

   Important is not to set default route and not to use DNS, in my case I connect to office resources via IP. In the first version I bring this tunnel up manually via LuCI, future plan is to bring it up on demand.
   Also note username specified as Windows Domain\User Name with just one slash above.

2. Adjust /etc/ppp/options and /etc/ppp/options.pptp

   root@OpenWrt:~# cat /etc/ppp/options
    debug
    logfile /dev/null
    noaccomp
    ipparam vpn
    replacedefaultroute
    nopcomp
    nocrtscts
    persist
    holdoff 10
    lock
    maxfail 0
    lcp-echo-failure 5
    lcp-echo-interval 5
   

   root@OpenWrt:~# cat /etc/ppp/options.pptp
    lock
    noauth
    nobsdcomp
    nodeflate
    idle 0
    defaultroute
    maxfail 0
    refuse-eap
    mppe required,no40,no56,stateless
    

   Last 2 lines appear to be essential to connect to Windows VPN server

3. Create new routing table. OpenWrt package ip will be needed.

   root@OpenWrt:~# opkg info ip
    Package: ip
    Version: 2.6.29-1-2
    Provides:
    Status: install user installed
    Section: net
    Architecture: ar71xx
    Maintainer: OpenWrt Developers Team
    MD5Sum: bb8d81a04dc2042a041ff3866167a05c
    Size: 76789
    Filename: ip_2.6.29-1-2_ar71xx.ipk
    Conffiles:
    /etc/iproute2/rt_tables a1313318d6778fe6b8c680248ef5a463
    Source: package/iproute2
    Description: Routing control utility
    Installed-Time: 1342434293
   

   Edit /etc/iproute2/rt_tables and add new entry vpn for a new routing table. This is persistent, no need to repeat this after reboot or to write any script to create it.

   root@OpenWrt:~# cat /etc/iproute2/rt_tables
    #
    # reserved values
    #
    255     local
    254     main
    253     default
    10      vpn
    0       unspec
    #
    # local
    #
    #1      inr.ruhep
    #
   

4. Create new script, that will be run each time out new PPTP interface goes up.

   root@OpenWrt:~# cat /etc/ppp/ip-up.d/10-bw116
    #!/bin/sh
    #PPP_REMOTE=$5
    logger -p daemon.debug "Starting script /etc/ppp/ip-up.d/10-bw116"
    #This is office LAN subnet
    REMOTE_NET="192.168.100.0/24"
    #Custom routing table created in previous step
    VPN_TABLE="vpn"
    #Delete an entry for VPN gateway in the main routing table
    #created when interface went up by /etc/ppp/ip-up script
    #5-th command line argument is this GW IP
    route del $5
    #Remove all old rules for this remote network
    ip rule list | grep -E "to[ \t]+$REMOTE_NET"  | while read line ; do
        ip rule del to "$REMOTE_NET"
    done
    #Add rule to route everything going to the remote LAN network
    #via custom routing table
    ip rule add to $REMOTE_NET lookup $VPN_TABLE
    #Put just one entry in the custom routing table to send via
    #PPTP interface
    ip route add $REMOTE_NET dev $1 table $VPN_TABLE
    logger -p daemon.debug "Finishing script /etc/ppp/ip-up.d/10-bw116"
   

5. Done for now.

Discussion

Things to consider for further improvement

• Connection won’t restore automatically, when dropped. For relatively stable WAN uplink might not be so important. Actually it never drops unless I manually help it.
• Would be nice to have this VPN link going up on demand, i.e. when somebody wants to connect to 192.168.100.x address, it goes up ans stays connected for as long as needed and then shuts down after some inactivity period. This could be rather simple as most commodity routers do provide this feature in some form, just needs time for testing.

Comments

comments