Startup scripts: DD-WRT vs. Tomato

Discussion in 'Tomato Firmware' started by tymbrwlf, Sep 11, 2013.

  1. tymbrwlf

    tymbrwlf Reformed Router Member

    I am in the process of trying to migrate from DD-WRT on my primary Router to Tomato. This has been prompted by a need for a more robust QoS system due to the implementation of a new VOIP System. DD-WRT's implementation of QoS is just not satisfactory and after having played with Tomato (Toastman's build to be specific), I have found it to be much better at allocating and controlling traffic in a relatively easy way to manage.

    What I need to do first is to set up a Tomato based router that provides the same base-level functionality that I have my DD-WRT based router doing currently. I have a custom startup script on my DD-WRT router that provide a number of things; NAT Translation from external IP to internal Quickbooks server, VPN, and a number of other services that servers in an external location need to be able to access.

    This is my current DD-WRT Startup script (I've changed the some of the IP addresses listed for security purposes):

    # Add in new IP that the router can listen to
    ip addr add <Second External IP Address> dev vlan1
    ip addr add <Third External IP Address> dev vlan1
    # Allow loopback for the new IPs (from internal to external)
    iptables -t nat -I POSTROUTING 1 -p all -s 10.x.x.32 -j SNAT --to <Second External IP Address>
    iptables -t nat -I POSTROUTING 1 -p all -s 10.x.x.45 -j SNAT --to <Third External IP Address>
    # QuickBooks: 80 (HTTP), 443 (SSL), 3306 (MySQL), 3389 (RDP)
    iptables -t nat -A PREROUTING -p tcp -d <Second External IP Address> --match multiport --dports 80,443,3306,3389 -j DNAT --to-destination 10.x.x.44
    iptables -I FORWARD -p tcp -d 10.x.x.44 --match multiport --dports 80,443,3306,3389 -j ACCEPT
    # VPN
    iptables -t nat -A PREROUTING -p tcp -d <Third External IP Address> --dport 1723 -j DNAT --to-destination 10.x.x.45:1723
    iptables -I FORWARD -p tcp -d 10.x.x.45 --dport 1723 -j ACCEPT
    # Development Website
    iptables -t nat -A PREROUTING -p tcp -d <Primary External IP Address> --dport 80 -j DNAT --to-destination 10.x.x.41:80
    iptables -I FORWARD -p tcp -d 10.x.x.41 --dport 80 -j ACCEPT
    # External to internal LDAP Translation
    iptables -t nat -A PREROUTING -p tcp -d <Third External IP Address> --dport 389 -j DNAT --to-destination 10.x.x.45:389
    iptables -I FORWARD -p tcp -d 10.x.x.45 --dport 389 -j ACCEPT

    If I copy and paste this exact script to my Tomato based router (in the firewall script), it doesn't work; VPN won't connect, LDAP fails, etc. I just can't seem to figure out why.

    In looking at the output from "iptables -vnL" and "iptables -t nat -L --line-numbers" on both routers, it appears that there are some differences when it seems like they should be the same, if they're using the same custom startup script. Specifically, there are some DROP rules in the beginning of the INPUT, FORWARD, and PREROUTING chain on Tomato that are not showing up on DD-DWRT. I added a few rules to remove those on Startup but it's still not working.

    I suspect that the way my rules are setup on DD-DWRT are simply not correct for Tomato and it's implementation of iptables. If anyone can provide some insight, I would really appreciate it. I've got to get this functionality working before I can even begin playing with QoS.

    Thank you in advance for any input. If I need to provide more information, please let me know.
  2. tymbrwlf

    tymbrwlf Reformed Router Member

    Also, I'm using "DD-WRT v24-sp2 (10/10/09) mega" on my current router (WRT54G-TM) and "Tomato Firmware v1.28.7634 Toastman-IPT-ND ND USB VLAN-Ext" (also a WRT54G-TM)
  3. koitsu

    koitsu Network Guru Member

    Why don't you telnet or SSH into the router and issue each of the above commands, one at a time, by hand or by copy/pasting a line at a time? You'll figure out which lines cause problems pretty quickly.

    One issue I see is that for your IP aliases, you're blindly binding things to vlan1 -- which is, on many routers under Tomato is already created and is for the LAN, but your comments indicate you're wanting it to be associated with an externally-facing address (i.e. an Internet-facing address).

    On Tomato with an RT-N16, the interfaces are as follows (I cannot help you with VPNs, if you're making your own VLANs, etc.):

    br0 = Bridge interface, which is a virtual bridge that binds vlan1 and eth1 together (keep reading)
    eth1 = Interface for wireless card
    vlan1 = 4 of 5 Ethernet ports on your router, a.k.a. the "LAN port(s)"
    vlan2 = 1 of 5 Ethernet ports on your router, a.k.a. the "WAN" port"

    On the model of router I mention, the Broadcom switch IC itself consists of 5 Ethernet ports -- the vlanX interfaces are used as a way to segregate which Ethernet port(s) go to what vlanX interface. I should be clear here: there is hardware support for this via the et.ko driver (Broadcom ethernet switch driver; proprietary if I remember right) so it's very fast/clean, but that's how it works.

    You're probably using a WRT54G (fairly old) and the interface naming convention may be different, but you should check. ifconfig -a would be all I'd need to see.

    So if your ip addr add commands aren't working (for creating IP aliases), it's because you're probably binding them to the LAN segment of your switch. You should change your commands to use ip addr add ... dev `nvram get wan_iface` (which will return the vlan interface name of your WAN interface).

    We can talk more about the iptables rules after you figure the above out. But I will tell you right now: removing the stock default Tomato rules (which you admitted you did during testing) is a very very bad thing to do. Many of them are there intentionally for security-related reasons. You should leave those alone and place your rules where appropriate. If you don't know where "appropriate" is, we can teach you; as I said, one step at a time.

    Some of these may need to go into the WAN Up scripts section and not the Firewall section, just FYI. If you're using PPPoE or PPPoA this is particularly important.

    You can look at /etc/iptables (which is generated partially off of internal code, and partially off NVRAM variables for things like the Port Forwarding table in the GUI) if you want to get an idea of what's what. Do not modify that file BTW -- your changes won't stick after a reboot or if you do a Save in the GUI.

    BTW, the fact that you're hiding IP addresses (using x.x.x, not providing the external IPs, etc.) does not really help. When it comes to firewall rules and network troubleshooting, it really helps if people can just provide things verbatim. I know you're security-conscious and don't want to disclose some of this stuff, but people port scan literally every IP on the Internet all the time, so those interested in tracking you down/etc. would eventually be able to anyway given that you're providing publicly-accessible services to some degree. What I'm trying to say here is that you omitting/hiding information just makes things harder to figure out / the likelihood of misunderstanding (on our parts) or typos/mistakes even higher.

    Footnote: it's too bad the GUI for Port Forwarding doesn't provide a destination IP field (equivalent of -d in iptables; the "Int Address" in Tomato's GUI refers to the --to-destination address/port), else I'd recommend you use the GUI and let the code work it all out. Bummer.
  4. tymbrwlf

    tymbrwlf Reformed Router Member

    Thanks for the very detailed reply. Unfortunately, I was instructed by my managers to purchase a recommended router (Linksys EA4500) instead of using one with DD-WRT/Tomato per the VOIP provider's requirements. I cannot put anything other than Linksys firmware (neither DD-WRT or Tomato is supported on tis chipset) on it so my original request has become moot. I'm less than happy about it as the Linksys firmware is truly atrocious but it does what it needs to do.

    However, by running ip addr add ... dev `nvram get wan_iface` I was able to verify that the WAN interface is vlan1 by default. Perhaps this is different because of the router I was originally using (a WRT54G-TM)?
  5. koitsu

    koitsu Network Guru Member

    Re: vlan1: very possible, but I'm also running under the assumption that the very first thing you did a thorough NVRAM erase (through the GUI menu).
  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