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 10.10.0.0/24. WAN has private address space 192.168.1.0/24 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 192.168.1.0/24 network but not from the remote end of the VPN.

• Allowed Remote IP Address: 192.168.1.0/24

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)

If I understand correctly the first rule accepts everything from ppp0 and makes the rest of the input policy redundant (for ppp0 sources). 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 www.google.com. Not certain if I am dealing with hardware, firmware, or network configuration issues. Any insight would be appreciated.

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
kelokepptpd)
  if [ $DEFAULTROUTE -eq 1 ]; then
    REMOTESUB="0.0.0.0"
    REMOTENET="0.0.0.0"
    /sbin/route add default dev $1
  else
    /sbin/route add -net $REMOTESUB netmask $REMOTENET dev $1
  fi
  /usr/sbin/iptables --insert OUTPUT --source 0.0.0.0/0.0.0.0 --destination $REMOTESUB/$REMOTENET --jump ACCEPT --out-interface $1
  /usr/sbin/iptables --insert INPUT --source $REMOTESUB/$REMOTENET --destination 0.0.0.0/0.0.0.0 --jump ACCEPT --in-interface $1
  /usr/sbin/iptables --insert FORWARD --source 0.0.0.0/0.0.0.0 --destination $REMOTESUB/$REMOTENET --jump ACCEPT --out-interface $1
  /usr/sbin/iptables --insert FORWARD --source $REMOTESUB/$REMOTENET --destination 0.0.0.0/0.0.0.0 --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
  fi
  /sbin/service dnsmasq restart
  ;;
 *)
esac
exit 0

Closed the security holes. Required that I add 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

Deleted the ppp0 INPUT filter from ip-up. Ditto for ip-down. Put the modified scripts in /tmp/mnt/USB/vpn/. All is peachy.

These changes are necessary if you use a service where the VPN acts as a gateway on the internet. Enabling NAT on ppp0 will protect the LAN from bad guys but without these modifications the Tomoto router itself is vulnerable. Verified that ICMP echo, SSH, and Telnet become reachable from the remote end of the VPN. It may be possible for other processes to be exploited too including Mini UPnP.

root@RT-N16:/tmp/mnt/USB/vpn# cat ip-up

#!/bin/sh
DEFAULTROUTE=$(/bin/nvram get pptp_client_dfltroute)
REMOTESUB=$(/bin/nvram get pptp_client_srvsub)
REMOTENET=$(/bin/nvram get pptp_client_srvsubmsk)
case "$6" in
 kelokepptpd)
  if [ $DEFAULTROUTE -eq 1 ]; then
    REMOTESUB="0.0.0.0"
    REMOTENET="0.0.0.0"
    /sbin/route add default dev $1
  else
    /sbin/route add -net $REMOTESUB netmask $REMOTENET dev $1
  fi
  /usr/sbin/iptables --insert OUTPUT --source 0.0.0.0/0.0.0.0 --destination $REMOTESUB/$REMOTENET --jump ACCEPT --out-interface $1
  /usr/sbin/iptables --insert FORWARD --source 0.0.0.0/0.0.0.0 --destination $REMOTESUB/$REMOTENET --jump ACCEPT --out-interface $1
  /usr/sbin/iptables --insert FORWARD --source $REMOTESUB/$REMOTENET --destination 0.0.0.0/0.0.0.0 --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
  fi
  /sbin/service dnsmasq restart
  ;;
 *)
esac
exit 0

root@RT-N16:/tmp/mnt/USB/vpn# cat ip-down

#!/bin/sh
DEFAULTROUTE=$(/bin/nvram get pptp_client_dfltroute)
REMOTESUB=$(/bin/nvram get pptp_client_srvsub)
REMOTENET=$(/bin/nvram get pptp_client_srvsubmsk)
case "$6" in
 kelokepptpd)
  if [ $DEFAULTROUTE -eq 1 ]; then
    REMOTESUB="0.0.0.0"
    REMOTENET="0.0.0.0"
    /sbin/route del default dev $1
  else
    /sbin/route del -net $REMOTESUB netmask $REMOTENET dev $1
  fi
  /usr/sbin/iptables -D OUTPUT --source 0.0.0.0/0.0.0.0 --destination $REMOTESUB/$REMOTENET --jump ACCEPT --out-interface $1
  /usr/sbin/iptables -D FORWARD --source 0.0.0.0/0.0.0.0 --destination $REMOTESUB/$REMOTENET --jump ACCEPT --out-interface $1
  /usr/sbin/iptables -D FORWARD --source $REMOTESUB/$REMOTENET --destination 0.0.0.0/0.0.0.0 --jump ACCEPT --in-interface $1
  /usr/sbin/iptables -D 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 -D POSTROUTING --out-interface $1 --jump MASQUERADE
  fi
  /sbin/service dnsmasq restart
  ;;
 *)
esac
exit 0