Restrict VPN Traffic (Shibby tomato-K26USB-1.28.RT-MIPSR2-105.1-AIO.trx)

Discussion in 'Tomato Firmware' started by heirloom, Feb 4, 2013.

  1. heirloom

    heirloom Serious Server Member

    I recently purchased an ASUS N16 router and discovered the world of custom router software. To Shibby and the Tomato contributors I thank you very much. Kudos and peans of praise!

    After slogging through the world of ipchains I'd like some help to verify a couple of rules I've changed which, hopefully, properly secure my Tomato VPN gateway. The VPN gateway is established as a PPTP client to a server on the internet. LAN has private address space WAN has private address space established using DHCP to an internet gateway. The internet gateway also does NAT and has the VPN gateway in its DMZ but no other forwarding rules.

    Firstly, I have attempted to restrict remote access to the VPN SSH and Telnet admin by using the Tomato GUI. The intention is to only allow "remote" access from machines on the network but not from the remote end of the VPN.
    • Allowed Remote IP Address:
    After establishing the client PPTP VPN to an internet VPN server shields-up reports that Telnet and SHH are open. Checking the logfile I see login attacks from China. My fault for using a "what is my ip address" web page found by googling an unknown server. Still, this should not be happening. The following was reported by ipchains:

    Chain INPUT (policy DROP 1 packets, 32 bytes)
    target    prot opt in    out    source              destination
    ACCEPT    all  --  ppp0  *  
    DROP      all  --  *      *            state INVALID
    ACCEPT    all  --  *      *            state RELATED,ESTABLISHED
    ACCEPT    all  --  lo    *  
    ACCEPT    all  --  br0    *  
    ACCEPT    udp  --  *      *            udp spt:67 dpt:68
    ACCEPT    tcp  --  *      *          tcp dpt:80
    ACCEPT    tcp  --  *      *          tcp dpt:22
    If I understand correctly the first rule accepts everything from ppp0 and makes the rest of the input policy useless. I deleted the ppp0 rule using the console. Nothing appears to have broken as a result and shields-up reports eveything is stealthy. Any guess what must be changed to fix this behavior permanently?

    Secondly, I have added a rule to prevent LAN traffic from routing through the VPN gateway to the WAN (and thus bypassing the VPN tunnel).
    • iptables -I FORWARD -i br0 -o vlan2 -j DROP
    The obvious place for this behavior is Tomato > Administration > Scripts > Firewall. Although it appears to work correctly I have strange intermittent problems where traffic from the lan to the ppp0 vpn just stops and nothing short of a full reboot corrects the problem. When this happens, before rebooting, I can use Tools > Ping to successfully reach Not certain if I am dealing with hardware, firmware, or network configuration issues. Any insight would be appreciated.
  2. heirloom

    heirloom Serious Server Member

    The default DROP action in the filter chain suggests that additional rules are expected to be as narrowly permissive as possible. If so then the INPUT rule shown below is a bug and should not exist because it opens the doors from ppp0 wide open.

    Just deleting the line means that any local processes expecting traffic from ppp0 will fail and so extra rules need to be added. Other running processes are: dropbear, dnsmasq, pptpclient, miniupnpd, httpd, telnetd, klogd, syslogd, .... Being very, very lazy I'm tempted to change this script by deleting the INPUT rule. Oh my god, I just noticed, because ppp0 is wide open is miniupnpd a giant security hole?

    cat /etc/vpn/ip-up
    DEFAULTROUTE=$(/bin/nvram get pptp_client_dfltroute)
    REMOTESUB=$(/bin/nvram get pptp_client_srvsub)
    REMOTENET=$(/bin/nvram get pptp_client_srvsubmsk)
    case "$6" in
      if [ $DEFAULTROUTE -eq 1 ]; then
        /sbin/route add default dev $1
        /sbin/route add -net $REMOTESUB netmask $REMOTENET dev $1
      /usr/sbin/iptables --insert OUTPUT --source --destination $REMOTESUB/$REMOTENET --jump ACCEPT --out-interface $1
      /usr/sbin/iptables --insert INPUT --source $REMOTESUB/$REMOTENET --destination --jump ACCEPT --in-interface $1
      /usr/sbin/iptables --insert FORWARD --source --destination $REMOTESUB/$REMOTENET --jump ACCEPT --out-interface $1
      /usr/sbin/iptables --insert FORWARD --source $REMOTESUB/$REMOTENET --destination --jump ACCEPT --in-interface $1
      /usr/sbin/iptables --insert FORWARD --protocol tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu
      if [ "$(/bin/nvram get pptp_client_nat)" = "1" ]; then
          /usr/sbin/iptables --table nat --append POSTROUTING --out-interface $1 --jump MASQUERADE
      /sbin/service dnsmasq restart
    exit 0
  3. heirloom

    heirloom Serious Server Member

    If want to use your Tomato router to connect an encrypted VPN tunnel to the internet then you're likely to experience some problems.

    First problem is that your IP address may leak outside of the VPN during boot, or when the tunnel is disconnected. To prevent this you need to configure a forwarding rule that prevents the lan (br0) from sending any packets directly to the WAN (vlan2):
    • iptables -I FORWARD -i br0 -o vlan2 -j DROP
    Other threads in this forum describe how to filter traffic more selectively if you need only some machines to be isolated as opposed to the entire LAN. This is not necessary for my purposes.

    Second problem is that the Tomato router will become absolutely naked and virtually unprotected to attacks from the internet at the remote end of the VPN. The culprit is an INPUT rule added to the filter table. The original code submission is here:

    The code has been active since Nov 2011 so it probably satisfies a valid use-case. I don't know what it is and may have to ask the original author ... though I am not terribly interested because it doesn't appear to be needed for this scenario. In fact it is dangerous. It exposes Telnet, SSH, ICMP Echo, and possibly other processes that can do real harm when used as a vulnerability and exploited.

    To fix I've added the following statements to PPTP Client Configuration:
    • ip-up-script /tmp/mnt/USB/vpn/ip-up
    • ip-down-script /tmp/mnt/USB/vpn/ip-down
    Delete the ppp0 INPUT filter from /rom/etc/vpn/ip-up. Ditto for /rom/etc/vpn/ip-down. Put the modified scripts in /tmp/mnt/USB/vpn/. There are probably other options for storing the modified scripts that are more secure but this fit my needs. All is peachy.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice